Recuperación puntual de MongoDB en Kubernetes

Ejecutar MongoDB en Kubernetes con Percona Operator no solo es simple, sino que también está diseñado para proporcionar un clúster MongoDB de alta disponibilidad diseñado para aplicaciones de misión crítica. En la última versión 1.8.0, agregamos una característica que implementa la recuperación de un punto en el tiempo (PITR). Permite a los usuarios almacenar Oplog en un depósito S3 externo y realizar la recuperación en una fecha y hora específicas una vez que sea necesario. El principal valor de este enfoque es un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) significativamente más bajos.

En esta publicación de blog, analizamos cómo proporcionamos esta función y revisamos algunas decisiones arquitectónicas.

Interior

Para copias de seguridad completas y funciones PITR, el operador confía Copia de seguridad de Percona para MongoDB (PBM), que por diseño admite el almacenamiento de registros de operaciones (oplogs) en almacenamiento compatible con S3. Ejecutamos PBM como un contenedor sidecar en pods de conjuntos de replicación, incluidos los pods de servidores de configuración. Luego, cada sector de replicación tiene dos contenedores desde el principio: Percona Server for MongoDB (PSMDB) y Percona Backup for MongoDB.

Si bien PBM es una gran herramienta, tiene algunas limitaciones que debemos tener en cuenta al implementar la función PITR.

Un balde

Si PITR está habilitado, PBM mantiene las copias de seguridad en el almacenamiento de S3 de forma concatenada: los registros de operaciones se almacenan inmediatamente después de la copia de seguridad completa y los necesitan. PBM almacena metadatos sobre las copias de seguridad en el propio clúster de MongoDB y crea una copia en S3 para mantener una visibilidad completa del estado de la copia de seguridad y los registros de operaciones.

Cuando un usuario quiere recuperarse en una fecha y hora específicas, PBM entiende qué copia de seguridad completa usar, se recupera y aplica los registros de operaciones.

Si el usuario decide utilizar varios cubos de S3 para almacenar copias de seguridad, significa que los registros de operaciones también están dispersos en estos cubos. Esto complica el proceso de recuperación porque PBM solo conoce el último depósito que S3 usó para almacenar la copia de seguridad completa.

Para simplificar las cosas y evitar estas situaciones de cerebro dividido con varios cubos, hemos tomado las siguientes decisiones de diseño:

  • No active la función PITR en depósitos múltiples especificados por el usuario
    respaldo.historias
    sección. Esto debería cubrir la mayoría de los casos. Emitimos un error si el usuario prueba que:

  • Siempre hay casos en los que los usuarios pueden ingresar a la situación con varios depósitos (por ejemplo, deshabilitar PITR y activarlo nuevamente con otro depósito).
    • Es por eso que para recuperar desde la copia de seguridad le pedimos al usuario que especifique el
      nombre de copia de seguridad (
      psmdbrespaldo Nombre de recurso personalizado) en u
      va a recuperarse.yaml
      manifiesto. De este CR tenemos el almacenamiento y PBM toma los registros de operación que siguen al respaldo completo.

La pregunta obvia es: ¿por qué el operador no puede manejar la lógica y de alguna manera almacenar metadatos de varios depósitos?

Aquí hay varias respuestas:

  1. La configuración del depósito puede cambiar durante el ciclo de vida de un clúster y es posible mantener todos estos datos, pero los datos pueden volverse obsoletos con el tiempo. Además, nuestro Operador no tiene estado y queremos que siga siendo así.
  2. No queremos llevar esta complejidad al Operador y estamos evaluando la viabilidad de agregar esta funcionalidad en PBM en su lugar (K8SPSMDB-460).

Se requiere copia de seguridad completa

Mencionamos anteriormente que Oplogs requiere copias de seguridad completas. Sin una copia de seguridad completa, PBM no comenzará a cargar registros de operaciones y el Operador lanzará el siguiente error:

Hay dos casos en los que esto puede suceder:

  1. El usuario activa PITR para el clúster
  2. El usuario se recupera de la copia de seguridad

En esta versión, hemos decidido no crear la copia de seguridad completa automáticamente, sino dejarla en manos del usuario o del archivo de copia de seguridad. Podemos introducir la bandera en las siguientes versiones que permitan a los usuarios configurar este comportamiento, pero por ahora, hemos decidido que las primitivas actuales son suficientes para automatizar la creación de copias de seguridad completas.

10 minutos RPO

Ahora PBM carga registros de operaciones en el depósito S3 cada 10 minutos. Este intervalo de tiempo no es configurable ni codificado en este momento. Lo que esto significa para el usuario es que un Objetivo del punto de recuperación (RPO) puede durar hasta diez minutos.

Esto se mejorará en las siguientes versiones de Percona Backup for MongoDB y se capturará en PBM-543 Problema JIRA. Una vez allí, el usuario podrá controlar el período entre las cargas de Oplog con
Especificaciones.respaldo.pitr.timeBetweenUploads
en
cr.yaml.

¿Qué copia de seguridad tengo?

Luego, el usuario tiene una copia de seguridad completa y PITR habilitado. PBM tiene una buena función que muestra todas las copias de seguridad y los tiempos de Oplog (PITR):

Pero en el Operador, el usuario puede ver los detalles completos de la copia de seguridad, pero no puede ver la información de Oplog incluso sin ingresar manualmente al contenedor de la copia de seguridad:

La idea obvia es almacenar esta información de alguna manera
psmdbrespaldo Recurso personalizado, pero para hacer esto necesitamos mantenerlo actualizado. Actualizar cientos de estos objetos todo el tiempo en un ciclo de conciliación podría ejercer presión sobre el Operador y sobre la API de Kubernetes. Siempre evaluamos diferentes opciones aquí.

Conclusiones

La recuperación puntual es una característica importante de Percona Operator para MongoDB porque reduce el RTO y el RPO. La función ha estado presente en PBM durante algún tiempo y se ha probado en batalla en muchas implementaciones de producción. Con Operator queremos reducir al mínimo la carga manual y automatizar al máximo las operaciones del día 2. Aquí hay un resumen rápido de lo que sale de las siguientes versiones del operador relacionado con PITR:

  • Reduzca el RPO aún más con el período de carga configurable de Oplogs (PBM-543, K8SPSMDB-388)
  • Realice una copia de seguridad completa automáticamente si PITR está habilitado (K8SPSMDB-460)
  • Proporcione a los usuarios visibilidad de las marcas de tiempo de Oplogs disponibles (K8SPSMDB-461)

Nuestra hoja de ruta está disponible públicamente aquí y tendremos curiosidad por saber más acerca de sus ideas. Si está dispuesto a contribuir, un buen punto de partida sería CONTRIBUYENDO.md en el nuestro Repositorio Github. Tiene todos los detalles sobre cómo contribuir con el código, enviar nuevas ideas e informar un error. Un buen lugar para hacer preguntas es el nuestro. foro de la Comunidad, donde cualquiera puede compartir libremente sus pensamientos y sugerencias sobre el software Percona.

Percona Distribution para MongoDB es una alternativa de base de datos MongoDB disponible gratuitamente, que le brinda una solución única que combina los mejores y más importantes componentes comerciales de la comunidad de código abierto, diseñada y probada para trabajar en conjunto.

¡Descarga Percona Distribution para MongoDB hoy!

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