Поделиться через

Резервное копирование и восстановление в службе "База данных Azure для MySQL"

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер

Внимание

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

В службе "База данных Azure для MySQL" для сервера автоматически создаются резервные копии, которые сохраняются в локально избыточном или геоизбыточном хранилище, настроенном пользователем. Резервные копии можно использовать для восстановления сервера до точки во времени. Резервное копирование и восстановление данных являются важной частью любой стратегии непрерывности бизнес-процессов. Таким образом данные защищаются от случайного повреждения или удаления.

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

База данных Azure для MySQL создает резервные копии файлов данных и журнала транзакций. При помощи этих резервных копий вы можете восстановить сервер до любой точки во времени в пределах заданного срока хранения резервных копий. По умолчанию срок хранения резервных копий составляет 7 дней. При желании можно задать срок хранения до 35 дней. Все резервные копии шифруются с помощью 256-битового шифрования AES.

Эти файлы резервных копий не предоставляются пользователю и их нельзя экспортировать. Эти резервные копии можно использовать только для операций восстановления в Базе данных Azure для MySQL. Скопировать базу данных можно с помощью утилиты mysqldump.

Тип и частота резервного копирования зависят от хранилища для серверов.

Тип и частота резервного копирования

Базовые серверы хранилища

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

Создание резервных копий журналов транзакций происходит каждые 5 минут.

Серверы хранилища общего назначения версии 1 (поддерживают хранение до 4 ТБ данных)

Хранилище общего назначения — это серверное хранилище, поддерживающее серверы общего назначения и уровня с оптимизированного для операций в памяти. Для серверов с хранилищем общего назначения объемом до 4 ТБ полные резервные копии выполняются каждую неделю. Разностное резервное копирование выполняется дважды в день. Создание резервных копий журналов транзакций происходит каждые 5 минут. Резервные копии в хранилище общего назначения объемом до 4 ТБ не основаны на моментальных снимках и потребляют пропускную способность ввода-вывода во время резервного копирования. Для больших баз данных (>1 ТБ) в хранилище объемом 4 ТБ рекомендуется рассмотреть

  • подготовку дополнительных операций ввода-вывода в секунду для резервного копирования или
  • или же переход на хранилище общего назначения, которое поддерживает объем до 16 ТБ, если базовая инфраструктура хранилища доступна в предпочитаемых регионах Azure. Дополнительная плата за хранилище общего назначения, поддерживающее объем до 16 ТБ, не взимается. Чтобы получить помощь при переходе на хранилище объемом 16 ТБ, отправьте запрос в службу поддержки портала Azure.

Серверы хранилища общего назначения версии 2 (поддерживают хранение до 16 ТБ данных)

В подмножестве регионов Azure все вновь подготовленные серверы могут поддерживать хранилище общего назначения объемом до 16 ТБ. Иными словами, хранилище объемом до 16 ТБ является хранилищем общего назначения по умолчанию для всех регионов, в которых он поддерживается. Резервные копирования, находящиеся на этих серверах хранилища объемом до 16 ТБ, основаны на моментальных снимках. Создание первой резервной копии моментального снимка планируется сразу же после создания сервера. Резервные копии моментальных снимков создаются один раз в день. Создание резервных копий журналов транзакций происходит каждые 5 минут.

Дополнительные сведения о базовом хранилище и хранилище общего назначения см. в документации по хранилищу.

Хранение архивных копий

Резервные копии сохраняются с учетом заданного на сервере периода хранения резервной копии. Период хранения можно установить от 7 до 35 дней. Период хранения по умолчанию — 7 дней. Период хранения можно задать в процессе создания сервера или позже, изменив конфигурацию резервного копирования на портале Azure или в интерфейсе командной строки Azure.

Срок хранения резервных копий определяет, насколько раннюю точку во времени можно задать для восстановления, так как это зависит от доступных резервных копий. Период хранения резервной копии также можно рассматривать как окно восстановления. Все резервные копии, необходимые для выполнения восстановления до точки во времени в течение периода хранения резервной копии, сохраняются в хранилище резервных копий. Например, если период хранения резервной копии равен 7 дням, окном восстановления считаются последние 7 дней. В этом сценарии сохраняются все резервные копии, необходимые для восстановления сервера за последние 7 дней. При окне хранения резервных копий в семь дней

  • На серверах общего назначения версии 1 (поддерживающих хранение до 4 ТБ данных) будет храниться до 2 полных резервных копий базы данных, все разностные резервные копии и резервные копии журнала транзакций, выполненные после самой ранней полной резервной копии базы данных.
  • На серверах общего назначения версии 2 (поддерживающих хранение до 16 ТБ данных) будет храниться полный моментальный снимок базы данных и резервные копии журналов транзакций за последние 8 дней.

Длительное хранение

В настоящее время служба не поддерживает долгосрочное хранение резервных копий (свыше 35 дней). Вы можете использовать mysqldump, чтобы создавать резервные копии и хранить их в течение длительного времени. Наша группа поддержки опубликовала статью с пошаговыми инструкциями, которые помогут вам в создании такой резервной копии.

географическое и локальное

В службе "База данных Azure для MySQL" вы можете выбрать локально избыточное или геоизбыточное хранилище резервных копий в ценовой категории "Общего назначения" или "С оптимизацией для операций в памяти". Резервные копии в геоизбыточном хранилище не только хранятся в регионе, где размещен сервер, но и реплицируются в связанный центр обработки данных. Благодаря этому сервер лучше защищен и его можно восстановить в другом регионе в случае аварии. На уровне "Базовый" предоставляется только локально избыточное хранилище резервных копий.

Примечание.

Для регионов "Центральная Индия", "Центральная Франция", "Северная часть ОАЭ", "Северная часть ЮАР" хранилище общего назначения версии 2 доступно в общедоступной предварительной версии. Если вы создаете исходный сервер в хранилище общего назначения версии 2 (поддерживающем хранение до 16 ТБ данных) в указанных выше регионах, включение геоизбыточного резервного копирования не поддерживается.

Переход с локально избыточного хранилища на хранилище резервных копий

Хранилище резервных копий (локально избыточное или геоизбыточное) можно настроить только на этапе создания сервера. После подготовки сервера невозможно изменить тип избыточности для хранилища резервных копий. Чтобы переместить хранилище резервных копий из локально избыточного хранилища в геоизбыточное хранилище, необходимо создать новый сервер и перенести данные, выполнив их дамп и восстановление — это единственный поддерживаемый вариант.

Стоимость хранилищ резервных копий

В службе "База данных Azure для MySQL" хранилище для резервных копий размером до 100 % объема подготовленного хранилища базы данных предоставляется бесплатно. За дополнительный объем хранилища резервных копий взимается плата (за ГБ в месяц). Например, если вы подготовили сервер с хранилищем объемом 250 ГБ, вам будут бесплатно предоставлены дополнительные 250 ГБ для хранения резервных копий сервера. Плата за использование хранилища для резервных копий свыше 250 ГБ рассчитывается в соответствии с моделью ценообразования.

Для отслеживания потребляемого сервером пространства в хранилище резервных копий можно использовать метрику Используемое хранилище резервных копий в Azure Monitor. Эта метрика представляет собой суммарную емкость хранилища, используемую для хранения всех резервных копий баз данных, разностных резервных копий и резервных копий журналов на основе периода хранения, заданного для сервера. Периодичность резервного копирования управляется службой и описана выше. Высокая активность транзакций на сервере может привести к увеличению использования хранилища резервных копий, независимо от общего размера базы данных. Для геоизбыточного хранилища резервных копий используется вдвое больший объем, чем для локально избыточного.

Основным способом управления затратами на хранение резервных копий является установка соответствующего периода хранения резервных копий и выбор правильных параметров избыточности резервных копий в соответствии с необходимыми целями восстановления. Можно установить период хранения от 7 до 35 дней. Серверы общего назначения и оптимизированные для операций в памяти серверы могут использовать для резервных копий геоизбыточное хранилище.

Восстановление

В Базе данных Azure для MySQL при восстановлении создается новый сервер из резервных копий исходного сервера и восстанавливаются все базы данных, содержащиеся на сервере. Восстановление в настоящее время не поддерживается, если исходный сервер находится в остановленном состоянии.

Есть два типа восстановления:

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

Предполагаемое время восстановления сервера зависит от нескольких факторов:

  • размер баз данных;
  • число участвующих журналов транзакций;
  • объем операций, которые требуется воспроизвести для восстановления до точки восстановления;
  • пропускная способность сети, если выполняется восстановление в другой регион;
  • количество одновременных запросов на восстановление, обрабатываемых в целевом регионе.
  • Наличие первичного ключа в таблицах базы данных. Для ускорения восстановления рекомендуется добавить первичный ключ для всех таблиц в базе данных. Проверить, есть ли у таблиц первичный ключ, можно с помощью следующего запроса.
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Восстановление большой или очень активной базы данных может занять несколько часов. В случае длительного сбоя в регионе для аварийного восстановления будет инициировано большое количество запросов на геовосстановление. При большом числе запросов время восстановления отдельных баз данных может увеличиться. В большинстве случаев на восстановление базы данных требуется менее 12 часов.

Внимание

Удаленные серверы могут быть восстановлены только в течение пяти дней с момента удаления резервных копий. Получить доступ к резервной копии базы данных и выполнить восстановление можно только из подписки Azure, в которой размещен сервер. Инструкции по восстановлению удаленного сервера см. в документированных действиях. Чтобы защитить ресурсы сервера после развертывания от случайного удаления или внесения непредвиденных изменений, администраторы могут использовать блокировки управления.

Восстановление на определенный момент времени

Независимо от типа избыточности для резервного копирования, вы можете выполнить восстановление до любой точки во времени в пределах срока хранения резервной копии. Новый сервер создается в том же регионе Azure, где расположен исходный сервер, и с такими же конфигурацией ценовой категории, поколением вычислительных ресурсов, числом виртуальных ядер, размером хранилища, сроком хранения резервных копий и типом избыточности резервного копирования.

Примечание.

Существуют два параметра сервера, которые сбрасываются на значения по умолчанию (и не копируются с сервера-источника) после операции восстановления.

  • time_zone — это значение, которое будет иметь значение SYSTEM, установленное по умолчанию;
  • event_scheduler — на восстановленном сервере имеет значение OFF.

Эти параметры сервера необходимо задать путем повторной настройки параметра сервера.

Восстановление до точки во времени подходит для большинства сценариев. Например, если пользователь случайно удалил данные, важные таблицы или базы данных либо если приложение в результате ошибки случайно перезаписало правильные данные неправильными.

Возможно, вам придется подождать, пока создастся резервная копия журналов транзакций, прежде чем выполнить восстановление до точки во времени в пределах последних пяти минут.

Геовосстановление

Вы можете восстановить сервер в другом регионе Azure, где доступна служба, если вы настроили для сервера геоизбыточное хранилище.

  • Серверы хранилища общего назначения версии 1 (поддерживающие до 4 ТБ) можно восстановить в геопарном регионе или в любой регион Azure, поддерживающий База данных Azure для MySQL — односерверную службу.
  • Серверы хранилища общего назначения версии 2 (поддерживающие хранение до 16 ТБ данных) можно восстановить только в регионах Azure, поддерживающих инфраструктуру серверов хранилища общего назначения версии 2. Список поддерживаемых регионов приведен в разделе Ценовые категории Базы данных Azure для MySQL.

Геовосстановление используется по умолчанию, когда сервер недоступен из-за аварии в регионе, в котором он размещен. Если из-за масштабной аварии в регионе приложение базы данных станет недоступным, сервер можно будет восстановить из геоизбыточных резервных копий на сервер в любом другом регионе. При геовосстановлении используется самая последняя резервная копия сервера. Между созданием резервной копии и ее репликацией в другом регионе может пройти некоторое время. Эта задержка может длиться до часа, поэтому в случае аварии возможна потеря данных за час или менее.

Внимание

Если географическое восстановление выполняется для вновь созданного сервера, то начальная синхронизация резервных копий может занять более 24 часов в зависимости от размера данных, так как время создания первоначальной полной резервной копии моментального снимка значительно выше. Последующие резервные копии моментальных снимков являются добавочными, поэтому восстановление выполняется быстрее по истечении 24 часов после создания сервера. Если вы оцениваете географические восстановления, чтобы определить RTO, то для того, чтобы получить более точную оценку, рекомендуем выполнить ее только через 24 часа с момента создания сервера.

Во время геовосстановления можно изменить такие конфигурации сервера, как поколение вычислительных ресурсов, виртуальное ядро, срок хранения резервных копий и варианты избыточности для резервного копирования. Изменить ценовую категорию ("Базовый", "Общего назначения" или "С оптимизацией для операций в памяти") и объем хранилища во время геовосстановления нельзя.

Предполагаемое время восстановления будет зависеть от нескольких факторов, включая размер базы данных, размер журнала транзакций, пропускную способность сети и общее количество баз данных, восстанавливаемых в том же регионе и в то же время. Обычно время восстановления составляет менее 12 часов.

Задачи после восстановления

После восстановления с помощью любого из механизмов восстановления необходимо выполнить следующие задачи, прежде чем данные и приложения станут доступными:

  • Если новый сервер заменит исходный, перенаправьте клиенты и клиентские приложения на новый сервер.
  • Убедитесь, что заданы соответствующие правила виртуальной сети, чтобы пользователи могли установить подключение. Эти правила не копируются с исходного сервера.
  • Убедитесь, что заданы соответствующие данные для входа и разрешений уровня базы данных.
  • Настройте оповещения соответствующим образом.

Следующие шаги

  • Дополнительные сведения о непрерывности бизнес-процессов см. в этой статье.
  • Сведения о восстановлении базы данных до точки во времени с помощью портала Azure приведены в этой статье.
  • Сведения о восстановлении базы данных до точки во времени с помощью интерфейса командной строки Azure можно найти в этой статье.