Mongo DB Replica impostato bloccato nello stato RECOVERING

Abbiamo creato un set di repliche e ora il problema è che 2 membri del set di repliche [set di 3 membri] sono in modalità di ripristino da 48 ore. Inizialmente la dimensione dei nodi di recupero era in aumento e ora anche quello si è fermato. Quindi nel recupero dei nodi sono bloccati dopo 90 GB di dati con oltre 60 GB di dati locali.

Come uscire da questa modalità?

Il modo semplice, anche se un po 'insicuro

1. Ferma il primo secondario
2. Elimina il contenuto di esso dbpath
3. Riavvia il secondario
4. Aspetta che raggiunga il primario
5. Ripetere il processo con il secondo secondario

Questo è un po 'insicuro in quanto non è noto il motivo per cui i secondari sono entrati nello stato di recupero.

Il modo più sicuro, ma anche più invadente

Come sopra, ma interrompi l'applicazione durante il processo. Ciò impedisce la possibilità che l'applicazione stia inserendo più dati di quanti i secondari siano in grado di replicare. Tuttavia, il problema può verificarsi durante la produzione.

Il modo più sicuro, ma anche più invadente

1. Chiudere l'intero set di repliche
2. Rimuovere il contenuto di dbpathsu entrambi i secondari
3. Copia il contenuto di dbpathentrambi i secondaridbpath
4. Inizia il vecchio primario.
5. Inizia una delle vecchie secondarie.
6. Attendere fino a quando viene eletto un nuovo primario.
7. Inizia il rimanente secondario.

Alcune note:

Usa MMS . È gratuito, è facile da configurare e ti dà buone informazioni sul tuo set di repliche. Cerca di mantenere il valore di "ritardo di replica" intorno a 0 e prendi tutti i mezzi necessari affinché il tuo ritardo di replica non sia mai maggiore della "finestra di dialogo di replica".

Assicurati sempre di avere una rete da 1 Gb e uno shitload (scusate) di RAM. Più è, meglio è. Regola aggiuntiva: piuttosto metà della RAM e SSD rispetto al doppio della RAM e nessun SSD (con RAM che rimane entro limiti ragionevoli).

Dichiarazione di non responsabilità: eseguire sempre un backup dei dati di produzione prima di giocherellare con esso.

Il processo di replica ha esito negativo anche se si avvia scratch da un nuovo dbpath sul secondario, quindi è necessario apportare alcune modifiche all'oplog . La dimensione dell'oplog deve essere impostata su un valore ottimale in modo che sia in grado di gestire tutte le scritture dell'applicazione in esso.

Aumento della dimensione dell'oplog:

Arrestare il server primario

use admin

db.shutdownServer()

Inizia primario come standalone ed esegui su porta diversa diciamo 37017

Accedi a mongo nella porta 37017

mongo --port 37017

Rimuovere i vecchi contenuti nel database locale

Per motivi di sicurezza, fai una scorta di vecchi oplog prima di lasciarli cadere

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

Rilascia i vecchi contenuti nel database locale

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

Non è possibile eliminare la raccolta di sostituzioni, quindi rimuoverla con l'id richiesto:

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

Crea un nuovo oplog delle dimensioni richieste, ad esempio 50 GB

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

Inoltre è possibile specificare la dimensione dell'oplog in MB nel file mongod.conf, ad esempio per 50 GB 429496 MB

replication:
   oplogSizeMB: 429496

Spero che sia di aiuto !!!

Modificare:

Come menzionato da Nicholas Tolley Cottrell nei commenti. In MongoDB versione 3.6 possiamo modificare le dimensioni dell'oplog in fase di esecuzione senza riavvio.

Controlla le dimensioni oplog correnti

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

Per modificare la dimensione dell'oplog in 10 GB

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