Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
© 2022 ООО «Яндекс.Облако»
Yandex Managed Service for MySQL®
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к базе данных
    • Остановка и запуск кластера
    • SQL-запросы в консоли управления
    • Изменение кластера
    • Подключение к DataLens
    • Управление хостами MySQL
    • Управление базами данных
    • Управление пользователями
    • Управление правами пользователей
    • Управление резервными копиями
    • Просмотр логов кластера
    • Удаление кластера
    • Диагностика производительности
    • Мониторинг состояния кластера и хостов
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
      • Действующие классы хостов
      • Архив
        • До 1 июня 2020 года
      • Использование устаревших классов хостов
    • Сеть в Managed Service for MySQL
    • Квоты и лимиты
    • Типы хранилища
    • Резервные копии
    • Репликация
    • Техническое обслуживание
    • Права пользователей
    • Настройки MySQL
  • Практические руководства
    • Все сценарии
    • Анализ производительности и оптимизация
    • Выгрузка базы данных в Yandex Data Proc
    • Миграция базы данных в Managed Service for MySQL
    • Миграция базы данных из Managed Service for MySQL в MySQL
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • Database
        • Overview
        • create
        • delete
        • get
        • list
      • ResourcePreset
        • Overview
        • get
        • list
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
    • Вопросы о MySQL
    • Подключение
    • Проблемы с чтением/записью в кластер
    • Проблемы с производительностью
    • Изменение кластера
    • Мониторинг и логи
    • Миграция/перенос
    • Настройки параметров MySQL
    • Все вопросы на одной странице
  1. Концепции
  2. Резервные копии

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

Статья создана
Yandex Cloud
  • Создание резервной копии
  • Хранение резервной копии
  • Проверка резервной копии
    • Проверка целостности резервной копии
    • Проверка восстановления из резервной копии

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.

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

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

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

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

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

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

Language / Region
© 2022 ООО «Яндекс.Облако»
В этой статье:
  • Создание резервной копии
  • Хранение резервной копии
  • Проверка резервной копии
  • Проверка целостности резервной копии
  • Проверка восстановления из резервной копии