Magento Admin/Front Split Server Redis Fehler

Question

Ich habe zwei identische Server (A und B) über Lsyncd synchronisiert. Hauptserver A verwendet Magento 1.9.1 CE, das mit Apache, Redis und RDS konfiguriert ist, und verwendet FPC. Ich habe es mit benutzerdefinierten Admin-URL konfiguriert, die A für Admin und B für Front machen. Ich habe alle Verzeichnisse außer var und app/etc/local.xml synchronisiert, da B eine leichte Modifikation für die Redis-Konfiguration hat.

B verbindet sich mit der Redis-Instanz von A. Redis ist für Back-End-Cache und Sitzungsspeicher konfiguriert. Ich habe getestet, alle Cachetypen in der Cache-Verwaltung zu deaktivieren, und es funktionierte gut, aber als ich sie alle aktivierte, gab es Redis-Fehler in B. Ich deaktivierte 'Configuration' Cachetyp und der Fehler war weg.

Das Ding, das mysteriös ist, ist; wenn ich den Cachetyp 'Configuration' aktiviere und dann in redis 'flushall' mache; und welcher auch immer Server A oder B zuerst lädt und Back-End-Cache-Schlüssel erstellt, der andere hat diesen Fehler. Sagen wir, wenn A zuerst lädt dann hat B redis Fehler. Und wenn Flushall in Redis und B Lasten zuerst getan wird, dann hat A redis Fehler.

Ich kann nicht scheinen, herauszufinden, was falsch ist. Hier ist meine redis Konfiguration:

 <session_save>db</session_save> 
    <cache> 
     <backend>Mage_Cache_Backend_Redis</backend> 
     <backend_options> 
      <server>127.0.0.1</server> 
      <port>6379</port> 
      <database>0</database> 
      <password>SOME_PASSWORD</password> 
      <force_standalone>0</force_standalone> <!-- 0 for phpredis, 1 for standalone PHP --> 
      <connect_retries>3</connect_retries> <!-- Reduces errors due to random connection failures --> 
      <automatic_cleaning_factor>0</automatic_cleaning_factor> <!-- Disabled by default --> 
      <compress_data>1</compress_data> <!-- 0-9 for compression level, recommended: 0 or 1 --> 
      <compress_tags>1</compress_tags> <!-- 0-9 for compression level, recommended: 0 or 1 --> 
      <compress_threshold>20480</compress_threshold> <!-- Strings below this size will not be compressed --> 
      <compression_lib>gzip</compression_lib> <!-- Supports gzip, lzf and snappy --> 
      <persistent>1</persistent> <!-- persistence value, 0: not in use, > 0 used as persistence ID --> 
     </backend_options> 
    </cache> 
    <redis_session>      <!-- All options seen here are the defaults --> 
     <host>127.0.0.1</host> 
     <port>6379</port> 
     <password>SOME_PASSWORD</password>   <!-- Specify if your Redis server requires authentication --> 
     <timeout>2.5</timeout>   <!-- This is the Redis connection timeout, not the locking timeout --> 
     <persistent></persistent>   <!-- Specify unique string to enable persistent connections. E.g.: sess-db0; bugs with phpredis and php-fpm are known: https://github.com/nicolasff/phpredis/issues/70 --> 
     <db>1</db>      <!-- Redis database number; protection from accidental loss is improved by using a unique DB number for sessions --> 
     <compression_threshold>2048</compression_threshold> <!-- Set to 0 to disable compression (recommended when suhosin.session.encrypt=on); known bug with strings over 64k: https://github.com/colinmollenhour/Cm_Cache_Backend_Redis/issues/18 --> 
     <compression_lib>gzip</compression_lib>    <!-- gzip, lzf or snappy --> 
     <log_level>4</log_level>    <!-- 0 (emergency: system is unusable), 4 (warning; additional information, recommended), 5 (notice: normal but significant condition), 6 (info: informational messages), 7 (debug: the most information for development/testing) --> 
     <max_concurrency>6</max_concurrency>     <!-- maximum number of processes that can wait for a lock on one session; for large production clusters, set this to at least 10% of the number of PHP processes --> 
     <break_after_frontend>5</break_after_frontend>  <!-- seconds to wait for a session lock in the frontend; not as critical as admin --> 
     <break_after_adminhtml>30</break_after_adminhtml> 
     <bot_lifetime>7200</bot_lifetime>     <!-- Bots get shorter session lifetimes. 0 to disable --> 
    </redis_session> 

Das Problem ist mit Back-End-Cache heißt Datenbank 0 Es ist nicht zwischen den verschiedenen URLs zu teilen scheint.

Die Redis Fehler ist:

Wenn jedoch in B local.xml i separate Datenbank verwenden kann 2 sagen für Back-End-Cache als es kein Problem hat. Ich möchte die gleiche Backend-Cache-Datenbank für A und B verwenden. Könnte mir jemand helfen zu verstehen, was hier passiert?

Danke!

Answer 1

Ich habe einen Workaround gefunden und die Lösung scheint Sinn zu machen. Ich habe identische local.xml-Dateien auf beiden Servern erstellt. Die Datei local.xml auf Server A, ich habe redis so konfiguriert, dass sie sich mit ihrer privaten IP anstelle ihrer lokalen IP 127.0.0.1 sowohl für den Cache als auch für die Sitzung verbindet. Da B eine Verbindung zur Redis-Instanz in A herstellen muss, war die Konfiguration identisch. Und dann habe ich flushall wieder entdeckt und es hat funktioniert. Ich denke, Magento speichert die Konfiguration in der Datenbank. Das Aktivieren des Cachetyps "Konfiguration" in der Cache-Verwaltung scheint daher insbesondere für den Frontserver B Fehler zu verursachen, da, wenn A zuerst lädt, der vorhergehende Hostname 127.0.0.1 in der Datenbank gespeichert wurde, was zu einem Verbindungsfehler des Servers B führte zu sich selbst anstelle von Remote-Server A. (Redis-Service wurde in B gestoppt)

Ich habe etwas Forschung und fand heraus, dass es tut. Dieser Beitrag hat dazu beigetragen, den Denkprozess zu entfachen.

How can I disable the cache via the database?

Dies war das gleiche mit lokaler Datenbank. Also habe ich RDS benutzt, aber ich wusste nicht, dass das Problem mit dem Hostnamen nicht konsistent war.