Резервные копии

Managed Service for MySQL обеспечивает автоматическое и ручное резервное копирование баз данных.

Managed Service for MySQL позволяет восстановить состояние кластера на любой момент времени (Point-in-Time-Recovery, PITR) после создания самой старой полной резервной копии. Это достигается за счет дополнения данных резервной копии, выбранной в качестве начальной точки для восстановления, записями из бинарных логов (Binary Log) более поздних резервных копий кластера.

Например, если операция создания резервной копии завершилась 10.08.2020 в 12:00:00 UTC, текущая дата — 15.08.2020 19:00:00 UTC, а последний бинарный лог был сохранен 15.08.2020 в 18:50:00 UTC, кластер может быть восстановлен в любое свое состояние в промежутке времени с 10.08.2020 12:00:01 UTC до 15.08.2020 18:50:00 UTC включительно.

При создании резервных копий и восстановлении из них на заданный момент времени учитывайте, что:

• Бинарный лог состоит из файлов размером 100 МБ, которые архивируются в работающем кластере по мере достижения нужного размера, после чего загружаются в объектное хранилище. Транзакции записываются в бинарный лог только целиком, поэтому иногда размер файлов превышает указанный, а на их архивацию требуется больше времени.

• На создание и загрузку архива бинарного лога в объектное хранилище требуется некоторое время. Из-за этого состояние кластера, хранящееся в объектном хранилище, может отличаться от реального.

• Восстанавливая кластер из резервной копии, вы создаете новый кластер с данными из резервной копии. Если в каталоге не хватает ресурсов для создания такого кластера, восстановиться из резервной копии не получится. Средняя скорость восстановления из резервной копии — 10 МБайт/с на каждое ядро БД.

  При восстановлении до состояния на текущий момент времени новый кластер будет отражать состояние:

  • существующего кластера на момент восстановления;
  • удаленного кластера на момент архивации последнего бинарного лога.

Подробнее о PITR см. в документации MySQL.

Чтобы восстановить кластер из резервной копии, следуйте инструкциям.

Создание резервной копии

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

Отключить автоматическое создание резервных копий нельзя. Однако при создании или изменении кластера для таких резервных копий можно задать время начала резервного копирования. По умолчанию время начала — 22:00 UTC (Coordinated Universal Time). Резервное копирование начнется в течение получаса от указанного времени.

После создания резервная копия сжимается для дальнейшего хранения.

В кластерах из одного хоста резервная копия создается чтением данных с хоста-мастера, а в многохостовых кластерах, так как это ресурсоемкая операция — с одной из реплик. При этом:

• Выбирается реплика с наибольшим приоритетом резервного копирования. Приоритет можно задать при создании кластера, добавлении в него новых хостов или изменении настроек существующих, тем самым указав конкретную реплику для резервного копирования. Минимальное значение приоритета резервного копирования — 0, максимальное — 100, по умолчанию — 0.
• Если наибольший приоритет имеют несколько реплик, источник резервного копирования выбирается среди них случайным образом.

Если сервис не сможет создать резервную копию, используя выбранную реплику, то резервное копирование будет запущено с использованием хоста-мастера.

Резервные копии создаются только на работающих кластерах. Если вы используете кластер Managed Service for MySQL не круглосуточно, проверьте настройки времени начала резервного копирования.

О том, как вручную создать резервную копию, читайте в разделе Управление резервными копиями.

Хранение резервной копии

Особенности хранения резервных копий в Managed Service for MySQL:

• Резервные копии хранятся во внутреннем хранилище Яндекса в виде бинарных файлов и шифруются с помощью GPG. У каждого кластера свои ключи шифрования.

• Резервные копии существующего кластера, созданные автоматически, хранятся 7 дней, а созданные вручную — бессрочно. После удаления кластера все его резервные копии хранятся 7 дней. Изменить срок хранения резервных копий нельзя.

• На хранилище резервных копий не распространяется действие квот и лимитов для хранилища кластера.

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

  Подробнее см. в разделе Правила тарификации для Managed Service for MySQL.

Проверка резервной копии

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

Целостность резервных копий проверяется на синтетических данных интеграционными тестами сервиса.

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

Для проверки возможностей резервного копирования восстановите кластер из резервной копии и проверьте целостность ваших данных.