Резервное копирование и восстановление в База данных Azure для MySQL — гибкий сервер

  • Статья

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

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

Обзор службы Azure Backup

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

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

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

Резервное копирование по запросу

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

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

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

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

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

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

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

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

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

  • Геоизбыточное хранилище резервных копий: если резервные копии хранятся в геоизбыточное хранилище резервных копий, несколько копий не только хранятся в регионе, в котором размещен сервер, но и реплика в его геопарированный регион. Благодаря этому сервер лучше защищен и его можно восстановить в другом регионе в случае аварии. Кроме того, это хранилище обеспечивает устойчивость объектов резервного копирования как минимум на 99,99999999999999 % (16 девяток) в течение заданного года. Можно включить вариант геоизбыточности во время создания сервера, чтобы обеспечить геоизбыточное хранилище резервных копий. Кроме того, вы можете перейти с локально избыточного хранилища на геоизбыточное после создания сервера. Геоизбыточность поддерживается для серверов, размещенных в любом из пар регионов Azure.

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

Примечание.

Сервер с поддержкой высокой доступности станет не высокой доступностью (высокий уровень доступности отключен) после восстановления для восстановления на определенный момент времени и геовосстановление.

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

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

Примечание.

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

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

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

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

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

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

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

Внимание

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

Внимание

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

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

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

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

Кроме того, геовосстановление можно выполнить на остановленном сервере с использованием Azure CLI. Чтобы узнать больше о геовосстановления сервера с помощью Azure CLI, ознакомьтесь с База данных Azure для MySQL гибким сервером с помощью Azure CLI.

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

Примечание.

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

Внимание

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

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

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

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

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

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

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

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

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

  • Резервное копирование LTR в настоящее время не поддерживается для серверов с поддержкой высокой доступности. Эта возможность будет добавлена в будущем.

  • Поддержка создания и управления LTR с помощью Azure CLI в настоящее время не поддерживается.

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

Резервное копирование по запросу и экспорт (предварительная версия)

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

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

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

  • Разделы справки резервное копирование сервера?

    По умолчанию База данных Azure для MySQL гибкий сервер позволяет автоматически создавать резервные копии всего сервера (охватывая все базы данных) с периодом хранения по умолчанию 7 дней. Вы также можете активировать резервное копирование вручную с помощью функции резервного копирования по запросу. Другим способом вручную создать резервную копию является использование средств сообщества, таких как mysqldump, как описано здесь или mydumper, как описано здесь. Если вы хотите создать резервную копию База данных Azure для MySQL гибкого экземпляра сервера в хранилище BLOB-объектов, обратитесь к блогу сообщества разработчиков База данных Azure для MySQL гибким сервером в служба хранилища BLOB-объектов.

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

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

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

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

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

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

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

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

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

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

  • При настройке периода обслуживания сервера необходимо учесть окно резервного копирования?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Для остановленных серверов новые резервные копии не создаются. Все старые резервные копии (в окне хранения) во время остановки сервера сохраняются до перезапуска сервера, после чего срок хранения резервных копий для активного сервера регулируется его окном хранения резервных копий.

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

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

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

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

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

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

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

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

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

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

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

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

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