¿Qué es la replicación de cadenas?
Cuando hablamos de replicación, nos referimos al proceso de hacer copias redundantes de datos para cumplir con los criterios de diseño sobre disponibilidad de datos. La replicación en cadena, por lo tanto, se refiere a la ordenación lineal de los servidores MongoDB para formar una cadena sincronizada. La cadena contiene un nodo principal, seguido de servidores secundarios dispuestos linealmente. Como sugiere la palabra cadena, el servidor más cercano al servidor principal se replica desde él, mientras que todos los demás servidores secundarios posteriores se replican desde el servidor MongoDB secundario anterior. Esta es la principal diferencia entre la replicación encadenada y la replicación normal. La replicación encadenada se produce cuando un nodo secundario selecciona su destino mediante el tiempo de ping o cuando el nodo más cercano es un secundario. Aunque la replicación en cadena, tal como aparece, reduce la carga en el nodo principal, puede causar un retraso en la replicación.
¿Por qué utilizar la replicación en cadena?
Las infraestructuras del sistema a veces sufren fallas impredecibles que conducen a la pérdida de un servidor y, por lo tanto, afectan la disponibilidad. La replicación garantiza que las fallas impredecibles no afecten la disponibilidad. La replicación permite además la recuperación de fallas de hardware e interrupciones del servicio. Tanto la replicación encadenada como la no encadenada cumplen este propósito de garantizar la disponibilidad a pesar de las fallas del sistema. Habiendo establecido que la replicación es importante, puede preguntarse por qué usar la replicación en cadena en particular. No hay diferencia de rendimiento entre la replicación encadenada y no encadenada en MongoDb. En ambos casos, cuando falla el nodo primario, los servidores secundarios votan por un nuevo primario activo y, por lo tanto, la escritura y la lectura de datos no se ven afectadas en ambos casos. Sin embargo, la replicación encadenada es el tipo de replicación predeterminado en MongoDb.
Cómo configurar una réplica en cadena
De forma predeterminada, la replicación encadenada está habilitada en MongoDB. Por lo tanto, desarrollaremos el proceso de desactivación de la replicación de la cadena. La razón principal por la que se puede desactivar la replicación en cadena es si está provocando un retraso. Sin embargo, el mérito de la replicación de la cadena es superior al demérito del retraso y, por lo tanto, en la mayoría de los casos es innecesario desactivarlo. En caso de que la replicación en cadena no esté activa de manera predeterminada, los siguientes comandos lo ayudarán a activarla.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Este proceso es reversible. Cuando se le obliga a desactivar la replicación en cadena, se sigue religiosamente el siguiente proceso.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Consejos y trucos para la replicación de cadenas
La limitación más terrible de la replicación en cadena es el retraso de la replicación. El retraso de la replicación hace referencia al retraso que se produce entre el momento en que se realiza una operación en el principal y cuando se replica la misma operación en el secundario. Aunque es naturalmente imposible, siempre se desea que la velocidad de replicación sea muy alta en que el retraso de replicación sea cero. Para evitar o minimizar el retraso de la replicación para que sea cercano a cero, es un criterio de diseño prudente utilizar hosts primarios y secundarios con las mismas especificaciones en términos de CPU, RAM, E/S y especificaciones relacionadas con la red.
Aunque la replicación en cadena garantiza la disponibilidad de los datos, la replicación en cadena se puede utilizar junto con el registro en diario. El registro en diario proporciona seguridad de los datos al escribir en un registro que se descarga periódicamente en el disco. Cuando los dos se combinan, se escriben tres servidores por solicitud de escritura, a diferencia de la replicación en cadena sola, donde solo se escriben dos servidores por solicitud de escritura.
Otro consejo importante es usar w con replicación. El parámetro w controla la cantidad de servidores en los que se debe escribir una respuesta antes de devolver el éxito. Cuando se establece el parámetro w, getlasterror verifica el registro de operación de los servidores y espera hasta que se aplique la operación al número dado de servidores 'w'.
El uso de una herramienta de monitoreo como MongoDB Monitoring Service (MMS) o ClusterControl le permite obtener el estado de sus nodos de réplica y visualizar los cambios a lo largo del tiempo. Por ejemplo, en MMS, puede encontrar gráficos de retraso de réplica de los nodos secundarios que muestran la variación en el tiempo de retraso de replicación.
Medición del rendimiento de la replicación de la cadena
A estas alturas ya sabe que el parámetro de rendimiento más importante de la replicación en cadena es el tiempo de retraso de la replicación. Por lo tanto, discutiremos cómo probar el período de retraso de la replicación. Esta prueba se puede realizar a través del script de shell MongoDb. Para hacer una prueba de retraso de replicación, comparamos el registro de operaciones del último evento en el nodo principal y el registro de operaciones del último evento en el nodo secundario.
Para verificar la información del nodo principal, ejecutamos el siguiente código.
db.printSlaveReplicationInfo()El comando anterior proporcionará información sobre todas las operaciones recientes en el nodo principal. Los resultados deberían aparecer a continuación.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Habiendo obtenido el oplog para el nodo primario, ahora estamos interesados en el oplog para el nodo secundario. El siguiente comando nos ayudará a obtener el oplog.
db.printReplicationInfo()Este comando proporcionará una salida con detalles sobre el tamaño del registro de operaciones, la longitud del registro, la hora del primer evento del registro de operaciones, la hora del último evento del registro de operaciones y la hora actual. Los resultados aparecen a continuación.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Desde el registro de operaciones del servidor principal, la última sincronización se produjo el martes 05 de marzo de 2013 a las 07:48:19 GMT-0800 (PST). Del oplog del servidor secundario, la última operación ocurrió el martes 05 de marzo de 2013 07:48:19 GMT-0800 (PST). El retraso de la replicación fue cero y, por lo tanto, nuestro sistema replicado en cadena está funcionando correctamente. Sin embargo, el tiempo de demora de la replicación puede variar según la cantidad de cambios que deben replicarse.
