Este artículo presenta principalmente el conocimiento relevante del conjunto de réplicas de MongoDB, que se mejorará continuamente en el futuro.
1. Composición e introducción del conjunto de réplicas
Por lo tanto, el conjunto de réplicas es el mismo almacenamiento de redundancia de datos, que generalmente se usa para garantizar una alta disponibilidad. La siguiente figura muestra el diagrama de arquitectura del conjunto de réplicas de MongoDB:
( 1) Un conjunto de réplicas es un grupo de instancias de mongod que mantienen el mismo conjunto de datos ( mongod : una instancia de máquina que implementa mongodb ) ;
(2) Composición del conjunto de réplicas de MongoDB. Un conjunto de réplicas incluye múltiples nodos portadores de datos y un nodo árbitro ( opcional ) . Uno y solo un miembro entre los nodos portadores de datos se considera como el nodo primario, y los otros nodos se consideran los nodos secundarios. Los nodos de árbitro no transportan datos y se utilizan principalmente para elecciones. El nodo de arbitraje es siempre el nodo de arbitraje, pero el nodo principal puede convertirse en un nodo secundario debido a la elección, y el nodo secundario también puede convertirse en el nodo principal debido a la elección.
(3) Redundancia y alta disponibilidad. La función del conjunto de réplicas es garantizar una alta disponibilidad a través de la redundancia. A través del almacenamiento redundante, el conjunto de réplicas como un todo tiene cierta tolerancia a la falta de disponibilidad de un solo nodo;
(4) Otra función del conjunto de réplicas es implementar la expansión de lectura configurando la estrategia de lectura y escritura ( presentada en la sección de estrategia de lectura y escritura ) .
(5) El nodo principal del conjunto de réplicas recibe todas las operaciones de escritura. El nodo primario registrará las operaciones de cambio de todos los conjuntos de datos a través del registro de operaciones ( oplog ) ( cuando mongodb escribe datos en el nodo primario , también escribirá el oplog en la base de datos local donde se encuentra el nodo primario ) .
Nota: Las solicitudes de escritura se envían directamente al nodo maestro, aunque el nodo esclavo tiene que copiar datos; aún así, el nodo maestro todavía tiene que hacer mucho más que el nodo esclavo. Es decir, es normal que el uso de CPU del nodo primario sea mayor que el del nodo secundario.
2. Análisis de latidos del conjunto de réplicas
Los miembros del conjunto de réplicas de MongoDB perciben el estado de supervivencia de otros nodos a través de los latidos del corazón. Los miembros del conjunto de réplicas generalmente se envían latidos cada 2 segundos, que es lo que normalmente llamamos ping. Por lo general, el nodo se marcará como no disponible si no hay comentarios durante más de 10S. Si el nodo que no ha respondido durante más de 10 segundos es el nodo principal, el nodo secundario activará una elección para volver a votar por el nodo principal para lograr la conmutación por error automática.
Los códigos relevantes se concentran principalmente en:
mongo/db/repl/replication_coordinator_impl_heartbeat.cpp
mongo/src/mongo/db/repl/replication_coordinator_impl.cpp
Los tres puntos clave más importantes de un conjunto de réplicas son: ① sincronización de datos ② conmutación por error ③ opciones de lectura de configuración.
1. Sincronización de datos
Para mantener una copia actualizada del conjunto de datos fragmentado, los nodos secundarios del conjunto de réplicas sincronizarán o replicarán los datos de otros miembros. MongoDB utiliza dos formas de sincronización de datos: una es la sincronización de inicialización, que llena nuevos miembros con conjuntos de datos completos; la otra es la sincronización de cambios en tiempo real con la ayuda de oplog.
1.1 Inicializar sincronización
No presentaré mucho sobre la sincronización de inicialización aquí, pero en realidad es una copia completa.
1.2 Sincronización en tiempo real
La descripción del sitio web oficial sobre Oplog: Oplog del conjunto de réplicas — Manual de MongoDB
1. Introducción a Oplog. Oplog, o registro de operaciones, es una colección de tamaño fijo (colecciones limitadas) que se utiliza para guardar todos los registros de operaciones de datos de la base de datos de Mongodb (en realidad, solo registra los registros de operaciones que cambian los datos de la base de datos, es decir, agregar/eliminar/modificar). Por analogía, es equivalente al registro binlog de mysql.
La existencia de Oplog facilita enormemente la sincronización de datos de cada nodo del conjunto de réplicas de MongoDB.
2. El proceso de sincronización de datos del conjunto de réplicas.
El proceso es más o menos el siguiente: después de que el nodo principal escribe los datos, el nodo secundario verifica la colección oplogt.rs de su base de datos local para averiguar la marca de tiempo del registro más reciente para asegurarse de que sus datos estén lo suficientemente actualizados; luego, consulta el oplog.rs de Pirmary El conjunto encuentra todos los registros mayores que esta marca de tiempo, luego escribe los registros de operación en su propio oplog y ejecuta las operaciones representadas por estos registros . ①Todos los miembros del conjunto de réplicas tendrán una copia del registro de operaciones. ②Cada operación en el registro de operaciones es idempotente, incluso si algunas operaciones se sincronizan dos o más veces, no habrá un impacto negativo. ③Para mejorar la eficiencia de la replicación, todos los nodos en el conjunto de réplicas realizarán la detección de latidos (ping) entre sí, y cada nodo puede obtener oplog de otros nodos. ④ mongodb establece oplog.rs en una colección de tipo limitada, es decir, un tamaño fijo, lo cual es razonable; ⑤ pero para un nodo que ha estado inactivo durante mucho tiempo, el nodo secundario usa su última marca de tiempo para encontrar los oplog.rs del nodo primario En este caso, los datos deben resincronizarse manualmente. ⑥ Se puede ver que el tamaño del oplog es muy importante.
Nota: para las colecciones limitadas, piense en ello como una cola circular. Cuando se agote el espacio de la colección, la inserción de elementos sobrescribirá el elemento principal inicial.
La sincronización maestro-esclavo tiene muchos detalles propios. Pero, en general, extraer el oplog y reproducirlo puede entenderse como un modelo de productor-consumidor de "productor único y consumidores múltiples". Son independientes entre sí y no están bloqueados entre sí en circunstancias normales. En cuanto a los detalles del código, tenga la oportunidad de estudiarlo.
1.3 Análisis del retardo de sincronización
Problema: cuando la carga es demasiado grande, hay un retraso significativo en la sincronización maestro-esclavo de mongodb, lo que a veces hace que no se puedan leer los datos más recientes.
Este tipo de retraso es casi imperceptible en escenarios de uso normal. Por ejemplo, no habrá inconsistencia de datos durante la prueba manual. Además, el monitoreo de retraso maestro-esclavo de Tencent Cloud está muy por debajo del segundo nivel (tal vez solo en el orden de ms) ). Sin embargo, si la carga de escritura es particularmente grande, puede haber una demora más obvia, pero casi no hay demora obvia en nuestro volumen de escritura de 50k/min . Esto no es un problema con mongodb en absoluto , porque la teoría CAP determina que la consistencia, la disponibilidad y la tolerancia de partición solo pueden ser 2 de 3. Para la mayoría de las bases de datos distribuidas, se seleccionan A ( disponibilidad ) y P ( tolerancia de partición ) . Abandone C (consistencia) en favor de una consistencia eventual menos exigente.
Nota: C (consistencia) en la teoría CAP se refiere a la consistencia lineal (consistencia fuerte), que corresponde a la consistencia eventual (consistencia débil).
Además de la consistencia de datos en diferentes aspectos de maestro y esclavo, mongodb también tiene consistencia de datos en lectura y escritura, y consistencia de datos en dimensiones de memoria/disco. Siento que puedo hablar de ello.
3. El tamaño predeterminado del Oplog
Cuando inicia el miembro del conjunto de réplicas por primera vez, si no especifica el registro de operaciones, mongodb creará automáticamente un registro de operaciones con un tamaño predeterminado. Para los sistemas Unix y Windows, el tamaño del registro de operaciones predeterminado depende del motor, de la siguiente manera:
| Motor de almacenamiento | Tamaño predeterminado de registro de operaciones | Límite inferior | Límite superior |
|---|---|---|---|
| En memoria | 5% de la memoria física | 50 MB | 50GB |
| tigre con cable | 5% de espacio libre en disco | 990 MB | 50GB |
| MMAPv1 | 5% de espacio libre en disco | 990 MB | 50GB |
En la mayoría de los casos, el tamaño de registro de operación predeterminado es suficiente. Por ejemplo, si el registro de operaciones ocupa el 5 % del espacio disponible en el disco y se llena en 24 horas de funcionamiento, el nodo de réplica puede alcanzar las 24 horas sin copiar datos del registro de operaciones y no afectará la sincronización final (como el tiempo de inactividad del nodo de réplica) . La mayoría de los conjuntos de réplicas son mucho menos intensivos en operaciones, y sus registros de operaciones pueden contener muchos más.
Por lo general, si existen las siguientes operaciones en el sistema, puede ser necesario establecer un valor de Oplog mayor para evitar la pérdida de datos.
①Actualizar una gran cantidad de datos a la vez ②Eliminar un campo e insertar aproximadamente la misma cantidad de datos ③Actualizar una gran cantidad de datos existentes
4. Comandos comunes de oplog
(1) Ver el estado del registro de operaciones:
rs.printReplicationInfo()
(2) Ver el tamaño de la configuración de almacenamiento de oplog
uso local
db.oplog.rs.stats().maxSize
(3) Ver el tamaño máximo del registro de operaciones, el tamaño ocupado actual y la duración de la grabación
db.getReplicationInfo()
(4) Cambiar el tamaño de Oplog de los miembros del conjunto de réplicas
db.adminCommand({replSetResizeOplog: 1, tamaño: 15000})
punto importante:
(1) Bajo la arquitectura fragmentada, los mongos no pueden ver el registro de operaciones, pero podemos ir a cada instancia de mongod para verlo.
Además, muchos de los comandos anteriores no se pueden usar en una sola instancia de mongo (lo que indica que no se ha detectado ningún conjunto de réplicas).
Modo de juego similar a:
Cómo jugar en redis:
De hecho, esta jugabilidad y la persistencia AOF de redis son completamente la misma idea. La persistencia AOF es registrar las operaciones de modificación de datos procesadas por el servidor en forma de registros y registrarlos; en caso de que redis se cuelgue para la recuperación de datos, primero restaure RDB persistencia El binario descargado se comprime y almacena, y luego se usa como una oportunidad para reproducir las operaciones de escritura, adición, eliminación y cambio.
Cómo jugar en mysql:
Se puede decir que binlog de registro binario de MySQL es el registro más importante de MySQL. Registra todas las declaraciones DDL y DML (excepto las declaraciones de consulta de datos select, show, etc.) en forma de eventos, y también incluye el tiempo consumido por la ejecución de la declaración. MySQL El registro binario es seguro para transacciones. El objetivo principal del binlog es la replicación y la recuperación. Los dos escenarios de uso más importantes de los registros de Binlog
①Replicación de maestro-esclavo de MySQL: la replicación de MySQL abre binlog en el lado del maestro, y el maestro pasa sus registros binarios a los esclavos para lograr el propósito de coherencia de datos maestro-esclavo
②Recuperación de datos : use la herramienta mysqlbinlog para hacer recuperación de datos