Как сделать резервную копию кластеров операторов MySQL Kubernetes

Oracle MySQL Operator for Kubernetes — это удобный способ автоматизировать подготовку базы данных MySQL в вашем кластере. Одной из основных функций оператора является встроенная поддержка автоматического резервного копирования, которая повышает вашу отказоустойчивость. Резервные копии копируют вашу базу данных во внешнее хранилище по повторяющемуся расписанию.

В этой статье вы узнаете, как настроить резервное копирование в службу хранилища объектов, совместимую с Amazon S3. Вы также узнаете, как хранить резервные копии в хранилище Oracle Cloud Infrastructure (OCI) или на локальных постоянных томах внутри вашего кластера.

Подготовка кластера базы данных

Установите оператор MySQL в свой кластер Kubernetes и создайте простой экземпляр базы данных для целей тестирования. Скопируйте приведенный ниже YAML и сохраните его в mysql.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-user
stringData:
  rootHost: "%"
  rootUser: "root"
  rootPassword: "P@$$w0rd"
 
---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1

Используйте Kubectl для применения манифеста:

$ kubectl apply -f mysql.yaml

Подождите несколько минут, пока оператор MySQL подготовит ваши модули. Используйте команду Kubectl get pods, чтобы проверить ход выполнения. Вы должны увидеть четыре запущенных модуля: один экземпляр маршрутизатора MySQL и три реплики сервера 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

Определение расписания резервного копирования

Оператору MySQL требуются два компонента для успешного создания резервной копии:

Расписание резервного копирования, определяющее время запуска резервного копирования.
Профиль резервного копирования, который настраивает место хранения и параметры экспорта MySQL.

Расписания и профили создаются независимо друг от друга. Это позволяет запускать несколько резервных копий по разным расписаниям, используя один и тот же профиль.

Каждое расписание и профиль связаны с определенным кластером базы данных. Они создаются как вложенные ресурсы внутри ваших объектов InnoDBCluster. Каждая база данных, которую вы создаете с помощью оператора MySQL, нуждается в собственной конфигурации резервного копирования.

Расписания резервного копирования определяются полем spec.backupSchedules вашей базы данных. Для каждого элемента требуется поле schedule, в котором указывается, когда запускать резервное копирование с помощью выражения cron. Вот пример, который запускает резервное копирование каждый час:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
   backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup

Поле backupProfileName ссылается на используемый профиль резервного копирования. Вы создадите это на следующем шаге.

Создание профилей резервного копирования

Профили определяются в поле spec.backupProfiles. Каждый профиль должен иметь имя и свойство dumpInstance, которое настраивает операцию резервного копирования.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          # ...

Хранилище резервных копий настраивается отдельно для каждого профиля в поле dumpInstance.storage. Свойства, которые необходимо предоставить, зависят от типа используемого хранилища.

Хранилище S3

Оператор MySQL может загружать ваши резервные копии прямо в S3-совместимые хранилища объектов. Чтобы использовать этот метод, вы должны создать секрет Kubernetes, который содержит файл конфигурации CLI aws с вашими учетными данными.

Добавьте следующее содержимое в s3-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [default]
    aws_access_key_id = YOUR_S3_ACCESS_KEY
    aws_secret_access_key = YOUR_S3_SECRET_KEY

Замените свои собственные ключи доступа и секретные ключи S3, а затем используйте Kubectl для создания секрета:

$ kubectl apply -f s3-secret.yaml
secret/s3-secret created

Затем добавьте следующие поля в раздел storage.s3 вашего профиля резервного копирования:

bucketName — имя корзины S3, в которую будут загружаться ваши резервные копии.
prefix — установите этот параметр, чтобы применять префикс к загружаемым файлам, например /my-app/mysql. Этот префикс позволяет создавать деревья папок в корзине.
конечная точка – укажите URL-адрес вашего поставщика услуг, если вы используете стороннее хранилище, совместимое с S3. Это поле можно опустить, если вы используете Amazon S3.
config — имя секрета, содержащего ваш файл учетных данных.
profile — имя профиля конфигурации для использования в файле учетных данных. В приведенном выше примере для этого было установлено значение default.

Вот полный пример:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          s3:
            bucketName: backups
            prefix: /mysql
            config: s3-secret
            profile: default

Применение этого манифеста активирует ежечасное резервное копирование базы данных в вашу учетную запись S3.

Хранилище OCI

Оператор поддерживает объектное хранилище Oracle Cloud Infrastructure (OCI) в качестве альтернативы S3. Он настраивается аналогичным образом. Сначала создайте секрет для ваших учетных данных OCI:

apiVersion: v1
kind: Secret
metadata:
  name: oci-secret
stringData:
  fingerprint: YOUR_OCI_FINGERPRINT
  passphrase: YOUR_OCI_PASSPHRASE
  privatekey: YOUR_OCI_RSA_PRIVATE_KEY
  region: us-ashburn-1
  tenancy: YOUR_OCI_TENANCY
  user: YOUR_OCI_USER

Затем настройте профиль резервного копирования с разделом storage.ociObjectStorage:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          ociObjectStorage:
            bucketName: backups
            prefix: /mysql
            credentials: oci-secret

Измените поля bucketName и prefix, чтобы указать место загрузки в вашей учетной записи OCI. Поле credentials должно ссылаться на секрет, содержащий ваши учетные данные OCI.

Объемное хранилище Kubernetes

Локальные постоянные тома — это третий вариант хранения. Это менее надежно, так как ваши резервные данные все еще будут находиться внутри вашего кластера Kubernetes. Однако это может быть полезно для одноразового резервного копирования и тестирования.

Сначала создайте постоянный том и сопроводительную претензию:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: backup-pv
spec:
  storageClassName: standard
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /tmp
 
---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backup-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Этот пример манифеста не подходит для использования в рабочей среде. Вы должны выбрать соответствующий класс хранилища и режим подключения тома для вашего дистрибутива Kubernetes.

Затем настройте профиль резервного копирования для использования постоянного тома, добавив поле storage.persistentVolumeClaim:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          persistentVolumeClaim:
            claimName: backup-pvc

На созданное ранее постоянное утверждение тома ссылается поле claimName. Теперь оператор MySQL поместит данные резервной копии в том.

Настройка параметров резервного копирования

Резервные копии создаются с помощью утилиты dumpInstance оболочки MySQL. По умолчанию это экспорт полного дампа вашего сервера. Формат записывает структуру и фрагментированные файлы данных для каждой таблицы. Вывод сжимается с помощью zstd.

Вы можете передать параметры в dumpInstance через поле dumpOptions в профиле резервного копирования оператора MySQL:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  # ...
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        dumpOptions:
          chunking: false
          compression: gzip
        storage:
          # ...

В этом примере отключается фрагментированный вывод, создается один файл данных для каждой таблицы и переключается на сжатие gzip вместо zstd. Вы можете найти полную справку по доступным параметрам в документации MySQL.

Восстановление резервной копии

Оператор MySQL может инициализировать новые кластеры базы данных, используя ранее созданные файлы из dumpInstance. Это позволяет восстанавливать резервные копии прямо в кластере Kubernetes. Это полезно в ситуациях восстановления или при переносе существующей базы данных в Kubernetes.

Инициализация базы данных управляется полем spec.initDB в ваших объектах InnoDBCluster. В этом разделе используйте объект dump.storage для ссылки на хранилище резервных копий, которое вы использовали ранее. Формат соответствует эквивалентному полю dumpInstance.storage в объектах профиля резервного копирования.

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [default]
    aws_access_key_id = YOUR_S3_ACCESS_KEY
    aws_secret_access_key = YOUR_S3_SECRET_KEY

---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster-recovered
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  initDB:
    dump:
      storage:
        s3:
          bucketName: backups
          prefix: /mysql/mysql20221031220000
          config: s3-secret
          profile: default

Применение этого файла YAML создаст новый кластер базы данных, который инициализируется выходными данными dumpInstance в указанном сегменте S3. Поле prefix должно содержать полный путь к файлам дампа в корзине. Резервные копии, созданные оператором, будут автоматически храниться в папках с отметкой времени; вам нужно будет указать, какой из них восстанавливать, установив префикс. Если вы восстанавливаете с постоянного тома, используйте поле path вместо prefix.

Краткое содержание

Оператор Oracle MySQL автоматизирует управление базой данных MySQL в кластерах Kubernetes. В этой статье вы узнали, как настроить систему резервного копирования оператора для хранения полных дампов базы данных в постоянном томе или сегменте хранилища объектов.

Использование Kubernetes для горизонтального масштабирования MySQL повышает отказоустойчивость, но внешние резервные копии по-прежнему необходимы на случай взлома вашего кластера или случайного удаления данных. Оператор MySQL может восстановить новый экземпляр базы данных из вашей резервной копии, если вам когда-нибудь понадобится, упростив процедуру восстановления после аварии.