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

  • Статья

Применимо к: База данных SQL Azure

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

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

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

Обзор

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

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

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

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

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

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

Примечание.

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

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

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

Снимок экрана: портал Azure с связью георепликации базы данных SQL.

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

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

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

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

  • Автоматическая асинхронная репликация

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

  • Доступные для чтения вторичные геореплики

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

    Внимание

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

  • Отработка отказа (без потери данных)

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

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

  • Принудительное отработка отказа (потенциальная потеря данных)

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

    Внимание

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

  • Несколько доступных для чтения вторичных геореплик

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

    Совет

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

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

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

  • Управляемые пользователем географически распределенная отработка отказа и восстановление размещения

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

  • Резервная реплика

    Если вторичная реплика используется только для аварийного восстановления (АВАРИЙНОго восстановления) и не имеет рабочих нагрузок чтения или записи, можно назначить реплику в качестве резервной , чтобы сэкономить на затратах на лицензирование.

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

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

Внимание

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

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

Для одного уровня служб требуется как основной, так и геоторийный. Также настоятельно рекомендуется настроить геоторию с одинаковым избыточностью хранилища резервных копий, уровнем вычислений (подготовленным или бессерверным) и размером вычислительных ресурсов (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 базы данных.
  • Причины, не связанные с размером вычислительных ресурсов. Подробные сведения, включая сведения о типах ожидания при различных видах регулирования операций ввода-вывода журнала, см. в статье Управление скоростью журнала транзакций.

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

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

Если вторичная реплика используется только для аварийного восстановления (АВАРИЙНОго восстановления) и не имеет рабочих нагрузок чтения или записи, вы можете сэкономить на затратах на лицензирование, назначив базу данных для ожидания при настройке новой активной связи георепликации.

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

Георепликация при наличии нескольких подписок

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

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

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

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

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

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

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

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

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

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

Сведения о группах отработки отказа см . в разделе масштабирования реплики в группе отработки отказа.

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

Из-за высокой задержки в глобальных сетях георепликация использует механизм асинхронной репликации. Асинхронная репликация делает неизбежной возможность потери данных при отказе первичной реплики. Чтобы защитить эти критические транзакции от потери данных, разработчик приложения может вызвать хранимую процедуру 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 задержка может быть продолжительной и зависит от размера еще не переданного журнала транзакций базы данных-источника во время вызова.

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

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

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

Совет

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

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

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

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

Внимание

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

Команда Description
ALTER DATABASE Используйте аргумент ADD SECONDARY ON SERVER, чтобы создать базу данных-получатель для существующей базы данных и начать репликацию данных.
ALTER DATABASE Используйте аргумент FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS, чтобы задать базу данных-получатель в качестве базы данных-источника для запуска отработки отказа.
ALTER DATABASE Используйте аргумент 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 Приложение будет ожидать, пока все зафиксированные транзакции не будут записаны в журнал транзакций вторичной геореплики.

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

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

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