Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for MySQL®
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Сеть в Managed Service for MySQL
    • Квоты и лимиты
    • Типы дисков
    • Резервные копии
    • Репликация
    • Техническое обслуживание
    • Права пользователей
    • Настройки MySQL
    • Ограничения для команд SQL
    • Сравнение MySQL® версий 5.7 и 8.0
  • Управление доступом
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • История изменений
  • Обучающие курсы

В этой статье:

  • Создание резервной копии
  • Хранение резервной копии
  • Проверка восстановления из резервной копии
  1. Концепции
  2. Резервные копии

Резервные копии в Managed Service for MySQL®

Статья создана
Yandex Cloud
Обновлена 19 апреля 2024 г.
  • Создание резервной копии
  • Хранение резервной копии
  • Проверка восстановления из резервной копии

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 включительно.

По умолчанию PITR включен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • В существующем кластере для созданных автоматически резервных копий срок хранения можно настроить в диапазоне от 7 до 60 дней (по умолчанию — 7). Созданные вручную резервные копии хранятся бессрочно.

  • После удаления кластера все его резервные копии хранятся 7 дней.

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

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

    Подробнее см. в разделе Правила тарификации.

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

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

Была ли статья полезна?

Предыдущая
Типы дисков
Следующая
Репликация
Проект Яндекса
© 2025 ООО «Яндекс.Облако»