Cómo hacer una copia de seguridad de los clústeres de operadores de MySQL Kubernetes
Oracle MySQL Operator para Kubernetes es una forma conveniente de automatizar el aprovisionamiento de bases de datos MySQL en su clúster. Una de las características principales del operador es el soporte integrado para copias de seguridad automáticas, lo que aumenta su capacidad de recuperación. Las copias de seguridad copian su base de datos en un almacenamiento externo en un horario recurrente.
En este artículo, aprenderá a configurar una copia de seguridad en un servicio de almacenamiento de objetos compatible con Amazon S3. También aprenderá a almacenar copias de seguridad en el almacenamiento de Oracle Cloud Infrastructure (OCI) o en volúmenes persistentes locales dentro de su clúster.
Preparación del clúster de la base de datos
Instale una declaración de MySQL en su clúster de Kubernetes y cree una instancia de base de datos simple para fines de prueba. Copie el YAML a continuación y guárdelo en mysql.yaml
:
Use Kubectl para aplicar el manifiesto:
$ kubectl apply -f mysql.yaml
Espere unos minutos para que el operador de MySQL prepare sus módulos. Use el comando Kubectl get pods
para verificar el progreso. Debería ver cuatro módulos ejecutándose: una instancia de enrutador MySQL y tres réplicas de servidor MySQL.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-cluster-0 2/2 Running 0 2m
mysql-cluster-1 2/2 Running 0 2m
mysql-cluster-2 2/2 Running 0 2m
mysql-cluster-router-6b68f9b5cb-wbqm5 1/1 Running 0 2m
Determinación de la programación de la copia de seguridad
La instrucción MySQL requiere dos componentes para crear correctamente una copia de seguridad:
- La programación de la copia de seguridad, que determina cuándo se realizará la copia de seguridad.
- Un perfil de copia de seguridad que configura la ubicación de almacenamiento de MySQL y las opciones de exportación.
Los horarios y perfiles se crean de forma independiente unos de otros. Esto le permite ejecutar varias copias de seguridad en diferentes horarios utilizando el mismo perfil.
Cada programa y perfil está asociado con un clúster de base de datos específico. Se crean como recursos anidados dentro de sus InnoDBCluster
objetos. Cada base de datos que cree con la instrucción MySQL necesita su propia configuración de respaldo.
Los horarios de las copias de seguridad están determinados por spec.backupSchedules
el campo de su base de datos. Cada elemento requiere un schedule
campo que indique cuándo ejecutar la copia de seguridad mediante una expresión cron. Aquí hay un ejemplo que ejecuta una copia de seguridad cada hora:
El campo backupProfileName
hace referencia al perfil de copia de seguridad que se está utilizando. Lo creará en el siguiente paso.
Crear perfiles de respaldo
Los perfiles se definen en spec.backupProfiles
el campo. Cada perfil debe tener una propiedad name
y dumpInstance
que configure la operación de copia de seguridad.
El almacenamiento de respaldo se configura para cada perfil en dumpInstance.storage
el campo. Las propiedades que debe proporcionar dependen del tipo de almacenamiento que esté utilizando.
almacenamiento S3
El operador de MySQL puede cargar sus copias de seguridad directamente en almacenes de objetos compatibles con S3. Para usar este método, debe crear un secreto de Kubernetes que contenga aws
un archivo de configuración de la CLI con sus credenciales.
Agregue el siguiente contenido a s3-secret.yaml
:
Sustituya sus propias claves de acceso y secretos S3, luego use Kubectl para generar el secreto:
$ kubectl apply -f s3-secret.yaml
secret/s3-secret created
Luego agregue los siguientes campos a storage.s3
la sección del perfil de respaldo:
-
bucketName
– El nombre del depósito S3 para descargar las copias de seguridad. -
prefix
– Configúrelo para aplicar un prefijo a los archivos descargados, como/my-app/mysql
. El prefijo le permite crear árboles de carpetas dentro de la papelera. -
endpoint
– Establecer como la URL de su proveedor de servicios si está utilizando un almacenamiento de terceros compatible con S3. Puede omitir este campo si utiliza Amazon S3. -
config
– El nombre del secreto que contiene su archivo de credenciales. -
profile
– El nombre del perfil de configuración que se utilizará en el archivo de credenciales. Esto se estableciódefault
en el ejemplo anterior.
Aquí hay un ejemplo completo:
La aplicación de este manifiesto habilitará las copias de seguridad de la base de datos cada hora en su cuenta de S3.
almacenamiento OCI
El operador admite el almacenamiento de objetos de Oracle Cloud Infrastructure (OCI) como alternativa a S3. Se configura de la misma manera. Primero cree un secreto para sus credenciales de OCI:
Luego configure el perfil de respaldo usando la storage.ociObjectStorage
sección:
Modifique los campos bucketName
y prefix
para especificar la ubicación de descarga en su cuenta OCI. El campo credentials
debe hacer referencia a un secreto que contenga sus credenciales de OCI.
Almacenamiento masivo de Kubernetes
Los volúmenes persistentes locales son la tercera opción de almacenamiento. Esto es menos seguro ya que sus datos de copia de seguridad seguirán estando dentro de su clúster de Kubernetes. Sin embargo, puede ser útil para copias de seguridad y pruebas únicas.
Primero, cree un volumen persistente y un reclamo que lo acompañe:
Este manifiesto de ejemplo no es adecuado para su uso en producción. Debe seleccionar la clase de almacenamiento y el modo de montaje de volumen apropiados para su distribución de Kubernetes.
Luego configure su perfil de respaldo para usar su volumen persistente agregando storage.persistentVolumeClaim
el campo:
El campo hace referencia a la solicitud de volumen persistente que se creó anteriormente claimName
. La declaración de MySQL ahora colocará los datos de la copia de seguridad en el volumen.
Configuración de las opciones de copia de seguridad
Las copias de seguridad se crean utilizando la utilidad MySQL Shell . El valor predeterminado es exportar un volcado completo de su servidor. El formato escribe la estructura y los archivos de datos fragmentados para cada tabla. La salida se comprime usando zstd. dumpInstance
Puede pasar opciones a través de campo dumpInstance
a través dumpOptions
de campo en el perfil de copia de seguridad de declaración de MySQL:
Este ejemplo deshabilita la salida fragmentada, crea un archivo de datos por tabla y cambia a la compresión gzip en lugar de zstd. Se puede encontrar una referencia completa de las opciones disponibles en la documentación de MySQL .
Restaurar una copia de seguridad
El operador de MySQL puede inicializar nuevos clústeres de bases de datos utilizando archivos creados previamente desde dumpInstance
. Esto le permite restaurar las copias de seguridad directamente en el clúster de Kubernetes. Esto es útil en situaciones de recuperación o al migrar una base de datos existente a Kubernetes.
La inicialización de la base de datos está controlada por spec.initDB
un campo de sus InnoDBCluster
objetos. En esta sección, utilice dump.storage
un objeto para hacer referencia a la ubicación de la copia de seguridad que utilizó anteriormente. El formato corresponde al dumpInstance.storage
campo equivalente en los objetos del perfil de copia de seguridad.
La aplicación de este archivo YAML creará un nuevo clúster de base de datos que se inicializa dumpInstance
con la salida en el depósito de S3 especificado. El campo prefix
debe contener la ruta completa a los archivos de volcado en la papelera. Las copias de seguridad creadas por el operador se guardarán automáticamente en carpetas con marca de tiempo; deberá especificar cuál restaurar estableciendo un prefijo. Si está restaurando desde un volumen persistente, use path
el campo en lugar de prefix
.
Resumen
El operador Oracle MySQL automatiza la gestión de bases de datos MySQL en clústeres de Kubernetes. En este artículo, aprendió a configurar un sistema de copia de seguridad del operador para almacenar volcados completos de la base de datos en un volumen persistente o en un segmento de almacenamiento de objetos.
El uso de Kubernetes para escalar horizontalmente MySQL mejora la tolerancia a fallas, pero aún se necesitan copias de seguridad externas en caso de que su clúster se vea comprometido o los datos se eliminen accidentalmente. El operador de MySQL puede restaurar una nueva instancia de base de datos desde su copia de seguridad si alguna vez lo necesita, lo que facilita la recuperación de un desastre.
Deja una respuesta