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

  • Статья

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

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

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

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

Обзор

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

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

active geo-replication

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

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

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

Примечание.

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

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

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

geo-replication relationship

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

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

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

Терминология и возможности активной георепликации

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

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

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

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

    Важно!

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

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

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

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

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

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

    Важно!

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

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

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

    Совет

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

Используйте Transact-SQL (T-SQL) создайте геоторичную в подписке, отличную от подписки первичной (будь то в том же клиенте Идентификатора Microsoft Entra (ранее Azure Active Directory) или нет. Дополнительные сведения см. в статье "Настройка активного гео-реплика tion".

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

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

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

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

Примечание.

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

Важно!

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

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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

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

Важно!

Приведенные ниже команды T-SQL применяются только к активной георепликации и не применяются к группам отработки отказа. Поэтому они также не применяются к Управляемому экземпляру 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 Приложение будет ожидать, пока все зафиксированные транзакции не будут записаны в журнал транзакций вторичной геореплики.

PowerShell: управление географически распределенной отработкой отказа для отдельных баз данных и баз данных в пуле

Примечание.

В этой статье предусмотрено использование модуля Azure Az PowerShell, который является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Важно!

Модуль PowerShell Azure Resource Manager по-прежнему поддерживается базой данных SQL Azure, но вся будущая разработка сосредоточена на модуле Az.Sql. Сведения об этих командлетах см. в разделе AzureRM.Sql. Аргументы команд в модулях Az и AzureRm практически идентичны.

Командлет Description
Get-AzSqlDatabase Получает одну или несколько баз данных.
New-AzSqlDatabaseSecondary Создает базу данных-получатель для существующей базы данных и начинает репликацию данных.
Set-AzSqlDatabaseSecondary Преобразует базу данных-получатель в базу данных-источник для запуска отработки отказа.
Remove-AzSqlDatabaseSecondary Завершает репликацию данных между базой данных SQL и указанной базой данных-получателем.
Get-AzSqlDatabaseReplicationLink Получает связи георепликации для базы данных.

Совет

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

REST API: управление географически распределенной отработкой отказа для отдельных баз данных и баз данных в пуле

API Description
Создание или обновление базы данных (createMode=Restore) Создает, обновляет или восстанавливает базу данных-источник или базу данных-получатель.
Получение, создание или обновление состояния базы данных Возвращает состояние во время операции создания.
Задание базы данных-получателя в качестве базы данных-источника (плановая отработка отказа) Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник. Этот параметр не поддерживается в Управляемом экземпляре SQL.
Задание базы данных-получателя в качестве базы данных-источника (внеплановая отработка отказа) Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник. Эта операция может привести к потере данных. Этот параметр не поддерживается в Управляемом экземпляре SQL.
Получение связи репликации Получает определенную связь репликации для заданной базы данных, участвующей в партнерстве георепликации. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links. Этот параметр не поддерживается в Управляемом экземпляре SQL.
Replication Links - List By Database (Ссылки для репликации: вывод списка по базе данных) Получает все связи репликации для заданной базы данных, участвующей в партнерстве георепликации. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links.
Удаление связей репликации Удаляет связь репликации базы данных. Невозможно выполнить во время отработки отказа.

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