Настройка высокого уровня доступности и аварийного восстановления
Основная часть настройки решений аварийного восстановления и высокого уровня доступности в SQL Server остается одной и той же в SQL Server, работающей на виртуальной машине Azure. Решение высокого уровня доступности предназначено для обеспечения того, чтобы данные без фиксации не были потеряны из-за сбоев, что рабочая нагрузка не влияет на операции обслуживания, и что база данных не становится одной точкой сбоя в архитектуре программного обеспечения.
Большинство уровней служб SQL Azure предлагают ряд вариантов высокой доступности, от локальной избыточности до моделей избыточности зоны.
Далее мы рассмотрим конкретные решения для аварийного восстановления и высокого уровня доступности для предложений PaaS Azure.
Непрерывное резервное копирование
База данных SQL Azure обеспечивает регулярное и непрерывное резервное копирование баз данных, которые затем реплика в геоизбыточное хранилище для чтения (RA-GRS).
Еженедельные полные резервные копии, разностные резервные копии каждые 12–24 часа и резервные копии журналов транзакций каждые 5–10 минут являются частью стратегии автоматического резервного копирования. Для расширенной доступности резервного копирования (до 10 лет) можно настроить долгосрочное хранение (LTR) для отдельных и пуловых баз данных.
Долгосрочное хранение (LTR)
Azure предлагает политику хранения, которую можно задать за рамки обычных ограничений, что полезно для сценариев, требующих долгосрочного хранения. Можно задать политику хранения до 10 лет, и этот параметр по умолчанию отключен.
На рисунке показано, как настроить долгосрочные политики хранения на портал Azure. После выбора базы данных панель появится справа от экрана, где можно изменить параметры по умолчанию.
Дополнительные сведения о долгосрочном хранении см. в разделе "Долгосрочное хранение" База данных SQL Azure и Управляемый экземпляр SQL Azure.
Геовосстановление
Резервные копии для База данных SQL и Управляемый экземпляр SQL по умолчанию являются геоизбыточными. Это позволяет легко восстанавливать базы данных в другом географическом регионе, которая полезна для менее строгих сценариев аварийного восстановления.
Хранилище резервных копий оплачивается отдельно от обычного хранилища файлов базы данных. Однако при подготовке Базы данных SQL хранилище резервных копий создается с максимальным размером уровня данных, выбранным для базы данных без дополнительных затрат.
Длительность операции геовосстановления может зависеть от нескольких базовых компонентов, включая размер базы данных, количество журналов транзакций, вовлеченных в операцию восстановления, и количество запросов на одновременное восстановление, обрабатываемых в целевом регионе.
Восстановление до точки во времени (PITR)
Вы можете восстановить базы данных до определенной точки во времени в соответствии с определенным временем хранения, но PITR поддерживается только в том случае, если вы восстанавливаете базу данных на том же сервере, где была создана резервная копия. Для восстановления Базы данных SQL можно использовать портал Azure, Azure PowerShell, Azure CLI или REST API.
Активная георепликация
Одним из способов повышения доступности для База данных SQL Azure является использование активной гео-реплика tion. Активная георепликация создает вторичную реплику базы данных в другом регионе с асинхронным обновлением.
Этот реплика доступен для чтения, как и группа доступности AlwaysOn в SQL Server. Под поверхностью Azure использует группы доступности для поддержания этой функциональности, поэтому некоторые термины аналогичны.
Активная георепликация обеспечивает непрерывность бизнес-процессов, позволяя клиентам программно или вручную переключать базы данных-источники на резервные регионы во время серьезной аварии.
Примечание.
Управляемый экземпляр SQL Azure не поддерживает активное гео реплика tion. Вместо этого необходимо использовать группы автоматической отработки отказа, раздел, который мы рассмотрим далее в этом уроке.
Все базы данных, участвующие в отношениях георепликации, должны иметь один и тот же уровень служб. Кроме того, чтобы предотвратить проблемы с производительностью реплика из-за тяжелой рабочей нагрузки записи, рекомендуется настроить вторичные реплика с тем же размером вычислительных ресурсов, что и основной.
Вы можете вручную настроить геоконфигурацию реплика для База данных SQL Azure, выбрав колонку для базы данных, в разделе управления данными, выбрав реплики, а затем + Создать реплика.
После установки вторичной реплика у вас есть возможность вручную инициировать отработку отказа. В этом процессе роли отменяются — вторичная реплика предполагает роль первичной, а исходная первичная становится вторичной.
Георепликация при наличии нескольких подписок
В некоторых сценариях может потребоваться настроить дополнительный реплика в подписке, отличной от базы данных-источника. Это место, где функция гео-реплика между подписками вступает в игру.
Примечание.
Геоизбыточное реплика между подписками доступно только программным способом.
Дополнительные сведения о шагах, необходимых для настройки геокон реплика фигурации между подписками, см. в статье геоза реплика tion между подписками.
группы автоматической отработки отказа.
Группа автоматической отработки отказа — это функция высокой доступности, поддерживаемая как База данных SQL Azure, так и Управляемый экземпляр SQL Azure. Группы автоматической отработки отказа позволяют управлять тем, как базы данных реплика в другой регион и как может произойти отработка отказа. Имя, назначенное группе автоматической отработки отказа, должно быть уникальным в домене *.database.windows.net .
Группа автоматической отработки отказа может включать несколько баз данных. Основной и вторичный имеют одинаковый размер базы данных.
Группы автоматической отработки отказа поддерживают функциональность, похожую на группу доступности, которая называется прослушиватель. Данный компонент позволяет выполнять операции чтения и записи или только для чтения. Существует два разных типа прослушивателей: один для чтения и записи, и один для трафика только для чтения. За кулисами отработки отказа DNS обновляется, чтобы клиенты могли указывать на абстрактное имя прослушивателя и не должны знать ничего другого. Сервер базы данных, содержащий копии, доступные для чтения и записи, является первичным, а сервер, принимающий транзакции из сервера-источника, является получателем.
Существует две разные политики для групп автоматической отработки отказа.
| Тип политики | Description |
|---|---|
| Автоматически | При обнаружении сбоя система автоматически активирует отработку отказа по умолчанию. Однако при необходимости можно отключить автоматическую отработку отказа. |
| Только для чтения | Во время отработки отказа подсистема отключает прослушиватель только для чтения по умолчанию, чтобы поддерживать производительность нового первичного элемента при отключении вторичного. Однако это поведение можно изменить, чтобы разрешить оба типа трафика после отработки отказа. |
Отработка отказа — это процесс, который можно инициировать вручную, даже если включена автоматическая отработка отказа. Однако тип отработки отказа может повлиять на то, возникает ли потеря данных. Например, не плановая отработка отказа может привести к потере данных, если она принудительно и база данных-получатель не полностью синхронизирована с первичной.
Определяет GracePeriodWithDataLossHours продолжительность ожидания Azure перед запуском отработки отказа с значением по умолчанию, равным одному часу. Если целевая точка восстановления (RPO) является строгой, а потеря данных не является параметром, можно задать это значение выше. Хотя это означает, что Azure ожидает больше времени, прежде чем инициировать отработку отказа, это может снизить потерю данных, так как она обеспечивает больше времени для полной синхронизации базы данных-получателя с первичной.
Примечание.
База данных-получатель создается автоматически с помощью процесса, известного как начальное значение, которое может занять некоторое время в зависимости от размера базы данных. Поэтому важно заранее планировать, учитывая такие факторы, как скорость сети.
Дополнительные сведения о высокой доступности и аварийном восстановлении для База данных SQL Azure см. в База данных SQL Azure списке проверка высокого уровня доступности и аварийного восстановления.