La réplique Mongo DB est bloquée à l'état RECOVERING

Nous avons créé un jeu de réplicas et maintenant le problème est que 2 membres du jeu de répliques [jeu de 3 membres] sont en mode de récupération à partir de 48 heures. Initialement, la taille des nœuds de récupération augmentait et maintenant même cela s'est arrêté. Ainsi, lors de la récupération des nœuds, ils sont bloqués après 90 Go de données avec plus de 60 Go de données locales.

Comment sortir de ce mode?

La manière simple, quoique un peu peu sûre

1. Arrêter le premier secondaire
2. Supprimer le contenu de son dbpath
3. Redémarrez le secondaire
4. Attendez qu'il rattrape le primaire
5. Répétez le processus avec le deuxième secondaire

C'est un peu incertain car on ne sait pas pourquoi les secondaires sont entrés dans l'état de récupération.

La manière la plus sécurisée, mais aussi la plus intrusive

Comme ci-dessus, mais arrêtez votre application pendant le processus. Cela évite la possibilité que votre application insère plus de données que les secondaires ne peuvent répliquer. Cependant, le problème peut se produire pendant la production.

Le moyen le plus sécurisé, mais aussi le plus intrusif

1. Arrêtez l'ensemble de la réplique
2. Supprimer le contenu de dbpathsur les deux secondaires
3. Copiez le contenu de dbpathsur les deux secondairesdbpath
4. Démarrez l'ancien primaire.
5. Démarrez l'un des anciens secondaires.
6. Attendez qu'un nouveau primaire soit élu.
7. Démarrez le secondaire restant.

Quelques notes:

Utilisez MMS . C'est gratuit, il est facile à configurer et il vous donne de bonnes informations sur votre jeu de répliques. Essayez de garder la valeur de «retard de réplication» autour de 0 et prenez tous les moyens nécessaires pour que votre retard de réplication ne soit jamais supérieur à la «fenêtre d'oplog de réplication».

Assurez-vous toujours que vous avez un réseau de 1 Go et une (merde) merde de RAM. Plus c'est mieux. Règle de base supplémentaire: plutôt la moitié de la RAM et des SSD que le double de la RAM et aucun SSD (la RAM restant dans des limites raisonnables).

Avertissement: faites toujours une sauvegarde des données de production avant de les manipuler.

Le processus de réplication échoue même si vous démarrez scratch à partir d'un nouveau dbpath sur le secondaire, le problème est donc de faire quelques changements dans l'oplog . La taille de l'oplog doit être définie sur une valeur optimale afin qu'il puisse gérer toutes les écritures d'application dans celui-ci.

Augmentation de la taille de l'oplog:

Arrêtez le serveur principal

use admin

db.shutdownServer()

Démarrez le primaire en mode autonome et exécutez-le sur un port différent, par exemple 37017

Connectez-vous à Mongo dans le port 37017

mongo --port 37017

Supprimer l'ancien contenu de la base de données locale

Pour plus de sécurité, sauvegardez l'ancien oplog avant de le supprimer

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

Déposez l'ancien contenu dans la base de données locale

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

La collection de replset ne peut pas être supprimée, supprimez-la avec l'ID requis:

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

Créez un nouvel oplog de la taille requise, par exemple 50 Go

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

Vous pouvez également spécifier la taille de l'oplog en Mo dans le fichier mongod.conf, disons pour 50 Go ses 429496 Mo

replication:
   oplogSizeMB: 429496

J'espère que cela t'aides !!!

Éditer:

Comme mentionné par Nicholas Tolley Cottrell dans les commentaires. Dans la version 3.6 de MongoDB , nous pouvons changer la taille d'oplog en runtime sans redémarrer.

Vérifier la taille actuelle de l'oplog

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

Pour modifier la taille de l'oplog à 10 Go

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