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

Активная георепликация

Применимо к:Azure SQL Database

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

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

Вы также можете перенести базу данных SQL с активной георепликацией.

Обзор

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

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

Схема активной георепликации.

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

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

Активная георепликация использует технологию группы доступности Always On для асинхронной репликации журнала транзакций, созданного на первичной реплике на все геореплики. Хотя в определенный момент времени база данных-получатель может немного отстать от базы данных-источника, данные в базе данных-получателе будут всегда согласованы с точки зрения транзакций. Другими словами, изменения, внесенные незафиксированными транзакциями, не отображаются.

Примечание.

Активная георепликация реплицирует изменения путем потоковой передачи журнала транзакций базы данных с первичной реплики на вторичные реплики. Она не связана с репликацией транзакций, которая реплицирует изменения путем выполнения команд DML (INSERT, UPDATE, DELETE) на подписчиках.

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

На следующем рисунке показан пример активной георепликации, настроенной с основным узлом в регионе "Запад США 2" и гео-вторичной базой данных в регионе "Восток США".

Скриншот портала Azure, показывающий георепликацию базы данных SQL.

Активная георепликация может использоваться не только для аварийного восстановления, но и в следующих сценариях:

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

Добавление региональной избыточности для баз данных — это лишь часть решения для обеспечения полной непрерывности бизнес-процессов. Для комплексного восстановления приложения (службы) после катастрофического сбоя необходимо восстановить все компоненты, из которых состоит служба и все зависимые службы. К примерам этих компонентов относятся клиентское программное обеспечение (например, браузер с пользовательским кодом JavaScript), интерфейсные веб-серверы, хранилище и DNS. Важно, чтобы все компоненты были устойчивы к одинаковым сбоям и становятся доступными в течение целевого времени восстановления (RTO) приложения. Следовательно, необходимо определить все зависимые службы и получить сведения о гарантиях и возможностях, которые они предоставляют. Затем необходимо предпринять надлежащие меры, чтобы гарантировать работоспособность вашей службы во время переключения отказоустойчивых служб, от которых она зависит. Дополнительные сведения о разработке решений для аварийного восстановления см. в разделе Проектирование глобально доступных служб с помощью Azure SQL Database.

Терминология и возможности

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

  • Доступные для чтения гео-вторичные реплики: приложение может получить доступ к гео-вторичной реплике для выполнения запросов только для чтения, используя те же или разные субъекты безопасности, используемые для доступа к основной базе данных. Дополнительные сведения см. в разделе "Использование реплик только для чтения" для разгрузки рабочих нагрузок запросов только для чтения.

Внимание

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

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

    • Проводите тесты по аварийному восстановлению в продакшене при недопустимой потере данных.
    • Перемещение базы данных в другой регион
    • Возвратите базу данных в основной регион после устранения сбоя (известно как возврат к исходному состоянию).

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

Внимание

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

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

Совет

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

  • Георепликация баз данных в эластичном пуле: каждая георезервная база данных может быть отдельной базой данных или базой данных в эластичном пуле. Выбор эластичного пула для каждой геосекундной базы данных является индивидуальным и не зависит от конфигурации каких-либо других реплик в топологии (ни основной, ни вторичной). Каждый эластичный пул находится на одном логическом сервере. Так как имена баз данных на логическом сервере должны быть уникальными, нескольким вторичным репликам одной и той же первичной базы данных не может быть предоставлен доступ к одному и тому же эластичному пулу.

  • Управляемое пользователем гео-отказоустойчивость и возврат: гео-вторичный объект, который завершил начальную инициализацию, можно явно переключить на основную роль (переключение при отказе) в любое время приложением или пользователем. Во время сбоя, когда основной недоступен, можно использовать только принудительное переключение, которое немедленно продвигает геосекундарный в качестве новой первичной. После устранения сбоя система автоматически превращает восстановленную первичную базу данных во вторичную геобазу данных и приводит ее в соответствие с новой первичной базой данных. Из-за асинхронной природы георепликации последние транзакции могут быть потеряны во время принудительного переключения, если основной сервер выходит из строя до репликации этих транзакций в вторичный регион. При отказе первичной реплики с несколькими геовторичными репликами система автоматически перенастраивает отношения репликации и связывает оставшиеся геовторичные реплики с вновь назначенной первичной репликой без какого-либо вмешательства пользователя. После устранения сбоя, вызвавшего георезервирование, может потребоваться вернуть основной сервер в исходный регион. Для этого выполните отработку отказа вручную.

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

Подготовка к географическому отказоустойчивому переключению

Чтобы гарантировать, что приложение сможет получить доступ к новому основному серверу сразу же после геоотказа, убедитесь в том, что проверка подлинности и сетевой доступ для вторичного сервера настроены правильно. Дополнительные сведения см. в статье Настройка и управление безопасностью Azure SQL Database при геовосстановлении или аварийном переключении. Кроме того, убедитесь, что политика хранения резервных копий для базы данных-получателя соответствует этой политике для базы данных-источника. Этот параметр не является частью базы данных и не реплицируется из основной базы данных. По умолчанию для базы данных-получателя с георепликацией устанавливается период хранения для восстановления на определенный момент времени, равный 7 дням. Дополнительные сведения см. в статье Automated backups in Azure SQL Database.

Внимание

Если база данных входит в состав группы отказоустойчивости, запустить её переключение с помощью команды переключения георепликации нельзя. Используйте команду переключения на резерв для группы. Если необходимо выполнить переключение на резервный сервер для отдельной базы данных, сначала нужно удалить ее из группы переключения на резервный сервер. Общие сведения о группах Failover Рекомендации (Azure SQL Database) для получения дополнительных сведений.

Настройка географической вторичной реплики

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

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

Совет

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

Если вы решите создать гео-вторичную реплику с другой конфигурацией, следует отслеживать скорость операций ввода-вывода журнала на первичной реплике в течение времени. Это позволяет оценить минимальный размер вычислительных ресурсов вторичной геореплики, необходимый для удовлетворения нагрузки репликации. Например, если база данных-источник — P6 (1000 DTU), а ее журнал ввода-вывода поддерживается на уровне 50%, гео-вторичный должен иметь по крайней мере P4 (500 DTU). Чтобы получить исторические данные ввода-вывода, используйте представление sys.resource_stats. Чтобы получить последние данные журнала ввода-вывода с более высокой степенью детализации, которая лучше отражает краткосрочные пики, используйте представление sys.dm_db_resource_stats .

Совет

Регулирование операций ввода-вывода журнала транзакций может выполняться в следующих сценариях:

  • Если гео-вторичный имеет меньший размер вычислительных ресурсов, чем основной. Ищите тип ожидания HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO в представлениях базы данных sys.dm_exec_requests и sys.dm_os_wait_stats.
  • Регулирование также может возникать по причинам, не связанным с размером вычислительных ресурсов, например, при больших рабочих нагрузках для массовой вставки, SELECT INTO и сборки индекса. Дополнительные сведения о типах ожидания для различных видов ограничения ввода-вывода журнала см. в разделе "Управление скоростью журнала транзакций".

По умолчанию избыточность хранилища резервных копий вторичной геореплики аналогична избыточности хранилища резервных копий базы данных-источника. При настройке вторичной геореплики можно выбрать другую избыточность хранилища резервных копий. Резервные копии всегда создаются в базе данных-источнике. Если для вторичной геореплики выбрана другая избыточность хранилища резервных копий, то после гео-переключения, когда вторичная геореплика будет повышена до уровня первичной, новые резервные копии будут храниться и тарифицироваться в соответствии с типом хранилища (RA-GRS, ZRS, LRS), выбранным для новой первичной реплики (ранее вторичной).

Экономия на затратах с помощью резервной реплики

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

Ознакомьтесь с бесплатной резервной репликой, чтобы узнать больше.

Георепликация между подписками

  • Портал Azure можно использовать для настройки активной георепликации между подписками, если обе подписки находятся в одном клиенте Microsoft Entra.

    • Чтобы создать георезервную реплику в подписке отличной от подписки основной в другом клиенте Microsoft Entra, используйте аутентификацию SQL и T-SQL. Аутентификация Microsoft Entra для Azure SQL для георепликации между подписками не поддерживается, если логический сервер находится в другом тенанте Azure.
    • Операции георепликации между подписками, включая настройку и геоотказ, также поддерживаются с помощью REST API создания или обновления баз данных.

  • Создание георепликации между подписками на логическом сервере в том же или другом клиенте Microsoft Entra не поддерживается, если проверка подлинности Microsoft Entra только с помощью Azure SQL включена на первичном или вторичном логическом сервере, а создание пытается использовать Microsoft Entra ID пользователя.

Методы и пошаговые инструкции см. в разделе Tutorial: настройка активной георепликации и отработки отказа (Azure SQL Database).

Частные конечные точки

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

Если частная конечная точка настроена, но доступ к общедоступной сети разрешен, добавление вторичной геореплики поддерживается при подключении к серверу-источнику с общедоступного IP-адреса.

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

Синхронизация учетных данных и правил брандмауэра

При использовании доступа к общедоступной сети для подключения к базе данных рекомендуется использовать правила брандмауэра IP уровня базы данных для геореплицированных баз данных. Эти правила реплицируются в базу данных, что позволяет гарантировать, что на всех вторичных георепликах будут использоваться те же правила брандмауэра для IP-адресов, что и на первичной реплике. Такой подход избавляет клиентов от необходимости вручную настраивать и обслуживать правила брандмауэра на серверах, на которых размещаются базы данных-источники и базы данных-получатели. Аналогичным образом, использование пользователей автономной базы данных для доступа к данным гарантирует, что как первичные, так и вторичные базы данных всегда имеют одинаковые учетные данные проверки подлинности. Таким образом, после географического отказоустойчивого переключения не происходит сбоев из-за несоответствия учетных данных аутентификации. Если вы используете логины и пользователей (а не содержащихся пользователей), необходимо предпринять дополнительные шаги, чтобы убедиться, что во вторичной базе данных существуют те же логины. Сведения о конфигурации см. в разделе Настройка и управление безопасностью Azure SQL Database для геовосстановления или переключения на резервный сервер.

Масштабирование базы данных-источника

Вы можете увеличить или уменьшить масштаб основной базы данных до другого размера вычисления (в рамках одного уровня обслуживания) без отключения всех вторичных геореплик. При увеличении масштаба рекомендуется сначала увеличить масштабы вторичного геообъекта, а затем первичного объекта. При уменьшении масштаба действия следует выполнять в обратном порядке: сначала уменьшайте основной экземпляр, затем — вторичный.

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

Предотвращение потери критически важных данных

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

Примечание.

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

Отслеживание задержки георепликации

Чтобы отслеживать задержку в отношении RPO, используйте столбец replication_lag_secsys.dm_geo_replication_link_status в основной базе данных. Он показывает задержку в секундах между транзакциями, зафиксированными в основном экземпляре базы данных, и записанными на диск в журнал транзакций на вторичном экземпляре. Например, если задержка составляет одну секунду, это означает, что если основной сервер будет подвержен сбою в данный момент и инициируется гео-фейловер, транзакции, зафиксированные в течение последней секунды, будут потеряны.

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

Совет

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

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

Программное управление активной георепликацией

Активная георепликация также может управляться программным способом с помощью T-SQL, Azure PowerShell и REST API. В приведенных ниже таблицах описан доступный для этого набор команд. Активная георепликация включает набор API Azure Resource Manager для управления, включая Azure SQL Database REST API и Azure PowerShell cmdlets. Эти API поддерживают Azure управление доступом на основе ролей (Azure RBAC). Дополнительные сведения о реализации ролей доступа см. в разделе Azure управление доступом на основе ролей (Azure RBAC).

Внимание

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

Команда Описание
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте ADD SECONDARY ON SERVER аргумент для создания вторичной базы данных для существующей базы данных и начать репликацию данных
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS для переключения вторичной базы данных в первичную для инициирования отказоустойчивости.
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте REMOVE SECONDARY ON SERVER для прекращения репликации данных между базой данных SQL и указанной базой данных-получателем.
sys.geo_replication_links Возвращает сведения о всех существующих связях репликации для каждой базы данных на сервере.
sys.dm_geo_replication_link_status Получает время последней репликации, задержку при последней репликации и другие сведения о связи репликации для заданной базы данных.
sys.dm_operation_status Показывает состояние всех операций с базой данных, включая изменения связей репликации.
sys.sp_wait_for_database_copy_sync (ожидание синхронизации копии базы данных) Приложение будет ожидать, пока все зафиксированные транзакции не будут записаны в журнал транзакций гео-вторичного узла.

Troubleshooting

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

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

Настройка активной георепликации:

Другое содержимое непрерывности бизнес-процессов:

  • Last updated on