Implementación de copias de seguridad distribuidas de MongoDB sin el coordinador

Antes de la versión 1.0, Percona Backup for MongoDB (PBM) tenía un demonio de coordinación separado como parte clave de su arquitectura. El coordinador manejó todas las comunicaciones con los agentes de rescate y el programa de control. Mantuvo una lista de configuraciones y copias de seguridad de PBM, tomó una decisión sobre qué agentes deberían hacer una copia de seguridad o restauración, y aseguró puntos de copia de seguridad y restauración consistentes en todos los fragmentos.

Tener una única fuente de verdad dedicada puede simplificar la comunicación y la toma de decisiones. Sin embargo, aporta una complejidad adicional al sistema de otras maneras (una parte más del sistema para mantenerse al día con el protocolo de comunicación, etc.). Más importante aún, se convierte en un punto único de fallo. Así que decidimos eliminar al coordinador en la versión 1.0.

Desde la versión 1.0, hemos utilizado MongoDB por sí mismo como un centro de comunicación y configuración y otro almacenamiento de datos de respaldo. Elimina una capa adicional de comunicación del sistema (en nuestro caso, gRPC) y nos brinda un almacenamiento distribuido duradero. Entonces ya no tenemos que mantener estas cosas. ¡Frio!

¿Copia de seguridad y restauración sin un coordinador?

¿Cómo podemos hacer copias de seguridad y restaurar sin el coordinador? ¿Quién va a tomar decisiones sobre en qué nodo del sector de la réplica realizar la copia de seguridad? ¿Y quién garantizará puntos de seguridad consistentes en todos los fragmentos del grupo?

Parece que necesitamos un jefe de todos modos. ¿O nosotros? Miremos más de cerca.

De hecho, podemos dividir este problema en dos niveles. Primero, tomaremos decisiones sobre qué nodo entre el sector de replicación debe estar a cargo de la operación (copia de seguridad, restauración, etc.). Y segundo, esa guía para el conjunto de réplicas tendrá una función adicional para garantizar la consistencia del clúster en el caso de un clúster fragmentado.

El segundo es más fácil. Dado que el clúster fragmentado debe tener el una y solo una réplica del conjunto del servidor de configuración de todos modosPodemos estar de acuerdo en que uno de sus miembros siempre debe estar a cargo de las operaciones en el clúster.

Entonces un problema se resuelve, otro para ir.

¿Cómo se elige un diputado para un conjunto de réplicas? La respuesta algo obvia es elegir un líder entre los nodos de replicación y dejar que el líder decida los pasos a seguir. Podemos usar algún software como Apache ZooKeeper para esto, pero tiene un componente pesado y una dependencia externa al sistema que queremos evitar. O podemos usar algunos algoritmos de consenso distribuido como paxos o Balsa. Un líder puede ser elegido primero y asumir la responsabilidad de las operaciones (copia de seguridad, restauración, etc.). En tal caso, deberíamos poder solucionarlo cuando el jefe falle: detectarlo, reelegir un nuevo jefe, etc. O podemos ejecutar el proceso de elección en cada solicitud de operación. Pero sí significa una rutina adicional y el tiempo que se pasa antes de iniciar la operación (lo cual no es realmente un gran problema considerando la frecuencia habitual de las operaciones de guardar/restaurar y algunos viajes de ida y vuelta adicionales a la red parecen no ser nada intermedio). propia operación de rescate/restauración.).

Pero, ¿podemos evitar unas elecciones generales? Sí, y esto es lo que hacemos. Cuando el comando de la operación es emitido por el programa de control de seguridad, se envía a cada agente de seguridad. Luego, el agente verifica si el nodo al que está conectado es adecuado para el trabajo (tiene un retraso de replicación aceptable, el secundario es el preferido para las copias de seguridad, etc.) y, de ser así, el agente intenta obtener un bloqueo para esta operación. . Y si lo conseguía, seguiría adelante y se convertiría en el responsable del conjunto de réplicas para este trabajo. Todos los demás agentes que no pudieron obtener un bloqueo simplemente se saltearon este trabajo. De hecho, matamos dos pájaros de un tiro, ya que necesitamos tener algún mecanismo incluso para evitar que dos o más copias de seguridad y/o restauraciones funcionen simultáneamente.

Lo último a considerar es cómo hacemos realmente la cadena de bloques. lo usamos Índices únicos de MongoDB.

En primer lugar, cuando se inicia PBM en el nuevo clúster, automáticamente crea colecciones internas. Uno de ellos es admin.pbmLock con la limitación de índice único para el campo «represt». Entonces, más adelante, cuando los agentes que actúan en nombre del conjunto de réplicas intentan obtener un bloqueo, solo uno puede tener éxito.

A continuación se muestra un código simplificado de PBM (usamos el oficial) Controlador MongoDB Go).

Cree una nueva colección con el índice único:

Una alternativa a los índices únicos para fines de cierre podría ser actas. Pero las transacciones se han introducido en MongoDB 4.0 y estamos obligados a admitir una versión 3.6 ampliamente utilizada.

En breve

Lo que buscamos es una solución que resuelva problemas complejos de forma sencilla pero a la vez eficaz. Reducir la complejidad simplifica el soporte y el desarrollo y deja menos espacio para los errores. Y a pesar de la naturaleza sofisticada de las copias de seguridad distribuidas y los desafíos de coordinación que enfrentamos, creo que hemos encontrado una solución simple pero efectiva.

Estén atentos para obtener más información sobre los aspectos internos de PBM y puede comenzar a realizar una copia de seguridad consistente de su clúster de MongoDB ahora. Descubre Percona Backup para MongoDB Github por lo mismo.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario