Magento Admin/Front Serveur Split Redis error

Question

J'ai deux serveurs identiques (A et B) synchronisés via Lsyncd. Le serveur principal A utilise Magento 1.9.1 CE configuré avec Apache, Redis et RDS et utilise FPC. Je l'ai configuré avec l'URL d'admin faite sur commande pour l'admin et B pour l'avant. J'ai synchronisé tous les répertoires sauf var et app/etc/local.xml car B a une légère modification pour la configuration redis.

B se connecte à l'instance redis de A. Redis est configuré pour le cache backend et le stockage de session. J'ai testé la désactivation de tous les types de cache dans la gestion de cache et cela a bien fonctionné mais quand je les ai tous activés, Redis a une erreur dans B. J'ai désactivé le type de cache 'Configuration' et l'erreur disparaissait.

La chose mystérieuse est; si j'active le type de cache 'Configuration', puis fais 'flushall' dans redis; et que le serveur A ou B charge d'abord et crée des clés de cache backend l'autre a cette erreur. Disons si A se charge d'abord, puis B a une erreur redis. Et si c'est fait, flushall en redis et B se charge en premier, alors A a une erreur redis. Je n'arrive pas à comprendre ce qui ne va pas. Voilà ma configuration Redis:

 <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> 

Le problème est avec cache back-end à savoir la base de données 0 Il ne semble pas partager entre les différents urls.

L'erreur est Redis:

Cependant, si dans le local.xml de B i utilise la base de données séparée permet de dire 2 pour le cache de back-end qu'il n'a pas de problème. Je veux utiliser la même base de données de cache backend pour A et B. Quelqu'un pourrait-il m'aider à comprendre ce qui se passe ici?

Merci!

Answer 1

J'ai trouvé une solution de contournement et la solution semble logique. J'ai fait des fichiers local.xml identiques sur les deux serveurs. Le fichier local.xml dans le serveur A, j'ai configuré redis pour se connecter à son ip privé au lieu de son adresse IP locale 127.0.0.1 pour le cache et la session. Comme B doit se connecter à l'instance redis dans A, la configuration était la même. Et puis j'ai fait flushall redis et ça a marché. Je pense que Magento stocke la configuration dans la base de données. Activer le type de cache "Configuration" dans Cache Management semble donner une erreur surtout pour le serveur frontal B, comme quand A charge d'abord le nom d'hôte précédemment 127.0.0.1 a été enregistré dans la base de données qui a causé le serveur B avec l'erreur redis connect en essayant de se connecter à lui-même au lieu du serveur distant A. (le service redis a été arrêté dans B)

J'ai fait quelques recherches et j'ai découvert que c'est le cas. Ce message a contribué à enflammer le processus de pensée.

How can I disable the cache via the database?

Ce fut la même chose avec la base de données locale. J'ai donc utilisé RDS mais je n'ai pas réalisé que c'était le problème lié au nom d'hôte qui n'était pas cohérent.