MongoDB Balancer Timeout mit verzögerter Replikat

Question

Wir haben eine Einrichtung von zwei MongoDB -Scherben. Jeder Shard enthält einen Meister, einen Sklaven, einen 24 -Stunden -Sklavensklaven und einen Schiedsrichter. Der Balancer migriert jedoch keine Scherben, die darauf warten, dass der verzögerte Sklave migriert. Ich habe versucht, _SecondaryThrottle in der Balancer -Konfiguration auf False festzulegen, aber ich habe immer noch das Problem.

Es scheint, dass die Migration für einen Tag weitergeht und dann fehlschlägt (eine Menge Warten auf Sklavennachrichten in den Protokollen). Schließlich gibt es auf und beginnt eine neue Migration. Die Nachricht besagt, dass es auf 3 Sklaven wartet, aber der Verzögerungssklave ist versteckt und Prio 0, also sollte er auf diese warten. Und wenn die _SecondaryThrottle funktioniert, sollte es nicht auf einen Sklaven warten, oder?

Es ist seit ein paar Monaten so, dass die Konfiguration auf allen Mongosen nachgeführt werden sollte. Einige der Mongosen, die den Balancer leiten, waren in letzter Zeit Restarter.

Hat jemand eine Idee, wie man das Problem lösen kann, wir hatten diese Probleme nicht, bevor wir den verspäteten Sklaven begonnen haben, aber es ist nur unsere Theorie.

Konfiguration:

{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }

Protokoll vom Shard1 -Masterprozess:

migrateThread] warning: migrate commit waiting for 3 slaves for 'xxx.xxx' { shardkey: ObjectId('4fd2025ae087c37d32039a9e') } -> {shardkey: ObjectId('4fd2035ae087c37f04014a79') } waiting for: 529dc9d9:7a [migrateThread] Waiting for Replikation zum Aufholen vor dem Eintritt in den kritischen Abschnitt

Protokoll vom Shard2 -Masterprozess:

Di 3. Dezember 14: 52: 25.302 [Conn1369472] Movechunk -Datenübertragung Fortschritt: {aktiv: true, ns: "xxx.xxx", aus: "shard2/mongo2: 27018, mongob2: 27018", min: {shardkey: objektid (objektid (objektid (objektid (ziel '4FD2025AE087C37D32039A9E')}, Max: {ShardKey: ObjectID ('4FD2035AE087C37F04014A79')}, Shardkeypern: {ShardKey: 1,0}, State: "Catchup", Zählung: {Cloned: 2273, 2673, 263, ",", ",", ", zählt: {Cloned: {Cloned: 2273, 2273,", ",", ",", ", {{Cloned: 2273, 2673," State, " 0}, OK: 1.0} Mein Mem verwendet: 0

UPDATE: Ich habe bestätigt, dass das Entfernen von Slavedelay den Balancer wieder zum Arbeiten gebracht hat. Sobald sie sich auf die Geschwindigkeit stiegen, bewegten sich die Brocken. Das Problem scheint also mit dem Slavedelay verbunden zu sein. Ich habe auch bestätigt, dass der Balancer mit "Secondary Throttle" beträgt: Falsch. Es scheint sowieso auf Sklaven zu warten.

Shard2:

TUE 10 11: 44: 25.423 [Migratethread] WARNUNG: Migrate Commit Warten auf 3 Sklaven für 'xxx.xxx' {shardkey: objectId ('4ff1213ee087c3516b2f2f703f')} -> {shardkey: ObjectId ('4ff12a5eddf2b32Dff1: 52A6F089: 81

Di 10. Dezember 11: 44: 26.423 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10. Dezember 11: 44: 27.423 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10. Dezember 11: 44: 28.423 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10 11: 44: 29.424 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10 11: 44: 30.424 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10 11: 44: 31.424 [Migratethread] Warten auf die Replikation, um vor dem Eintritt in den kritischen Abschnitt aufzuholen

Di 10 11: 44: 31.424 [Migratethread] Migrate Commit wurde nachgelassen, um zu Secondaries für 'xxx.xxx' {shardkey: ObjectID ('4ff1213ee087c3516b2f703f')} -> {ShardKey: Objectid ('4ff12a5eddf2b32Dff1In)) (' 4ff12a5EDDF2B32DFF1E7:

Di 10 11: 44: 31.425 [Migratethread] Migrate Commit gespült zum Journal für 'xxx.xxx' {ShardKey: ObjectID ('4ff1213ee087c3516b2f2f703f')} -> {ShardKey: objektid ('4ff12a5eddf2b2b32dff1e7Bea')).

Di 10 11: 44: 31.647 [Migratethread] Migrate Commit wurde nachgelassen, um zu Secondaries für 'xxx.xxx' {shardkey: ObjectID ('4ff1213ee087c3516b2f703f')} -> {ShardKey: Objectid ('4ff12a5EDDF2B32DFF1E7)) (' 4ff12a5EDDF2B32DFF1E7:

Di 10 11: 44: 31.667 [Migratethread] Migrate Commit zum Journal für 'xxx.xxx' {shardkey: objectID ('4ff1213ee087c3516b2f2f703f')} -> {ShardKey: objektid ('4ff12a5eddf2b2b32dff1e7Bea')))).

Answer 1

Der Balancer wartet ordnungsgemäß auf die Mehrheit des Replik -Satzes des Ziels, um die Dokumente zu migrieren, bevor das Löschen dieser Dokumente auf der Quellschard eingeleitet wird.

Das Problem ist, dass Sie vier Mitglieder in Ihrem Replik -Set haben (Master, ein Sklave, ein 24 -Stunden -Sklavenverzögerungssklave und ein Schiedsrichter). Das heißt, drei sind die Mehrheit. Ich bin mir nicht sicher, warum Sie einen Schiedsrichter hinzugefügt haben, aber wenn Sie ihn entfernen, werden zwei die Mehrheit sein und der Balancer muss nicht auf den verspäteten Sklaven warten.

Die alternative Art, dasselbe Ergebnis zu erzielen, besteht darin, den verspäteten Sklaven mit votes:0 Eigentum und verlassen Sie den Schiedsrichter als dritter Wahlknoten.

Answer 2

Welche Version laufen Sie? Es gibt einen bekannten Fehler in 2.4.2 und darunter sowie 2.2.4 und darunter, der eine falsche Anzahl der Sekundärzahlen im Set verursacht (und es macht es daher unmöglich, den Standard zu erfüllen W: Mehrheit Schreiben Sie für die Migration). Dies ist der Fehler (behoben in 2.4.3+ und 2.2.5+):

https://jira.mongodb.org/browse/server-8420

Das Ausschalten der Sekundärdrosselklappe sollte eine gültige Problemumgehung sein, aber Sie möchten vielleicht eine Flushrouterconfig auf jedem mongos Prozesse (oder starten Sie einfach alle neu mongos Prozesse) um sicherzustellen, dass die Einstellung für Ihre Migrationen wirksam wird, insbesondere wenn sie einen Tag zur Zeit dauern. Als ein weiterer potenzieller Fix vor dem Upgrade können Sie auch Lassen Sie die lokale Kollektion fallen (Es wird neu erstellt).