¿Por qué está Mongo atascado en STARTUP2?

Tengo un Mongoconjunto de réplicas con algunas secundarias. Un cuadro, que aloja una instancia secundaria, se bloqueó y perdió la base de datos.

Comencé la Mongoinstancia secundaria nuevamente y ahora está atascada en STARTUP2 por más de 12 horas. Tiene sentido ? Los documentos dicen que Mongodebe estar en STARTUP2 por un corto período de tiempo antes de ingresar al estado RECUPERANDO

¿Qué significa exactamente STARTUP2? ¿Está copiando la base de datos de la primaria? ¿Cómo puedo verificarlo (suponiendo que Mongo se esté ejecutando en Linux)?

La respuesta de eoinbrazil es en parte incorrecta. Un nuevo nodo puede estar en STARTUP2 durante mucho tiempo. El enlace publicado dice:

Cada miembro de un conjunto de réplica ingresa al estado STARTUP2 tan pronto como mongod termina de cargar la configuración de ese miembro, momento en el que se convierte en un miembro activo del conjunto de réplica. El miembro decide si realizar o no una sincronización inicial. Si un miembro comienza una sincronización inicial, el miembro permanece en STARTUP2 hasta que se copien todos los datos y se creen todos los índices. Luego, el miembro realiza la transición a RECUPERACIÓN.

Estoy administrando una colección de 700 GB y, cuando agrego un nuevo nodo, el estado STARTUP2 permanece durante más de 24 horas. Pero aún puede ver si está sucediendo algo, observando si la base de datos crece. Puede ver el tamaño de la base de datos en el nuevo nodo con

show databases

o también puede observar el directorio de datos, para ver si aún está creciendo. (en Linux con los comandos ls, df, du, iotop, etc.)

El estado STARTUP2 significa que el nodo no puede votar. Un miembro de un RS ingresa a este estado una vez que el proceso MongoD completa la carga de su configuración. En este estado, el miembro ha creado subprocesos para manejar las operaciones de replicación interna, pero aún tiene que cambiar el estado a Recuperación y luego a Secundario (consulte el [estado y sus detalles en los documentos]) .

Si su nodo ha estado en este estado durante más de un breve período, entonces se encuentra con un comportamiento extraño. Esto es prácticamente imposible de analizar sin los registros para determinar por qué está atascado. La ejecución de rs.status () y db.printSlaveReplicationInfo () le dará algunos detalles sobre la imagen local en el nodo.

El enfoque normal para resolver esto sería apagar el nodo, borrar sus archivos de datos (esos archivos en el dbpath) y reiniciarlo. Esto reiniciará el proceso de sincronización inicial y debería pasar a SECUNDARIO. Si vuelve a atascarse en STARTUP2, tendrá que mirar los registros para recopilar más información sobre por qué: hay una variedad de causas, pero una que puede suceder es una red débil o una contención de recursos locales.

Un punto a tener en cuenta es que, mientras se realiza una sincronización inicial, el nodo permanecerá en STARTUP2, por lo que, dependiendo de la cantidad de datos que se sincronice, esto podría ser una cantidad considerable de tiempo (potencialmente días).

Una posible causa es que su secundaria se vuelva "obsoleta" como se indica aquí .

Cuando vuelva a sincronizar un miembro, asegúrese de que el RS no esté bajo una carga pesada.

El estado STARTUP2 podría deberse a que no hay suficiente espacio en disco. Bueno, como no hay dónde sincronizar, solo puede permanecer en el estado @ STARTUP2.