El problema (lo más probable)
La última operación en el primario es de "2015-05-15T02:10:56Z", mientras que la última operación del secundario es de "2015-05-14T11:23:51Z", que es una diferencia de aproximadamente 15 horas. Esa ventana bien puede exceder su ventana de registro de operación de replicación (la diferencia entre el tiempo de la primera y la última entrada de operación en su registro de operación). En pocas palabras, hay demasiadas operaciones en el primario para que el secundario se ponga al día.
Un poco más elaborado (aunque simplificado):durante una sincronización inicial, los datos de la sincronización secundaria son los datos de un punto dado en el tiempo. Cuando los datos de ese punto en el tiempo se sincronizan, el secundario se conecta al oplog y aplica los cambios que se realizaron entre dicho punto en el tiempo y ahora de acuerdo con las entradas del oplog. Esto funciona bien siempre que el registro de operaciones mantenga todas las operaciones entre el momento mencionado. Pero el registro de opciones tiene un tamaño limitado (es lo que se llama una colección limitada
). Por lo tanto, si se están realizando más operaciones en el principal de las que puede contener el registro de operaciones durante la sincronización inicial, las operaciones más antiguas "se desvanecen". El secundario reconoce que no están disponibles todas las operaciones necesarias para "construir" los mismos datos que el principal y se niega a completar la sincronización, permaneciendo en RECOVERY modo.
La(s) solución(es)
El problema es conocido y no un error, sino el resultado del funcionamiento interno de MongoDB y varias suposiciones a prueba de fallas hechas por el equipo de desarrollo. Por lo tanto, hay varias maneras de lidiar con la situación. Lamentablemente, dado que solo tiene dos nodos que contienen datos, todos implican tiempo de inactividad.
Opción 1:aumentar el tamaño del registro de operaciones
Este es mi método preferido, ya que trata el problema de una vez por todas. Sin embargo, es un poco más complicado que otras soluciones. Desde una perspectiva de alto nivel, estos son los pasos que debe seguir.
- Apagar el principal
- Cree una copia de seguridad del registro de operaciones mediante el acceso directo a los archivos de datos
- Reiniciar el
mongoden modo independiente - Copiar el oplog actual a una colección temporal
- Eliminar el registro de operaciones actual
- Recrea el oplog con el tamaño deseado
- Vuelva a copiar las entradas de oplog de la colección temporal al nuevo y brillante oplog
- Reiniciar
mongodcomo parte del conjunto de réplicas
¡No olvide aumentar el registro de operaciones del secundario antes de realizar la sincronización inicial, ya que puede convertirse en principal en algún momento en el futuro!
Para obtener más información, lea "Cambiar el tamaño del oplog" en los tutoriales sobre el mantenimiento del conjunto de réplicas .
Opción 2:cerrar la aplicación durante la sincronización
Si la opción 1 no es viable, la única otra solución real es cerrar la aplicación que provoca la carga en el conjunto de réplicas, reiniciar la sincronización y esperar a que se complete. Dependiendo de la cantidad de datos a transferir, calcule con varias horas.
Una nota personal
El problema de la ventana de oplog es bien conocido. Si bien los conjuntos de réplicas y los clústeres fragmentados son fáciles de configurar con MongoDB, se necesita bastante conocimiento y un poco de experiencia para mantenerlos correctamente. No ejecute algo tan importante como una base de datos con una configuración compleja sin conocer los conceptos básicos; en caso de que suceda Algo malo (tm), podría conducir a una situación FUBAR.
