Replicación en MongoDB (1 parte)

A partir de ahora incluiremos una serie de entradas para explicar como MongoDB permite replicar datos entre instancias secundarias.

Estos miembros secundarios pueden cumplir diferentes funciones dentro del ecosistema de replicación (se explicaran mas abajo).

El mecanismo o fichero donde se guardan todos los cambios del servidor primario para ser replicados se llama Oplog  y envía estos datos de forma asincrona.

Su tamaño puede ser cambiado con la opción  oplogSize, pero es recomendable configurarlo antes de levantar la instancia porque por defecto el proceso mongod lo inicializa con los siguientes tamaños según el sistema donde se encuentre instalado:

• Un tamaño del 5% del total del espacio libre del filesystem en sistemas Linux, Solaris, Freebsd y Windows de 64bits.

• Para MacOS de 64bits se inicializa con un tamaño de 183Mb.

• Y en sistemas de 32bits tan solo con 48Mb.

Se recomienda tener un Oplog lo bastante grande para contener datos durante 24 horas.

Imaginate el hipotetico caso de tener replicas paradas por algun problema en la red que impide la conexión entre ellas, si estas replicas logran conectarse de nuevo dentro de esas 24 horas no hay necesidad de recostruirlas, directamente el primario se encargará de enviar los datos guardados en el oplogs  para su  recuperación.


Véase en bases de datos transaccionales el mismo concepto pero con diferente nombre  master-slaves, multimasters en MySQL y Dataguard en Oracle.

Como comentamos al principio MongoDB tiene diferentes tipos de replicación o miembros secundarios, cada uno de ellos creados para un fin distinto:

• Secondary-Only Members (miembros secundarios): Como su nombre indica, estos nunca serán primarios y están organizados para realizar tareas de secundarios para siempre.

• Hidden Members (miembros ocultos): Son invisibles al cliente, pero tienen la propiedad de convertirse en primarios. Se utilizan para  tareas de reporting, testing y backup.

• Delayed members: En estas instancias se aplican los cambios con un retardo(delayed), ideales para protegerlas de errores humanos, o cambios inesperados que pueden provocar una perdida de efectividad del servicio. Es  ideal para la situación:

   "¡Acabo de cargarme todos los datos, espero aun que no se haya replicado al Deleyed"

• Arbiters: No contienen datos, su principal tarea es la de elegir al futuro primario en el caso de que se produzca un failover automático.

• Non-Voting Members: Difieren de las anteriores en dos puntos, su tarea es la de no votar (en caso de failover) pero si contienen datos.