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

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

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

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

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

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

Обзор

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

  • Читаемые гео-вторичные реплики

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

    Внимание

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

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

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

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

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

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

    Внимание

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

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

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

    Совет

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

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

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

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

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

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

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

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

Чтобы гарантировать, что приложение сможет получить доступ к новой базе данных-источнику сразу же после географически распределенной отработки отказа, убедитесь в том, что проверка подлинности и сетевой доступ для сервера-получателя настроены правильно. Дополнительные сведения см. в статье Настройка и управление безопасностью базы данных Azure SQL для геовосстановления или аварийного переключения. Кроме того, убедитесь, что политика хранения резервных копий для базы данных-получателя соответствует этой политике для базы данных-источника. Этот параметр не является частью базы данных и не реплицируется из источника. По умолчанию для базы данных-получателя с георепликацией устанавливается период хранения для восстановления на определенный момент времени, равный 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 не поддерживается, если проверка подлинности только для Microsoft Entra включена на первичном или вторичном логических серверах, а создание пытается использовать пользователя Идентификатора Microsoft Entra.

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

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

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

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

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

При использовании доступа к общедоступной сети для подключения к базе данных рекомендуется использовать правила брандмауэра IP уровня базы данных для геореплицированных баз данных. Эти правила реплицируются в базу данных, что позволяет гарантировать, что на всех вторичных георепликах будут использоваться те же правила брандмауэра для IP-адресов, что и на первичной реплике. Такой подход избавляет клиентов от необходимости вручную настраивать и обслуживать правила брандмауэра на серверах, на которых размещаются базы данных-источники и базы данных-получатели. Аналогичным образом, использование пользователей автономной базы данных для доступа к данным гарантирует, что как первичные, так и вторичные базы данных всегда имеют одинаковые учетные данные проверки подлинности. Таким образом, после геоработки отказа нет сбоев из-за несоответствия учетных данных проверки подлинности. Если вы используете имена входа и пользователи (а не содержащиеся пользователи), необходимо выполнить дополнительные действия, чтобы убедиться, что для базы данных-получателя существуют те же имена входа. Сведения о конфигурации см. в статье "Настройка и управление безопасностью базы данных 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 задержка может быть продолжительной и зависит от размера еще не переданного журнала транзакций базы данных-источника во время вызова.

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

Чтобы отслеживать задержку в отношении RPO, используйте столбец 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, включая REST API для Базы данных SQL Azure и командлеты Azure PowerShell. Эти 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 (ожидание синхронизации копии базы данных) Приложение будет ожидать, пока все зафиксированные транзакции не будут записаны в журнал транзакций вторичной геореплики.

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

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

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