Cómo hacer una copia de seguridad de los clústeres de operadores de MySQL Kubernetes

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 podspara 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 InnoDBClusterobjetos. 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.backupSchedulesel campo de su base de datos. Cada elemento requiere un schedulecampo 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 backupProfileNamehace 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.backupProfilesel campo. Cada perfil debe tener una propiedad namey dumpInstanceque configure la operación de copia de seguridad.

El almacenamiento de respaldo se configura para cada perfil en dumpInstance.storageel 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 awsun 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.s3la 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ó defaulten 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.ociObjectStoragesección:

Modifique los campos bucketNamey prefixpara especificar la ubicación de descarga en su cuenta OCI. El campo credentialsdebe 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.persistentVolumeClaimel 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 dumpInstancea través dumpOptionsde 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.initDBun campo de sus InnoDBClusterobjetos. En esta sección, utilice dump.storageun objeto para hacer referencia a la ubicación de la copia de seguridad que utilizó anteriormente. El formato corresponde al dumpInstance.storagecampo 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 dumpInstancecon la salida en el depósito de S3 especificado. El campo prefixdebe 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 pathel 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

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *