Резервные копии MySQL Operator в Kubernetes

Логотип MySQL — белый дельфин на синем фоне

Быстрые ссылки

Подготовка кластера базы данных
Определение расписания резервного копирования
Создание профилей резервного копирования
Настройка параметров резервного копирования
Восстановление из резервной копии
Контрольный список и план действий
Часто задаваемые вопросы

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

Перед настройкой резервного копирования убедитесь, что MySQL Operator установлен в вашем кластере Kubernetes и что вы можете создать простую тестовую базу данных. Ниже — минимальный пример манифеста для создания кластера InnoDBCluster и секрета с учётными данными root.

Сохраните файл как mysql.yaml и примените его с помощью kubectl:

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 apply -f mysql.yaml

Подождите несколько минут, пока оператор не создаст Pod’ы. Проверить статус можно так:

$ kubectl get pods

Ожидаемый результат: четыре запущенных Pod’а — один маршрутизатор и три экземпляра сервера MySQL.

Примечание: В продуктивных окружениях замените тестовый пароль и включите управляемое хранение секретов (например, HashiCorp Vault, Cloud KMS).

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

Оператор MySQL использует два независимых компонента для резервного копирования:

Расписание резервного копирования — когда запускать резервную копию (cron).
Профиль резервного копирования — куда и как выгружать данные (настройки storage и dumpOptions).

Разбиение на расписания и профили позволяет использовать один профиль для нескольких расписаний (например, hourly и daily).

Пример добавления расписания в spec.backupSchedules вашего InnoDBCluster:

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

Описание полей:

name — человекочитаемое имя расписания.
enabled — включено ли расписание.
schedule — cron-выражение (в кластере используется временная зона ядра Kubernetes; уточните, какая TZ у вашего control plane).
backupProfileName — имя профиля из spec.backupProfiles.

Важно: каждое хранилище и профиль являются вложенными ресурсами в объекте InnoDBCluster и привязаны к конкретному кластеру.

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

Профили описывают, как именно выполнять экспорт через MySQL Shell 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, ociObjectStorage или persistentVolumeClaim.

S3-совместимое хранилище

Оператор умеет загружать архивы прямо в S3-совместимые объекты (Amazon S3, MinIO, Wasabi, Yandex Object Storage и т.д.). Для этого создайте секрет с конфигурацией AWS CLI в формате ini.

Файл 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

Применение:

$ kubectl apply -f s3-secret.yaml

Добавьте в профиль следующие поля:

bucketName — имя бакета.
prefix — префикс (путь в бакете), например mysql или /my-app/mysql. Необязательно начинать с /.
endpoint — URL S3-совместимого провайдера (опционально для Amazon S3).
config — имя секрета (в примере s3-secret).
profile — профиль внутри файла credential (обычно default).

Пример профиля с S3:

backupProfiles:
  - name: hourly-backup
    dumpInstance:
      storage:
        s3:
          bucketName: backups
          prefix: /mysql
          config: s3-secret
          profile: default

Важно: если вы используете сторонний провайдер, укажите endpoint и убедитесь, что сетевые политики и firewall позволяют доступ к нему из кластера.

OCI Object Storage

Для Oracle Cloud укажите секрет с ключами и настройте профиль так:

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

Профиль:

backupProfiles:
  - name: hourly-backup
    dumpInstance:
      storage:
        ociObjectStorage:
          bucketName: backups
          prefix: /mysql
          credentials: oci-secret

Параметры region, tenancy и user зависят от вашей учетной записи OCI.

Локальный том Kubernetes (PersistentVolume)

Локальные PV удобны для тестов и однократных бэкапов, но менее устойчивы в сравнении с внешними объектными хранилищами. Пример PV+PVC:

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

Привязка в профиле:

backupProfiles:
  - name: hourly-backup
    dumpInstance:
      storage:
        persistentVolumeClaim:
          claimName: backup-pvc

Примечание: В production используйте сеть-ориентированные хранилища (CSI), а не hostPath. hostPath подходит только для локальной разработки.

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

По умолчанию оператор использует утилиту MySQL Shell dumpInstance для создания дампов. Формат по умолчанию: структура + чанки данных по таблицам; сжатие — zstd.

Вы можете передавать параметры dumpInstance через поле dumpOptions в профиле.

Пример изменения настроек:

backupProfiles:
  - name: hourly-backup
    dumpInstance:
      dumpOptions:
        chunking: false
        compression: gzip
      storage:
        s3:
          bucketName: backups
          prefix: /mysql
          config: s3-secret
          profile: default

Примеры полезных опций:

chunking: true/false — разбивать ли данные на чанки и по сколько.
compression: zstd/gzip/none — алгоритм сжатия.
includeBinlog: true/false — включать ли бинарные логи (если поддерживается).

Опции зависят от версии MySQL Shell. Для полного списка смотрите официальную документацию MySQL Shell на соответствующей версии.

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

Оператор умеет инициализировать новый кластер MySQL из выходных файлов dumpInstance. Для этого используется поле spec.initDB.dump на объекте InnoDBCluster.

Пример секрета для доступа к S3 (тот же, что и для резервного копирования):

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

Обратите внимание:

prefix должен указывать полный путь к папке с дампом (оператор сохраняет дампы в timestamp-папках).
Если вы восстанавливаете с PersistentVolume, используйте поле path вместо prefix.

После применения этого манифеста оператор создаст новый кластер, инициализированный указанным дампом.

Контрольный список и план действий

Ниже — практический playbook и чек-листы для подготовки, выполнения и проверки резервного копирования и восстановления.

Перед настройкой

Установлен MySQL Operator и есть доступ к кластеру.
Создан секрет с административными учетными данными MySQL.
Определено место хранения резервных копий (S3/OCI/PVC).
Настроены сетевые правила для доступа к внешнему хранилищу.
Определён график резервного копирования (RPO/RTO цели согласованы).

Действия по настройке

Создайте секрет для доступа к выбранному хранилищу.
Добавьте backupProfiles в спецификацию InnoDBCluster.
Добавьте backupSchedules, указывая имя профиля.
Примените манифест и убедитесь, что Cron/Controller активировал расписание.
Проверьте успешные бэкапы в целевом хранилище (появились timestamp-папки).

Проверка и валидация

Убедитесь, что файлы дампа появились в бакете или в PVC.
Выполните контрольное восстановление в тестовом namespace/кластере.
Проверяйте целостность таблиц после восстановления (SELECT COUNT, контрольные суммы).

План восстановления (Runbook)

Создайте секрет с доступом к хранилищу, если он отсутствует.
Сформируйте манифест InnoDBCluster с initDB.dump, указывая префикс нужной timestamp-папки.
Примените манифест и отслеживайте Pod’ы оператора и сервера.
После поднятия кластера выполните базовую валидацию данных и целостности.
При проблемах — переключитесь на следующий по времени бэкап (измените prefix).

Критерии приёмки

Кластер успешно создан и в состоянии Ready.
Таблицы и данные доступны и соответствуют контрольным суммам.
Время восстановления соответствует ожидаемому RTO (в пределах допустимого).

Отказоустойчивость, безопасность и лучшие практики

Храните резервные копии в гео-изолированном внешнем хранилище (объектное хранилище) для защиты от полного выхода кластера.
Шифруйте секреты доступа к хранилищу и используйте ротацию ключей.
Ограничьте права доступа к бакету: запись/чтение только с ролей оператора.
Проверяйте бэкапы регулярными тестовыми восстановлением — бэкап годен, только если его можно восстановить.
Для критичных данных храните несколько уровней резервных копий: hourly, daily, weekly, с разными профилями и TTL.
Используйте мониторинг и алерты на неудавшиеся задания резервного копирования.

Распространённые проблемы и их решение

Бэкап не стартует: проверьте логи MySQL Operator и status ресурса InnoDBCluster.
Ошибка доступа к S3/OCI: проверьте секреты, endpoint, регион и сетевые правила (DNS, NAT).
Превышение квоты или недостаточно места: проверьте размер данных и лимиты бакета/PVC.
Неполные дампы: убедитесь, что dumpInstance завершается корректно и не прерывается OOM/killed.

Тесты и сценарии приёмо-сдаточных тестов

Проверка успешного создания профиля и запуска резервного копирования в течение 1 часа после применения.
Восстановление в тестовом namespace и проверка контрольной суммы таблицы.
Имитация недоступности S3: убедиться, что ошибки корректно логируются и попадают в алерты.
Проверка ротации и удаления старых дампов (если реализована вручную или на стороне хранилища).

Ментальные модели и эвристики для принятия решений

Если требуемая долговременная сохранность выше, чем RPO/ RTO кластера, используйте объектное хранилище вне кластера.
Для быстрого тестирования и изолированных инсталляций достаточно PVC; для боевого — внешнее S3/OCI.
Разделяйте права на запись и на восстановление: системный аккаунт для записи бэкапов, операторский — для восстановления.

Примеры шаблонов и сниппетов

Шаблон расписания и профиля — сводный пример с комментариями:

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
    - name: daily
      enabled: true
      schedule: "0 2 * * *"
      backupProfileName: daily-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        dumpOptions:
          chunking: true
          compression: zstd
        storage:
          s3:
            bucketName: backups
            prefix: /mysql/hourly
            config: s3-secret
            profile: default
    - name: daily-backup
      dumpInstance:
        dumpOptions:
          chunking: false
          compression: zstd
        storage:
          s3:
            bucketName: backups
            prefix: /mysql/daily
            config: s3-secret
            profile: default

Риски и рекомендации по снижению

Риск: утечка учётных данных для S3/OCI — mitigations: использовать KMS, ротацию и ограничение доступа.
Риск: повреждение дампа при записи — mitigations: проверка контрольных сумм, регулярные тестовые восстановления.
Риск: нехватка места — mitigations: мониторинг использования бакетов и PVC, автоочистка старых дампов.

Управление версиями и совместимость

Убедитесь, что версия MySQL Shell, которую использует оператор, совместима с версией сервера MySQL.
При обновлении оператора проверьте изменения в API и формате dumpInstance.
Храните документацию о версиях бэкапов (в metadata или в отдельном журнале сборки), чтобы знать, с какими версиями MySQL были созданы дампы.

Часто задаваемые вопросы

Как часто нужно делать бэкапы?

Зависит от бизнес-требований: определите RPO (максимально допустимую потерю данных) и RTO (время восстановления). Hourly/daily — типичные варианты, но для критичных данных рассмотрите более частые снапшоты.

Можно ли хранить бэкапы в разных регионах?

Да — создайте для каждого региона отдельный профиль и секрет, указывающий соответствующий endpoint/регион.

Что делать, если восстановление не прошло?

Проверьте логи оператора и MySQL Shell, убедитесь, что указанный prefix корректен и файлы целы. Попробуйте восстановиться из предыдущего по времени дампа.

Как протестировать бэкапы регулярно?

Настройте отдельный namespace и автоматизированный pipeline (CI) для периодического восстановления и проверки контрольных сумм.

Короткое объявление для команды (100–200 слов)

Мы внедрили автоматическое резервное копирование MySQL через MySQL Operator в Kubernetes. Резервные копии можно хранить в S3-совместимом объектном хранилище, Oracle Cloud (OCI) или локальном PersistentVolume. Вся конфигурация задаётся через spec.backupSchedules и spec.backupProfiles объекта InnoDBCluster. Пожалуйста, используйте отдельные профили для разных SLA и следуйте чек-листу восстановления: хранение секретов в KMS, тестовые восстановления и мониторинг неудач. Если нужно — помогу подготовить манифесты и план тестового восстановления.

Короткое резюме

MySQL Operator упрощает управление резервными копиями MySQL в Kubernetes за счёт встроенной интеграции с dumpInstance и поддержкой популярных хранилищ. В производственной среде рекомендуется хранить бэкапы вне кластера и регулярно тестировать восстановление.

Если нужна помощь с конкретным провайдером (MinIO, S3-сервис, OCI) или примером манифеста для вашей инфраструктуры — пришлите детали (версия оператора, целевой провайдер, требования RPO/RTO), и я подготовлю адаптированный план и манифесты.