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

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

Обзор резервного копирования

Гибкий сервер Базы данных Azure для MySQL поддерживает два типа резервных копий, чтобы обеспечить повышенную гибкость для поддержания резервных копий критически важных для бизнеса данных.

Автоматизированное резервное копирование

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

Резервное копирование по требованию

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

Вы не можете экспортировать эти файлы резервного копирования. Резервные копии можно использовать только для операций восстановления в гибком сервере Базы данных Azure для MySQL. Для копирования базы данных можно также использовать mysqldump из клиента MySQL.

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

Резервные копии на гибких серверах создаются с использованием моментальных снимков. Первое резервное копирование моментальных снимков запланировано сразу после создания сервера. Система выполняет резервное копирование моментальных снимков один раз в день. Резервные копии журналов транзакций выполняются каждые пять минут.

Если запланированное резервное копирование завершается сбоем, служба резервного копирования пытается выполнить резервное копирование каждые 20 минут, пока она не будет выполнена успешно. Тяжелые транзакционные производственные нагрузки на сервере могут привести к сбоям резервного копирования.

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

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

Чтобы изменить интервал резервного копирования, перейдите в раздел "Параметры > вычислений и хранилища " и задайте поле "Интервал резервного копирования ". Интервал по умолчанию — 24 часа, но его можно изменить на 12 или 6 часов.

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

Гибкий сервер Базы данных Azure для MySQL сохраняет несколько копий резервных копий, чтобы данные были защищены от запланированных и незапланированных событий. К этим событиям относятся временные сбои оборудования, сети или сбоя питания и массовые стихийные бедствия. Гибкий сервер Базы данных Azure для MySQL обеспечивает гибкость в выборе между локально избыточным, избыточным между зонами или геоизбыточным хранилищем резервных копий на уровнях "Базовый", "Общего назначения" и "Memory-Optimized". По умолчанию гибкий сервер Базы данных Azure для MySQL использует локально избыточное хранилище резервных копий для серверов с высоким уровнем доступности (HA) одной зоны или без конфигурации высокой доступности, а для серверов с конфигурацией высокого уровня доступности с избыточностью между зонами используется избыточное по зонам хранилище резервных копий.

Избыточность резервного копирования гарантирует, что база данных соответствует ее целям доступности и устойчивости даже в случае сбоев. Гибкий сервер Базы данных Azure для MySQL предлагает три варианта:

• Локально избыточное хранилище резервных копий : при использовании локально избыточного хранилища резервных копий система сохраняет несколько копий резервных копий в одном центре обработки данных. Этот вариант защищает ваши данные от сбоев в стойках сервера и на дисках. Он также обеспечивает по крайней мере 99,999999999% (11 девяток) долговечности объектов резервных копий в течение указанного года. По умолчанию хранилище резервных копий для серверов с высокой доступностью в пределах одной зоны или без такой конфигурации настраивается как локально избыточное.

• Хранилище резервных копий, избыточное между зонами: при использовании хранилища резервных копий, избыточного между зонами, система сохраняет несколько копий в зоне доступности, в которой размещен сервер. Он также реплицирует резервные копии в другую зону доступности в том же регионе. Используйте этот параметр для сценариев, требующих высокой доступности или ограничения репликации данных в страну или регион для удовлетворения требований к месту расположения данных. Он обеспечивает по крайней мере 99,9999999999% (12 девяток) долговечности объектов резервных копий в течение заданного года. Выберите параметр высокой доступности с избыточностью между зонами при создании сервера, чтобы обеспечить хранилище резервных копий. После создания сервера можно отключить высокую доступность, но хранилище резервных копий остается зонально избыточным.

• Геоизбыточное хранилище резервных копий: при использовании геоизбыточного хранилища резервных копий система хранит несколько копий в регионе, в котором размещен сервер. Он также реплицирует резервные копии в геопарированный регион. Этот параметр обеспечивает лучшую защиту и возможность восстановления сервера в другом регионе в случае аварии. Он обеспечивает по крайней мере 99,999999999999999% (16 девяток) надежности объектов резервного копирования в течение заданного года. Вы можете включить параметр Geo-Redundancy во время создания сервера, чтобы обеспечить геоизбыточное хранилище резервных копий. Кроме того, после создания сервера можно перейти из локально избыточного хранилища в геоизбыточное хранилище. Геоизбыточность поддерживается для серверов, размещенных в любом из пар регионов Azure.

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

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

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

• Переход от избыточного хранения резервных копий между зонами к геоизбыточному хранилищу. Гибкий сервер базы данных Azure для MySQL не поддерживает преобразование из избыточного хранения между зонами в геоизбыточное хранилище через настройки вычислений и хранилища после подготовки сервера. Чтобы переместить хранилище резервных копий из зонально-избыточного хранилища в геоизбыточное хранилище, у вас есть два варианта: a) Используйте PITR (восстановление на определенный момент времени) для восстановления сервера с требуемой конфигурацией. b) Создайте новый сервер с требуемой конфигурацией и перенесите данные с помощью дампа и восстановления.

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

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

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

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

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

Чтобы отслеживать объем хранилища резервных копий, используемого сервером, используйте метрику Monitor Azure Database for MySQL - Гибкий сервер в Azure Monitor, доступную на портале Azure. Хранилище резервных копий использует метрику, которая представляет собой суммарную емкость хранилища, используемую для хранения всех резервных копий баз данных и журналов на основе периода хранения резервных копий, заданного для сервера. Тяжелые операции транзакций на сервере могут привести к увеличению использования хранилища резервных копий независимо от общего размера базы данных. Хранилище резервных копий, используемое для геоизбыточного сервера, в два раза больше, чем для локально избыточного сервера.

Задайте соответствующий период хранения резервных копий для управления затратами на хранилище резервных копий. Срок хранения можно выбрать в диапазоне от 1 до 35 дней.

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

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

Восстановить

В гибком сервере Базы данных Azure для MySQL восстановление создает новый сервер из резервных копий исходного сервера. Доступны два типа восстановления:

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

Некоторые факторы влияют на предполагаемое время восстановления сервера:

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

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

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

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

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

Вы можете выбрать между последней точкой восстановления, пользовательской точкой восстановления и самой быстрой точкой восстановления (восстановление с использованием полной резервной копии) через функцию восстановления на определённый момент времени в Azure Database for MySQL - Flexible Server через портал Azure.

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

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

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

Если вы настроите сервер на использование геоизбыточного резервного копирования, его можно восстановить в его геопарном регионе или любом другом регионе, поддерживаемом Azure, где доступен гибкий сервер Базы данных Azure для MySQL (за исключением Brazil South, USGov Virginiaи West US 3). Возможность восстановления геоизбыточного резервного копирования в любом регионе называется универсальным геовосстановлением.

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

Вы также можете выполнить геовосстановление на остановленном сервере с помощью Azure CLI. Дополнительную информацию см. в разделе "Восстановление на определенный момент времени в Базе данных Azure для MySQL — гибкий сервер с помощью Azure CLI".

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

Выполнение задач после восстановления

После восстановления из последней точки восстановления или пользовательской точки восстановления выполните следующие задачи, чтобы ваши пользователи и приложения вернулись к работе и функции:

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

Долгосрочное хранение (предварительная версия)

Службы гибкого сервера Azure Backup и Базы данных Azure для MySQL создали долгосрочное решение резервного копирования корпоративного класса для экземпляров гибкого сервера Базы данных Azure для MySQL, сохраняющих резервные копии до 10 лет. Вы можете использовать долгосрочное хранение независимо или в дополнение к решению автоматического резервного копирования, предлагаемого Azure Database for MySQL Flexible Server, который предлагает сохранение до 35 дней. Автоматические резервные копии — это моментальные резервные копии, которые подходят для восстановления, особенно если нужно восстановить данные из последних резервных копий. Долгосрочные резервные копии помогают вам соответствовать требованиям и потребностям аудита. Помимо долгосрочного хранения, решение предлагает следующие возможности:

• Управляемые клиентом резервные копии и резервные копии по запросу
• Управляйте всеми операциями и заданиями, связанными с резервными копиями, между серверами, группами ресурсов, расположениями, подписками и клиентами из одной панели стекла, называемой Центром резервного копирования.
• Резервные копии хранятся на отдельных доменах безопасности и сбоя. Если исходный сервер или подписка скомпрометированы, резервные копии остаются в хранилище Azure Backup (в управляемых учетных записях хранилища Azure Backup).

Рекомендации и ограничения

• В предварительной версии восстановление LTR в настоящее время доступно как RestoreasFiles в учетных записях хранения. Функция RestoreasServer будет добавлена в будущем.
• Поддержка создания и управления LTR с помощью Azure CLI в настоящее время не поддерживается.

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

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

Вопросы, связанные с резервным копированием

• Как сделать резервное копирование моего сервера?

  По умолчанию гибкий сервер Базы данных Azure для MySQL позволяет автоматически создавать резервные копии всего сервера (охватывая все базы данных), а срок хранения по умолчанию — семь дней. Вы также можете активировать резервную копию вручную с помощью функции резервного копирования по запросу. Еще один способ вручную создать резервную копию — использовать средства сообщества, такие как mysqldump, задокументированные здесь, или такие как mydumper, описанные здесь. Если вы хотите создать резервную копию экземпляра сервера Azure Database for MySQL Flexible Server в хранилище Blob, ознакомьтесь с блогом на техносообществе Резервное копирование Azure Database for MySQL Flexible Server в хранилище Blob.

• Можно ли настроить долгосрочное хранение автоматически созданных резервных копий?

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

• Что собой представляют окна резервного копирования для сервера? Можно ли настраивать их?

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

• Резервные копии зашифрованы?

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

• Можно ли восстановить одну или несколько баз данных?

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

• Будет ли мой сервер доступен во время окна резервного копирования?

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

• Когда я настрою период обслуживания сервера, нужно ли учесть окно резервного копирования?

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

• Где хранятся автоматически созданные резервные копии и как управлять их хранением?

  Azure Database for MySQL Flexible Server автоматически создает резервные копии серверов и сохраняет их в настраиваемом пользователем локально избыточном хранилище или в геоизбыточном хранилище. Вы не можете экспортировать эти файлы резервного копирования. По умолчанию срок хранения резервных копий составляет 7 дней. При необходимости можно настроить резервное копирование базы данных от 1 до 35 дней.

• Как можно проверить мои резервные копии?

  Лучший способ проверить доступность успешно созданных резервных копий — просмотреть полные автоматизированные резервные копии, созданные в течение периода хранения, в колонке "Резервное копирование и восстановление". Если резервная копия завершается ошибкой, она не указана в списке доступных резервных копий, и служба резервного копирования пытается выполнить резервное копирование каждые 20 минут до тех пор, пока не будет выполнено успешное резервное копирование. Эти сбои резервного копирования возникают из-за высоких нагрузок транзакций в рабочей среде на сервере.

• Где можно просмотреть сведения об использовании резервных копий?

  В портале Azure на вкладке "Мониторинг" в разделе "Метрики" вы можете найти метрику Azure Database для MySQL — гибкий сервер, которая поможет отслеживать общее использование резервных копий.

• Что произойдет с соответствующими резервными копиями, если удалить сервер?

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

• Что происходит с резервными копиями при восстановлении сервера?

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

• Как взимается плата и плата за использование резервных копий?

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

• Как хранятся резервные копии для остановленных серверов?

  Для остановленных серверов новые резервные копии не создаются. Служба сохраняет все старые резервные копии (в окне хранения) во время остановки сервера до перезапуска сервера. После перезапуска сервера хранение резервных копий для активного сервера регулируется его окном хранения резервных копий.

• Как выставляются счета за резервные копии для остановленного сервера?

  При остановке экземпляра сервера взимается плата за выделенное хранилище (включая выделенные IOPS) и хранилище резервных копий (резервные копии, хранящиеся в рамках указанного периода хранения). Бесплатное хранилище резервных копий ограничено размером подготовленной базы данных и применяется только к активным серверам.

• Как защищены данные резервного копирования?

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

• Как операция восстановления на определенный момент времени (PITR) влияет на использование IOPS?

  Во время операции PITR в Базе данных Azure для MySQL — гибкий сервер служба создает новый сервер и копирует данные из хранилища исходного сервера в хранилище нового сервера. Этот процесс увеличивает использование операций ввода-вывода в секунду (IOPS) на исходном сервере. Это увеличение использования IOPS является обычным явлением и не указывает на проблемы с исходным сервером или операцией PITR. Когда операция PITR завершится, показатель IOPS на исходном сервере возвращается на обычный уровень.

Вопросы, связанные с восстановлением

• Как восстановить мой сервер? Портал Azure поддерживает восстановление на определенный момент времени для всех серверов, чтобы можно было восстановить до последней или пользовательской точки восстановления. Чтобы вручную восстановить сервер из резервных копий, созданных mysqldump или MyDumper, см. статью "Восстановление базы данных с помощью myLoader".

• Почему восстановление занимает так много времени?

  Некоторые факторы влияют на предполагаемое время восстановления сервера:

  • Размер баз данных. В процессе восстановления база данных гидратирует данные из последней физической резервной копии. Таким образом, время восстановления пропорционально размеру базы данных.
  • Активная часть действия транзакции, которую процесс должен воспроизвести для восстановления. Восстановление может занять больше времени в зависимости от дополнительной активности транзакций после последней успешной контрольной точки.
  • пропускная способность сети, если выполняется восстановление в другой регион;
  • количество одновременных запросов на восстановление, обрабатываемых в целевом регионе.
  • Наличие первичных ключей в таблицах в базе данных. Чтобы ускорить восстановление, попробуйте добавить первичные ключи для всех таблиц в базе данных.

• Влияет ли изменение переменных базы данных на уровне сеанса на восстановление?

  Изменение переменных уровня сеанса и выполнение инструкций DML в сеансе клиента MySQL может повлиять на операцию восстановления на определенный момент времени (PITR). Эти изменения не записываются в двоичном журнале, который использует операция резервного копирования и восстановления. Например, foreign_key_checks — это переменная уровня сеанса. Если отключить его для запуска инструкции DML, которая нарушает ограничение внешнего ключа, операция восстановления (PITR) завершается ошибкой. Единственное решение в этом сценарии заключается в выборе времени восстановления (PITR) до момента отключения foreign_key_checks . Не изменяйте переменные сеансов для успешного выполнения операции восстановления на заданный момент времени (PITR).

Связанный контент

• непрерывность бизнес-процессов
• зональная избыточность для высокой доступности
• резервное копирование и восстановление