MongoDB primärer stepDown ist nicht erfolgreich

Setup: Replikat mit 5 Knoten, Version 3.4.5.MongoDB primärer stepDown ist nicht erfolgreich

Versuch PRIMARY mit rs.stepDown zu schalten (60, 30), sondern immer gleichbleibend den Fehler:

rs0:PRIMARY> rs.stepDown(60, 30) 
{ 
    "ok" : 0, 
    "errmsg" : "No electable secondaries caught up as of 2017-07-11T00:21:11.205+0000. Please use {force: true} to force node to step down.", 
    "code" : 50, 
    "codeName" : "ExceededTimeLimit" 
}

jedoch rs.printSlaveReplicationInfo() in einem parallel laufenden Terminal bestätigt, dass alle Repliken bis vollständig gefangen :

rs0:PRIMARY> rs.printSlaveReplicationInfo() 
source: X.X.X.X:27017 
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC) 
    0 secs (0 hrs) behind the primary 
source: X.X.X.X:27017 
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC) 
    0 secs (0 hrs) behind the primary 
source: X.X.X.X:27017 
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC) 
    0 secs (0 hrs) behind the primary 
source: X.X.X.X:27017 
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC) 
    0 secs (0 hrs) behind the primary

Mache ich etwas falsch?

UPD: Ich habe lange überprüft Operationen vor und während rs.stepDown läuft wie es unten vorgeschlagen, und es sieht wie folgt aus:

# Before rs.stepDown 
$ watch "mongo --quiet --eval 'JSON.stringify(db.currentOp())' | jq -r '.inprog[] | \"\(.secs_running) \(.desc) \(.op)\"' | sort -rnk1" 
984287 rsSync none 
984287 ReplBatcher none 
67 WT RecordStoreThread: local.oplog.rs none 
null SyncSourceFeedback none 
null NoopWriter none 
0 conn615153 command 
0 conn614948 update 
0 conn614748 getmore 
... 

# During rs.stepDown 
984329 rsSync none 
984329 ReplBatcher none 
108 WT RecordStoreThread: local.oplog.rs none 
16 conn615138 command 
16 conn615136 command 
16 conn615085 update 
16 conn615079 insert 
...

Grundsätzlich lange laufen scheinen Benutzeroperationen als Folge passieren von rs.stepDown() als secs_running wird nicht null, sobald PRIMARY versucht, umzuschalten und weiter bis zum stepDown scheitert. Dann wird alles wieder normal.

Irgendwelche Ideen, warum das passiert und ob das überhaupt normal ist?

Quelle

2017-07-11 Dmitry

Diese Frage ist nicht [zum Thema StackOverflow] (https://stackoverflow.com/help/on-topic) und gehört zu DBA StackExchange. Die zugehörige Frage enthält tatsächlich alle erforderlichen Kontextinformationen zu Ihrer Umgebung: [MongoDB legt beim Herunterfahren auf] (https://dba.stackexchange.com/questions/179616/mongodb-hangs-up-on-shutdown/180379). – Stennie

** Dieses Problem wurde in der Version 3.4.6 behoben. ** Siehe [diese Frage] (https://dba.stackexchange.com/questions/179616/mongodb-hangs-up-on-shutdown/180379) für mehr Kontext. – Dmitry

Before stepping down, rs.stepDown() will attempt to terminate long running user operations that would block the primary from stepping down, such as an index build, a write operation or a map-reduce job.

Haben Sie einige lange laufende Jobs zu gehen? Überprüfen Sie db. Überprüfen Sie das Ergebnis von db.currentOp()

Sie können versuchen, eine längere Zeit für das Herunterstufen einzustellen rs.stepDown(60, 360).

Quelle

2017-07-11 06:43:42 JJussi

Danke für die schnelle Antwort! Ich habe lange laufende Operationen während 'rs.stepDown' überprüft und die Frage aktualisiert. Wie auch immer, basierend auf dem, was ich sehe, scheint es nicht so zu sein, dass man in diesem Fall die Zeit für das Herunterstufen erhöhen kann ... – Dmitry

Wie viele Knoten haben Sie in Ihrem Replikat-Set vollständig? Wenn Sie mongod.log während des Abstiegs beobachten (tail -f), was erklärt es über den Grund, warum das Absetzen fehlgeschlagen ist? – JJussi

Es gibt insgesamt 5 Knoten. Log ist in diesem Fall nicht sehr informativ: es sagt nur "Versuch, als Reaktion auf den replSetStepDown-Befehl zurückzutreten", dann eine Reihe von "end connection"/"connection accepted" -Meldungen, und wenn das Timeout abgelaufen ist, kehrt MongoDB einfach zur Verarbeitung zurück Abfragen. Ich denke, eine Erhöhung des Logging-Levels könnte hier möglicherweise mehr Farbe hinzufügen. Aber da das primäre nicht normal umschaltet, bin ich mir nicht sicher, ob es ein sicheres System ist, wenn es dazu gezwungen wird. Was würdest du vorschlagen? – Dmitry

Um die Schleife bei dieser Frage zu schließen, wurde festgestellt, dass die fehlgeschlagene Abwärtsbewegung auf die Zeit zurückzuführen war, die auf dem Host zurückging.

MongoDB 3.4.6 ist resistenter gegenüber Zeitproblemen auf dem Host, und ein Upgrade der Implementierung behebt die Blockierungsprobleme.

Quelle

2017-07-21 00:35:59

MongoDB primärer stepDown ist nicht erfolgreich

Antwort

Verwandte Themen