Le cluster RabbitMQ ne se reconnecte pas après une panne réseau

J'ai RabbitMQ cluster à deux nœuds dans la production et le cluster est en rupture avec ces messages d'erreur:

=RAPPORT d'ERREUR==== 23-Déc-2011::04:21:34 ===
** Nœud de lapin@rabbitmq02 pas de réponse **
** La suppression (timedout) de la connexion **

=INFO RAPPORT==== 23-Déc-2011::04:21:35 ===
nœud de lapin@rabbitmq02 perdu lapin

=RAPPORT d'ERREUR==== 23-Déc-2011::04:21:49 ===
Amnésie & nbsp; (lapin@rabbitmq01): ** ERREUR ** mnesia_event obtenu {inconsistent_database, running_partitioned_network, lapin@rabbitmq02}

J'ai essayé de simuler le problème en tuant la connexion entre les deux nœuds à l'aide de "tcpkill", le cluster s'est déconnecté,et, étonnamment, les deux nœuds ne sont pas essayer de renouer !

Lorsque le cluster des pauses, haproxy équilibreur de charge marque encore les deux nœuds actifs et envoyer la demande à la fois d'entre eux, bien qu'ils ne sont pas dans un cluster.

Mes questions:

  1. Si les nœuds sont configurés pour fonctionner en tant que cluster, quand j'ai une panne de réseau , pourquoi ne sont-ils pas essayer de se reconnecter après ?
  2. Comment puis-je identifier les brisées de cluster et de l'arrêt de l'un des nœuds ? J'ai des problèmes de cohérence lorsque l'on travaille avec les deux nœuds séparément.

source d'informationauteur Ranch

  1. 8

    Un autre moyen pour récupérer à partir de ce type de défaillance est de travailler avec amnésie & nbsp; qui est la base de données RabbitMQ utilise le mécanisme de persistance et de la synchronisation de la RabbitMQ instances (et le maître /esclave) sont contrôlés par ce. Pour plus de détails, reportez-vous à l'URL suivante: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap7.html

    Ajout de la section pertinente ici:

    Il y a plusieurs occasions, lorsque amnésie & nbsp; peut détecter que le réseau
    a été partitionné en raison d'une défaillance de communication.

    C'est quand amnésie & nbsp; est déjà en place et en cours d'exécution et l'Erlang nœuds de gain
    contacter de nouveau. Puis amnésie & nbsp; essaie de contacter amnésie & nbsp; sur l'autre
    nœud pour voir si elle pense également que le réseau a été partitionné
    pendant un certain temps. Si amnésie & nbsp; sur les deux nœuds a enregistré mnesia_down entrées
    les uns des autres, amnésie & nbsp; génère un événement système, appelé
    {inconsistent_database, running_partitioned_network, Nœud}, qui est
    envoyé à l'amnésie & nbsp; le gestionnaire d'événements et autres abonnés. L'
    gestionnaire d'événement par défaut signale une erreur à l'erreur enregistreur.

    Une autre occasion, lors de l'amnésie & nbsp; peut détecter que le réseau a été
    partitionné en raison d'une panne de communication, est au démarrage. Si Amnésie & Nbsp;
    détecte à la fois le nœud local et un autre nœud reçu mnesia_down
    les uns des autres il génère un {inconsistent_database,
    starting_partitioned_network, Nœud} événements système et agit comme décrit
    ci-dessus.

    Si l'application détecte qu'il y a eu un échec de communication
    qui peut avoir causé une base de données incohérente, elle peut utiliser le
    fonction amnésie & nbsp;: set_master_nodes(Onglet Nœuds) pour identifier à partir de laquelle
    les nœuds de chaque table peut être chargé.

    Au démarrage amnésie & nbsp; est normal tableau de charge algorithme sera contourné et
    la table sera chargé à partir de l'un des maître de nœuds définis pour l'
    tableau, quel que soit leur potentiel mnesia_down entrées dans le journal. L'
    Les nœuds ne peuvent contenir que des nœuds où la table a une réplique et si il
    est vide, le nœud principal mécanisme de récupération de la table en particulier
    seront remis à zéro et la charge normale mécanisme sera utilisé lors de la prochaine
    le redémarrage.

    La fonction amnésie & nbsp;: set_master_nodes(Nœuds) des ensembles de noeuds maîtres pour tous
    des tables. Pour chaque table, il déterminera sa réplique de nœuds et d'appeler
    amnésie & nbsp;: set_master_nodes(Onglet, TabNodes) avec ces répliques de nœuds
    sont inclus dans la liste de Nœuds (c'est à dire TabNodes est l'intersection de
    Les nœuds et les répliques de nœuds de la table). Si l'intersection est
    vide le nœud principal mécanisme de récupération pour la table
    être réinitialisé et la charge normale mécanisme sera utilisé lors du prochain redémarrage.

    Les fonctions amnésie & nbsp;: system_info(master_node_tables) et
    amnésie & nbsp;: table_info(Onglet, master_nodes) peut être utilisé pour obtenir des informations
    sur le potentiel de noeuds maîtres.

    Déterminer la nature des données à conserver après l'échec de la communication est à l'extérieur
    le champ d'application de l'amnésie & nbsp;. Une approche serait de déterminer "l'île"
    contient une majorité de nœuds. À l'aide de l' {majorité,vrai} option pour
    critique des tables peut être un moyen de s'assurer que les nœuds qui ne sont pas de la partie
    d'une "majorité de l'île" ne sont pas en mesure de mettre à jour ces tables. Notez que
    cela constitue une réduction du service à la minorité des nœuds. Cette
    serait un compromis en faveur de davantage de consistance des garanties.

    La fonction amnésie & nbsp;: force_load_table(Onglet) peut être utilisé pour charger de force
    le tableau indépendamment de la table mécanisme de chargement est activé.

    C'est un plus longue et complexe moyen de récupérer de tels échecs .. mais donnera une meilleure granularité et le contrôle sur les données qui devraient être disponibles dans le dernier nœud maître (ce qui peut réduire le montant de la perte de données peut se produire quand une "fusion" RabbitMQ maîtres).

  2. 9

    RabbitMQ Grappes ne sont pas bien fonctionner sur des réseaux non fiables (partie de RabbitMQ de la documentation). Ainsi, lorsque la défaillance du réseau qui se passe (dans un cluster à deux nœuds) chaque nœud pense qu'il est le maître et le seul nœud dans le cluster. Deux nœuds maîtres ne pas se reconnecter automatiquement, parce que leurs membres ne sont pas synchronisées automatiquement (même en cas de RabbitMQ esclave - le véritable message de synchronisation ne se produit pas - l'esclave juste "rattrape" comme les messages sont consommés à partir de la file d'attente et plus de messages ajoutés).

    De détecter si vous avez cassé un cluster, exécutez la commande:

    rabbitmqctl cluster_status

    sur chacun des nœuds qui font partie du cluster. Si le cluster est cassé, alors vous ne verrez qu'un seul nœud. Quelque chose comme:

    Cluster status of node rabbit@rabbitmq1 ...
[{nodes,[{disc,[rabbit@rabbitmq1]}]},{running_nodes,[rabbit@rabbitmq1]}]
...done.

    Dans de tels cas, vous devez exécuter les commandes suivantes sur l'un des nœuds qui faisait partie du premier groupe (de sorte qu'il se joint à l'autre nœud maître (dire rabbitmq1) dans le cluster en tant qu'esclave):

    rabbitmqctl stop_app

rabbitmqctl reset

rabbitmqctl join_cluster rabbit@rabbitmq1

rabbitmqctl start_app

    Enfin vérifier l'état du cluster de nouveau .. cette fois, vous devriez voir les deux nœuds.

    Remarque: Si vous avez le RabbitMQ des nœuds dans un HA de configuration à l'aide d'une adresse IP Virtuelle (et les clients se connectent à RabbitMQ à l'aide de cette adresse IP virtuelle), puis le nœud qui doit être fait le maître doit être celui qui a l'adresse IP Virtuelle.

  3. 6

    RabbitMQ propose également deux façons de traiter avec le réseau des partitions automatiquement: pause-minoritaires mode et autoheal mode. (Le comportement par défaut est appelé mode ignorer).

    En pause de minorité mode RabbitMQ se met automatiquement en pause les nœuds de cluster qui déterminent eux-mêmes pour être à une minorité (c'est à dire moins de ou égale à la moitié du nombre total de nœuds) après avoir vu les autres nœuds aller vers le bas. Il choisit donc la partition de tolérance par rapport à la disponibilité du théorème CAP. Cela garantit que, dans le cas d'un partage réseau, au plus les nœuds en une seule partition de continuer à fonctionner.

    Dans autoheal mode RabbitMQ décidera automatiquement sur un gagnant partition si une partition est réputée avoir eu lieu. Il va redémarrer tous les nœuds qui ne sont pas dans la réussite de la partition. Le gagnant partition est celle qui a le plus de
    Gérer automatiquement les partitions

    clients connectés (ou si cela produit un tirage au sort, l'un avec la plupart des nœuds; et si cela produit toujours un tirage au sort ensuite l'une des partitions est choisi dans l'une quelconque façon).

    Vous pouvez activer le mode de réglage du paramètre de configuration cluster_partition_handling pour le lapin application dans votre fichier de configuration soit pause_minority ou autoheal.

    Le mode dans lequel devrais-je choisir?

    Il est important de comprendre qu'en permettant à des RabbitMQ pour traiter avec le réseau des partitions automatiquement n'en fait pas moins un problème. Réseau des partitions posera toujours des problèmes pour RabbitMQ grappes; vous venez d'obtenir un certain degré de choix sur ce genre de problèmes que vous obtenez. Comme indiqué dans l'introduction, si vous souhaitez vous connecter RabbitMQ grappes plus généralement des liens peu fiables, vous devez utiliser de la fédération ou de la pelle.

    Avec cela dit, vous pourriez souhaiter pour choisir un mode de récupération comme suit:

    • ignorer
      Votre réseau est vraiment fiable. Tous les nœuds sont dans un rack, connecté à un commutateur, et que le commutateur est aussi la voie vers le monde extérieur. Vous ne voulez pas courir le risque de tout de votre cluster arrêt si aucune autre partie ne parvient pas (ou que vous avez un cluster à deux nœuds).

    • pause_minority
      Votre réseau est peut-être moins fiable. Vous disposez de cluster à travers les 3 AZs dans EC2, et l'on suppose qu'un seul AZ échouera à la fois. Dans ce scénario, vous voulez les deux autres AZs pour continuer le travail et les nœuds de l'échec de l'AZ pour rejoindre automatiquement et sans chichi quand l'AZ est de retour.

    • autoheal
      Votre réseau peut ne pas être fiable. Vous êtes plus préoccupé par la continuité de service qu'avec l'intégrité des données. Vous pouvez avoir un cluster à deux nœuds.

    Cette réponse est la ref de rabbitmq docs.
    https://www.rabbitmq.com/partitions.html vous donnera une description plus détaillée.