Mongo DB-Replikat im Status WIEDERHERSTELLEN blockiert

Wir haben ein Replikat-Set erstellt und jetzt besteht das Problem darin, dass 2 Mitglieder des Replikat-Sets [3 Mitglieder-Set] sich nach 48 Stunden im Wiederherstellungsmodus befinden. Anfänglich nahm die Größe der wiederhergestellten Knoten zu, und jetzt hat auch dies aufgehört. Bei der Wiederherstellung von Knoten bleiben sie also nach 90 GB Daten mit mehr als 60 GB lokalen Daten stecken.

Wie verlasse ich diesen Modus?

replication mongodb restore

— Avinash Sahu
quelle

Antworten:

Der einfache, wenn auch etwas unsichere Weg

Stoppen Sie die erste sekundäre
Löschen Sie den Inhalt davon dbpath
Starten Sie die sekundäre neu
Warten Sie, bis es die primäre eingeholt hat
Wiederholen Sie den Vorgang mit der zweiten Sekundärseite

Dies ist etwas unsicher, da nicht bekannt ist, warum die Secondaries in den Wiederherstellungsstatus versetzt wurden.

Der sicherere, aber auch aufdringlichere Weg

Wie oben, aber beenden Sie Ihre Bewerbung während des Vorgangs. Dies verhindert, dass Ihre Anwendung mehr Daten einfügt, als die sekundären Systeme replizieren können. Das Problem kann jedoch während der Produktion auftreten.

Der sicherste, aber auch aufdringlichste Weg

Fahren Sie den gesamten Replikatsatz herunter
Entfernen Sie den Inhalt dbpathauf beiden Sekundär
Kopieren Sie den Inhalt der dbpathbeiden Secondariesdbpath
Starten Sie die alte Grundschule.
Starten Sie einen der alten Secondaries.
Warten Sie, bis eine neue Grundschule gewählt ist.
Starten Sie die verbleibende sekundäre.

Einige Notizen:

Verwenden Sie MMS . Es ist kostenlos, einfach einzurichten und bietet Ihnen gute Informationen zu Ihrem Replikatsatz. Versuchen Sie, den Wert für "Replikationsverzögerung" bei 0 zu halten, und treffen Sie alle erforderlichen Maßnahmen, damit Ihre Replikationsverzögerung niemals größer als das "Replikations-Oplog-Fenster" ist.

Stellen Sie immer sicher, dass Sie über ein 1-Gbit-Netzwerk und eine (entschuldigende) Menge an RAM verfügen. Je mehr desto besser. Zusätzliche Faustregel: Lieber die Hälfte des Arbeitsspeichers und der SSDs als das Doppelte des Arbeitsspeichers und keine SSDs (wobei der Arbeitsspeicher innerhalb angemessener Grenzen bleibt).

Haftungsausschluss: Erstellen Sie immer eine Sicherungskopie der Produktionsdaten, bevor Sie damit experimentieren.

— Markus W. Mahlberg
quelle

Derzeit befindet sich kein sekundärer Knoten im Replikatsatz. Einer befindet sich im PRIMARY-Modus und zwei andere befinden sich im RECOVERING-Modus.

— Avinash Sahu

Logische Secondaries also. Der Prozess ist der gleiche.

— Markus W Mahlberg

Ich habe viele Male versucht, die Mongo-Instanz zu starten und erneut zu synchronisieren, jedes Mal, wenn sie beginnt, die Daten auf einen anderen Knoten zu kopieren, bis eine feste Größe (~ 96 GB) erreicht ist und dann hängen bleibt. Hat oplog size etwas damit zu tun?

— Avinash Sahu

Nicht wirklich, außer dass die Resynchronisierung möglicherweise beendet wird, wenn Sie mehr Daten einfügen, als das Oplog während der ersten Resynchronisierung aufnehmen kann. Nehmen Sie in diesem Fall Option 2 oder 3.

— Markus W Mahlberg

Können Sie das etwas näher erläutern? "Lieber die Hälfte des Arbeitsspeichers und der SSDs als das Doppelte des Arbeitsspeichers und keine SSDs (wobei der Arbeitsspeicher innerhalb angemessener Grenzen bleibt)."

— Stephen Nguyen

Der Replikationsprozess schlägt fehl, selbst wenn Sie von einem neuen Datenbankpfad auf der Sekundärseite aus neu beginnen. Sie müssen also einige Änderungen im Oplog vornehmen . Die Größe des Oplogs muss auf einen optimalen Wert festgelegt werden, damit es alle Anwendungsschreibvorgänge verarbeiten kann.

Erhöhen der Oplog-Größe:

Fahren Sie den Primärserver herunter

use admin

db.shutdownServer()

Starten Sie primary als Standalone und führen Sie es auf einem anderen Port aus, beispielsweise 37017

Loggen Sie sich im Mongo in Port 37017 ein

mongo --port 37017

Entfernen Sie den alten Inhalt in der lokalen Datenbank

Aus Sicherheitsgründen sollten Sie vor dem Fallenlassen einen alten Oplog-Backop verwenden

mongodump --db local --collection 'oplog.rs' --port 37017

Löschen Sie den alten Inhalt in der lokalen Datenbank

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

Die Replset-Sammlung kann nicht gelöscht werden. Entfernen Sie sie daher mit der erforderlichen ID:

db.system.replset.remove({ "_id" : "your_replsetname"})

Erstellen Sie ein neues Oplog mit der erforderlichen Größe, beispielsweise 50 GB

db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )

Sie können auch die Oplog-Größe in MB in der Datei mongod.conf angeben, z. B. für 50 GB die Größe von 429496 MB

replication:
   oplogSizeMB: 429496

Hoffe das hilft !!!

Bearbeiten:

Wie von Nicholas Tolley Cottrell in Kommentaren erwähnt. In der MongoDB Version 3.6 wir die Oplog-Größe zur Laufzeit ohne Neustart ändern.

Überprüfen Sie die aktuelle Oplog-Größe

use local
db.oplog.rs.stats().maxSize

So ändern Sie die Oplog-Größe auf 10 GB

db.adminCommand({replSetResizeOplog: 1, size: 10000})

— JERRY
quelle

Die obigen Angaben sind zum 3.6. Nicht mehr aktuell. Sie können jetzt die Größe des Oplogs ändern, ohne Inhalte löschen oder Knoten neu starten zu müssen: docs.mongodb.com/manual/tutorial/change-oplog-size

— Nicholas Tolley Cottrell

@NicholasTolleyCottrell ja, ich habe die Antwort bearbeitet.

— JERRY