My Debian 8.9 DRBD 8.4.3 Configuration est d'une certaine mesure dans un état où les deux nœuds ne peuvent plus se connecter sur le réseau. Ils devraient reproduire une seule ressource r1
, mais immédiatement après drbdadm down r1; drbadm up r1
sur les deux nœuds leur /proc/drbd
Décrivez la situation comme suit:
sur le 1er noeud (état de connexion est soit WFConnection
ou StandAlone
):
1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
ns:0 nr:0 dw:0 dr:912 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:20
sur 2e noeud:
1: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:48
Les deux nœuds peuvent ping mutuellement sur les adresses IP citées dans /etc/drbd.d/r1.res
, et netstat
montre que les deux écoutaient sur le port cité.
Comment puis-je (davantage de diagnostiquer et de diagnostiquer et) de sortir de cette situation afin que les deux nœuds puissent devenir connectés et reproduire à nouveau sur DRBD?
BTW, sur un niveau d'abstraction plus élevé, ce problème se manifeste actuellement par systemctl start drbd
Ne jamais sortir, apparemment parce qu'il reste coincé dans drbdadm wait-connect all
(comme suggéré par /lib/systemd/system/drbd.service
).
La situation était apparemment causée par un cas de cerveau de scission.
Je n'avais pas remarqué cela parce que j'avais inspecté seulement les récentes entrées de journal pour drbd.service
(Sudo journalctl -u drbd
), mais le problème a apparemment été signalé dans d'autres journaux du noyau et légèrement plus tôt (Sudo journalctl | grep Split-Brain
).
Avec cela, résolvant manuellement le cerveau fractionné (comme décrit ici ou ici ) a également résolu la situation gênante comme suit.
Sur la victime de la scission-cérébrale (en supposant que la ressource DRBD est r1
):
drbdadm disconnect r1
drbdadm secondary r1
drbdadm connect --discard-my-data r1
Sur le survivant cérébral de scission:
drbdadm disconnect r1
drbdadm primary r1
drbdadm connect r1