La réplica de Mongo DB está atascada en estado de RECUPERACIÓN

Hemos creado un conjunto de réplica y ahora el problema es que 2 miembros del conjunto de réplica [conjunto de 3 miembros] están en modo de recuperación desde 48 horas. Inicialmente, el tamaño de los nodos en recuperación aumentaba y ahora incluso eso se ha detenido. Entonces, al recuperar los nodos, se atascan después de 90 GB de datos con más de 60 GB de datos locales.

¿Cómo salir de este modo?

La manera fácil, aunque un poco insegura

1. Parar la primera secundaria
2. Eliminar el contenido de su dbpath
3. Reiniciar el secundario
4. Espera a que alcance a la primaria
5. Repita el proceso con el segundo secundario.

Esto es un poco inseguro ya que se desconoce por qué los secundarios ingresaron al estado de Recuperación.

La forma más segura, pero también más intrusiva

Como arriba, pero detenga su solicitud durante el proceso. Esto evita la posibilidad de que su aplicación esté insertando más datos de los que los secundarios pueden replicar. Sin embargo, el problema puede ocurrir durante la producción.

La forma más segura, pero también más intrusiva

1. Cierra todo el conjunto de réplicas
2. Eliminar el contenido del dbpathsobre ambas secundarias
3. Copie el contenido de dbpathambos secundarios 'dbpath
4. Comience la vieja primaria.
5. Comience uno de los antiguos secundarios.
6. Espere hasta que se elija una nueva primaria.
7. Comience el secundario restante.

Algunas notas:

Utiliza MMS . Es gratis, es fácil de configurar y le brinda buena información sobre su conjunto de réplicas. Intente mantener el valor de "retraso de replicación" alrededor de 0 y tome todos los medios necesarios para que su retraso de replicación nunca sea mayor que la "ventana de registro de replicación".

Siempre asegúrese de tener una red de 1 Gb y una carga de RAM (perdón). Mientras más, mejor. Regla general adicional: más bien la mitad de la RAM y las SSD que el doble de RAM y ninguna SSD (con RAM restante dentro de límites razonables).

Descargo de responsabilidad: siempre haga una copia de seguridad de los datos de producción antes de jugar con ellos.

El proceso de replicación falla incluso si comienza desde cero desde un nuevo dbpath en el secundario, por lo que la cosa es hacer algunos cambios en el oplog . El tamaño del oplog debe establecerse en un valor óptimo para que pueda manejar todas las escrituras de aplicaciones en él.

Aumento del tamaño del oplog:

Apagar el servidor primario

use admin

db.shutdownServer()

Inicie primario como independiente y ejecute en un puerto diferente, digamos 37017

Inicie sesión en mongo en el puerto 37017

mongo --port 37017

Eliminar el contenido anterior en la base de datos local

Por seguridad, coloque una copia de seguridad del viejo oplog antes de soltar

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

Descarte los contenidos antiguos en la base de datos local

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

La colección Replset no se puede descartar, así que elimínela con la identificación requerida:

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

Cree un nuevo oplog del tamaño requerido, digamos 50 GB

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

También puede especificar el tamaño de oplog en MB en el archivo mongod.conf, digamos por 50 GB sus 429496 MB

replication:
   oplogSizeMB: 429496

Espero que esto ayude !!!

Editar:

Como mencionó Nicholas Tolley Cottrell en los comentarios. En la versión 3.6 de MongoDB podemos cambiar el tamaño de oplog en tiempo de ejecución sin reiniciar.

Verifique el tamaño actual del registro

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

Para cambiar el tamaño del oplog a 10 GB

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