Распределенные группы доступности

  • Статья

Применимо к:SQL Server

Распределенная группа доступности — это особый тип группы доступности, который охватывает сразу две отдельные группы доступности. Распределенные группы доступности доступны в SQL Server 2016 и более поздних версий.

В этой статье описывается функция распределенной группы доступности. Сведения о настройке распределенной группы доступности см. в статье Настройка распределенных групп доступности.

Обзор

Распределенная группа доступности — это особый тип группы доступности, который охватывает сразу две отдельные группы доступности. Группы доступности, которые относятся к распределенной группе доступности, необязательно должны находиться в одном расположении. Они могут быть физическими, виртуальными или локальными, размещаться в общедоступном облаке или в любом другом месте, которое поддерживает развертывание групп доступности. Распределенные группы доступности могут включать группы из разных доменов и даже на разных платформах: например, одна группа доступности может быть размещена в Linux, а другая — в Windows. Если две группы доступности могут взаимодействовать, их можно включить в распределенную группу доступности.

Традиционная группа доступности содержит ресурсы, настроенные в отказоустойчивом кластере Windows Server (WSFC) или в Linux, Pacemaker. Распределенная группа доступности не настраивает ресурсы в базовом кластере (WSFC или Pacemaker). Все необходимое хранится в SQL Server. Дополнительные сведения о просмотре данных распределенной группы доступности см. в статье Просмотр сведений о распределенной группе доступности.

Для участия в распределенной группе доступности у группы доступности должен иметься прослушиватель. Однако вместо имени базового сервера для автономного экземпляра (или, если речь идет об экземпляре отказоустойчивого кластера [FCI] SQL Server, то значения, связанного с ресурсом имени сети), необходимого для традиционной группы доступности, вы указываете прослушиватель, настроенный для распределенной группы доступности с параметром ENDPOINT_URL в процессе ее создания. Несмотря на то, что у каждой группы доступности, входящей в распределенную группу доступности, прослушиватель есть, у самой распределенной группы доступности его нет.

На следующем рисунке показано общее представление распределенной группы доступности, охватывающий две группы доступности (AG 1 и AG2), каждая из которых настроена в собственном кластере WSFC. Распределенная группа доступности имеет четыре реплики, по две в каждой группе доступности. Каждая группа доступности может поддерживать до максимального количества реплика, поэтому распределенная группа доступности может содержать до 18 реплика.

Diagram showing a high-level view of a distributed availability group.

Перемещение данных в распределенной группе доступности можно настроить как синхронное или асинхронное. При этом в распределенных группах доступности данные перемещаются не так, как в традиционных. Несмотря на то, что у каждой группы доступности есть первичная реплика, принимать вставки, обновления и удаления может только одна копия баз данных, участвующих в распределенной группе доступности. Как показано на следующем рисунке, первичной группой доступности является AG1. Ее первичная реплика отправляет транзакции в обе вторичные реплики AG1 и в первичную реплику AG2. Первичная реплика AG2 также называется сервером пересылки. Сервер пересылки — это первичная реплика во вторичной группе доступности в распределенной группе доступности. Сервер пересылки получает транзакции из первичной реплики в первичной группе доступности и пересылает их во вторичные реплики в собственной группе доступности. После этого сервер пересылки обновляет вторичные реплики AG2.

Diagram showing a distributed availability group and its data movement.

Единственный способ сделать так, чтобы первичная реплика AG2 принимала вставки, обновления и удаления, — это вручную выполнить отработку отказа распределенной группы доступности из AG1. Поскольку AG 1 содержит доступную для записи копию базы данных, после отработки отказа группа доступности AG2 сможет принимать вставки, обновления и удаления. Сведения о том, как выполнить отработку отказа с переходом из одной группы доступности в другую, см. в статье Отработка отказа с переходом на вторичную группу доступности.

Примечание.

Распределенные группы доступности в SQL Server 2016 поддерживают отработку отказа только с переходом из одной группы доступности в другую с использованием параметра FORCE_FAILOVER_ALLOW_DATA_LOSS.

Примечание.

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

Требования к версии и выпуску

В распределенных группах доступности в SQL Server 2017 или более поздней версии можно смешивать основные версии SQL Server в пределах одной и той же распределенной группы доступности. Группа доступности, содержащая основную реплику для чтения и записи, может иметь ту же версию или ниже, чем у других групп доступности, участвующих в распределенной группе доступности. Другие группы доступности могут относиться к той же или более поздней версии. Этот сценарий предназначен для обновления и миграции. Например, если группа доступности, содержащая первичную реплику чтения и записи, — это SQL Server 2016, но требуется обновление или миграция на SQL Server 2017 или более поздние версии, другие группы доступности, участвующие в распределенной группе доступности, можно настроить с помощью SQL Server 2017.

Так как в SQL Server 2012 или 2014 функция распределенных групп доступности еще не существовала, группы доступности, созданные с помощью этих версий, не могут относиться к распределенным группам доступности.

Примечание.

В зависимости от версии SQL Server при подключении к службам Azure (например, ссылке Управляемый экземпляр), можно настроить распределенную группу доступности с выпуском Standard или сочетание выпусков Standard и Enterprise. Ознакомьтесь с КБ5016729, чтобы узнать больше.

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

  1. Начните с обновления реплик второй группы доступности в распределенной группе доступности.

  2. Установите исправления в реплики первичной группы доступности в распределенной группе доступности.

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

Версии Windows Server и распределенные группы доступности

Распределенная группа доступности охватывает несколько групп доступности, каждая из которых занимает собственный кластер WSFC, и работает только в SQL Server. Это означает, что кластеры WSFC, в которых размещаются отдельные группы доступности, могут иметь различные основные версии Windows Server. Как уже говорилось в предыдущем разделе, основные версии SQL Server должны совпадать. Как на исходном изображении, так и на изображении, представленном ниже, показаны группы AG1 и AG2, участвующие в распределенной группе доступности, но в этом случае кластеры WSFC имеют разные версии Windows Server.

Diagram showing a distributed availability groups with WSFCs having different versions of Windows Server.

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

  • Оба кластера WSFC присоединяются к одному домену.
  • Каждый кластер WSFC присоединен к отдельному домену.
  • Один кластер WSFC присоединен к домену, а другой — нет.
  • Ни один кластер WSFC не присоединен ни к одному домену.

Если оба кластера WSFC присоединены к одному домену (не к доверенным доменам), при создании группы доступности никакие дополнительные действия выполнять не нужно. При использовании распределенной группы доступности, в которую входят группы доступности и кластеры WSFC, не присоединенные к одному домену, применяйте сертификаты. Во многом это напоминает создание группы доступности для группы доступности, не зависящей от домена. Чтобы настроить сертификаты для распределенной группы доступности, выполните шаги 3–13 в разделе Создание группы доступности, не зависящей от домена.

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

Сценарии использования

Ниже представлены три основных варианта применения распределенной группы доступности.

Сценарии аварийного восстановления и конфигураций с несколькими сайтами

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

Diagram showing a traditional multi-site availability group.

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

Распределенные группы доступности связаны слабо — в данном случае это означает, что для них необязательно наличие только одного кластера WSFC или обслуживание в SQL Server. Так как кластеры WSFC обслуживаются отдельно, а синхронизация между двумя группами доступности в основном выполняется асинхронно, настроить аварийное восстановление на другом сайте гораздо проще. Первичные реплики в каждой группе доступности синхронизируют свои собственные вторичные реплики.

  • Для распределенной группы доступности поддерживается только отработка отказа вручную. В случае аварийного восстановления и необходимости переключения центров обработки данных настраивать автоматическую отработку отказа не следует (за редкими исключениями).
  • Скорее всего, вам не потребуется настраивать некоторые традиционные элементы или параметры для кластеров WSFC с несколькими сайтами и подсетями, такие как CrossSubnetThreshold, но нужно будет проверить задержку сети на другом уровне транспортировки данных. Разница в том, что каждый кластер WSFC обеспечивает собственную доступность, а не является одной крупной сущностью для четырех узлов. У вас есть два отдельных кластера WSFC, каждый из которых имеет по два узла, как показано на предыдущем рисунке.
  • Мы рекомендуем асинхронное перемещение данных, поскольку этот вариант подходит для аварийного восстановления.
  • При настройке синхронного перемещения данных между первичной и по крайней мере одной вторичной репликой второй группы доступности и синхронного перемещения данных в распределенной группе доступности распределенная группа доступности будет ждать, пока все синхронные копии подтвердят получение данных. Если несколько распределенных групп доступности подключены последовательно (AG1 -> AG2 -> AG3) и настроены для синхронной работы, распределенная группа доступности будет ожидать обновления последней реплики последней группы доступности.

Перенос

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

Возможность миграции особенно полезна в случаях изменения или обновления базовой операционной системы при сохранении прежней версии SQL Server. Несмотря на то, что Windows Server 2016 допускает последовательное обновление Windows Server 2012 R2 при неизменном оборудовании, большинство пользователей предпочитает выполнять развертывание на новое оборудование или виртуальные машины.

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

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

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

Переход на более поздние версии SQL Server

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

При настройке распределенной группы доступности с целевым объектом миграции SQL Server, версия которого выше версии источника, автозаполнение не поддерживается, поэтому для режима заполнения нужно задать значение MANUAL. Если вы не отключите AUTO-SEEDING, миграция завершится ошибкой 946 "Не удается открыть базу данных DistributionAG версии xxx. Обновите базу данных до последней версии в журнале ошибок. Необходимо установить режим заполнения вручную и вручную выполнить полную резервную копию журнала транзакций исходной базы данных из первичной группы доступности. Затем вручную восстановите его вместе с журналом транзакций в вторичную группу доступности. Чтобы узнать больше, см. инструкции по заполнению вручную для настройки распределенной группы доступности, а также скрипты для резервного копирования и восстановления базы данных из первичной группы доступности во вторичной.

При условии, что вторичная группа доступности (AG2) является целью миграции и имеет более высокую версию, чем первичная группа доступности (AG1), учитывайте следующие ограничения:

  • У вас не будет доступа на чтение к репликам базы данных во вторичной группе доступности, если версия первичная группа доступности более ранняя.
  • В течение этого времени обновления будут продолжать поступать от первичной AG (AG1) к вторичной AG (AG2), но для вторичной AG будет отображаться состояние частичной работоспособности, а для базы данных на вторичных репликах вторичной AG (AG2) будет отображаться состояние синхронизации или выполнения восстановления (даже если для AG выполняется синхронная фиксация).
  • После отработки отказа распределенной группы доступности на более позднюю версию (AG2) для этой версии будет отображаться состояние работоспособности.
  • В течение этого времени вернуться к AG1 будет невозможно, так как это более ранняя версия.
  • Так как версия AG1 более ранняя, обновления из AG2 после отработки отказа на AG2 не будут реплицироваться в AG1.
  • Здесь выберите, если вы хотите удалить исходную (первичную) группу доступности или хотите обновить AG1 и обслуживать распределенную группу доступности.
    • Если вы решили удалить AG1, удалите исходную первичную группу доступности из распределенной группы доступности, и процесс завершится.
    • Если вы решили сохранить распределенную группу доступности, обновите версию SQL Server для AG1, чтобы она соответствовала AG2. После обновления AG1 и распределенная группа доступности становятся работоспособными, реплики возобновляют синхронизацию, и становится возможным восстановление размещения.

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

Одна распределенная группа доступности при необходимости может иметь до 16 вторичных реплик. В связи с этим у нее может быть до 18 доступных для чтения копий, включая две первичные реплики различных групп доступности. Это означает, что сразу несколько узлов могут обращаться к ней практически в режиме реального времени для передачи отчетов в различные приложения.

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

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

Другими словами, первичная реплика может участвовать в разных распределенных группах доступности. На следующем рисунке показаны AG1 и AG2, участвующие в распределенной группе доступности AG1, и AG2 и AG3, участвующие в распределенной группе доступности AG2. Первичная реплика AG2 (или сервер пересылки) является одновременно вторичной репликой группы доступности AG1 и первичной репликой распределенной группы доступности AG2.

Diagram showing scaling out reads with distributed availability groups.

На следующем рисунке AG1 является первичной репликой двух различных распределенных групп доступности: распределенной группы доступности AG1 (состоящей из AG1 и AG2) и распределенной группы доступности AG2 (состоящей из AG1 и AG 3).

Diagram showing another example of scaling out of reads using distributed availability groups.

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

Маршрутизация только для чтения полностью не поддерживается для распределенных групп доступности. В частности

  1. Маршрутизация только для чтения, может быть настроена и будет работать для первичной группы доступности распределенной группы доступности.
  2. Маршрутизацию только для чтения можно настроить, но эта функция не будет работать для вторичной группы доступности распределенной группы доступности. Все запросы, если они используют прослушиватель для подключения к вторичной группе доступности, поступают на первичную реплику вторичной группы доступности. Если это не так, необходимо настроить каждую реплику так, чтобы она принимала все подключения как вторичная реплика и обращалась к ним напрямую. Маршрутизация только для чтения будет работать, если вторичная группа доступности становится первичной после отработки отказа. Это поведение может измениться в обновлении для SQL Server 2016 или в будущей версии SQL Server.

Инициализация вторичных групп доступности

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

  1. Восстановление резервных копий базы данных с ключевым словом WITH NORECOVERY.
  2. Восстановление резервных копий соответствующих журналов транзакций с ключевым словом WITH NORECOVERY (при необходимости).
  3. Создание второй группы доступности без указания имени базы данных и с параметром SEEDING_MODE, имеющим значение AUTOMATIC.
  4. Создание распределенной группы доступности с помощью автоматического заполнения.

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

  • Результат в переменной sys.dm_hadr_automatic_seeding, соответствующей первичной реплике второй группы доступности, будет содержать параметр current_state со значением FAILED и следующей причиной "Превышено время ожидания сообщения о проверке заполнения".

  • Текущий журнал ошибок SQL Server в основном реплика второй группы доступности покажет, что автоматическое заполнение работало и что LSN были синхронизированы.

  • Результат в переменной sys.dm_hadr_automatic_seeding, соответствующей первичной реплике первой группы доступности, будет содержать параметр current_state со значением COMPLETED.

  • Автоматическое заполнение также отличается от поведения распределенных групп доступности. Чтобы автоматическое заполнение началось на второй реплика, необходимо выполнить команду ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE в реплика. Хотя это условие по-прежнему верно для всех вторичных реплика, участвующих в базовой группе доступности, основной реплика второй группы доступности уже имеет правильные разрешения, чтобы разрешить автоматическое заполнение, чтобы начать работу после добавления в распределенную группу доступности.

Мониторинг работоспособности

Распределенная группа доступности — это только конструкция SQL Server, и она не отображается в базовом WSFC. В следующем примере кода показаны два разных WSFCs (CLUSTER_A и CLUSTER_B), каждая из которых содержит собственные группы доступности. Здесь обсуждаются только группы доступности AG1 в CLUSTER_A и AG2 в CLUSTER_B.

PS C:\> Get-ClusterGroup -Cluster CLUSTER_A

Name                            OwnerNode             State
----                            ---------             -----
AG1                             DENNIS                Online
Available Storage               GLEN                  Offline
Cluster Group                   JY                    Online
New_RoR                         DENNIS                Online
Old_RoR                         DENNIS                Online
SeedingAG                       DENNIS                Online

PS C:\> Get-ClusterGroup -Cluster CLUSTER_B

Name                            OwnerNode             State
----                            ---------             -----
AG2                             TOMMY                 Online
Available Storage               JC                    Offline
Cluster Group                   JC                    Online

Все подробные сведения о распределенной группе доступности находятся в SQL Server, в частности в динамических административных представлениях группы доступности. Сейчас в SQL Server Management Studio отображается только первичная реплика для групп доступности. Как показано на следующем рисунке, распределенная группа доступности отображается в папке "Группы доступности" SQL Server Management Studio. На рисунке AG1 показана в качестве первичной реплики для отдельной группы доступности, которая является локальной для этого экземпляра, а не для распределенной группы доступности.

Screenshot from SQL Server Management Studio of the primary replica on the first WSFC of a distributed availability group.

Если щелкнуть распределенную группу доступности правой кнопкой мыши, вы увидите, что доступные действия для нее отсутствуют (см. следующий рисунок), а развернутые папки "Базы данных доступности", "Прослушиватели группы доступности" и "Реплики доступности" пусты. Это можно видеть SQL Server Management Studio 16, но ситуация измениться в будущих версиях SQL Server Management Studio.

Screenshot showing no options available for action.

Как показано на следующем рисунке, вторичные реплики в SQL Server Management Studio не связаны с распределенной группой доступности. Эти имена групп доступности соответствуют ролям, показанным на предыдущем изображении с кластером WSFC CLUSTER_A.

Screenshot from SQL Server Management Studio of a secondary replica.

Динамическое административное представление для перечисления имен всех реплик доступности

Те же принципы применяются при использовании динамических административных представлений. Выполнив следующий запрос, вы увидите все группы доступности (обычные и распределенные) и входящие в них узлы. Этот результат отображается только при отправке запроса к первичной реплике в одном из кластеров WSFC, которые входят в распределенную группу доступности. В динамическом административном представлении sys.availability_groups появился новый столбец с именем is_distributed. Этот столбец содержит значение 1, если группа доступности является распределенной. Чтобы просмотреть этот столбец:

-- shows replicas associated with availability groups
SELECT
   ag.[name] AS [AG Name],
   ag.Is_Distributed,
   ar.replica_server_name AS [Replica Name]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON ag.group_id = ar.group_id;
GO

На следующем рисунке показан пример выходных данных второго кластера WSFC, входящего в распределенную группу доступности. SPAG1 состоит из двух реплик: DENNIS и JY. При этом распределенная группа доступности SPDistAG включает имена двух входящих в нее групп доступности (SPAG1 и SPAG2), а не имена экземпляров как в традиционных группах доступности.

Screenshot showing the example output of the preceding query.

Динамическое административное представление для просмотра состояния работоспособности распределенных групп доступности

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

-- shows sync status of distributed AG
SELECT
   ag.[name] AS [AG Name],
   ag.is_distributed,
   ar.replica_server_name AS [Underlying AG],
   ars.role_desc AS [Role],
   ars.synchronization_health_desc AS [Sync Status]
FROM  sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON  ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON  ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Screenshot showing a distributed availability group status.

Динамическое административное представление для просмотра производительности основной группы

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

-- shows underlying performance of distributed AG
SELECT
   ag.[name] AS [Distributed AG Name],
   ar.replica_server_name AS [Underlying AG],
   dbs.[name] AS [Database],
   ars.role_desc AS [Role],
   drs.synchronization_health_desc AS [Sync Status],
   drs.log_send_queue_size,
   drs.log_send_rate,
   drs.redo_queue_size,
   drs.redo_rate
FROM sys.databases AS dbs
INNER JOIN sys.dm_hadr_database_replica_states AS drs
   ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups AS ag
   ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas AS ar
   ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Screenshot showing performance information for a distributed availability group.

Динамическое административное представление для просмотра счетчиков производительности распределенной группы доступности

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

-- displays OS performance counters related to the distributed ag named 'distributedag'
SELECT * FROM sys.dm_os_performance_counters WHERE instance_name LIKE '%distributed%'

Screenshot of a DMV displaying OS performance counters for DAG.

Примечание.

Фильтр LIKE должен иметь имя распределенной группы доступности. В этом примере имя распределенной группы доступности — "distributedag". Измените модификатор LIKE, чтобы он отражал имя вашей распределенной группы доступности.

Динамическое административное представление для отображения работоспособности обычной и распределенной групп доступности

Указанный ниже запрос отображает подробные сведения о работоспособности обычной и распределенной групп доступности. (Воспроизводится с разрешения Трейси Боггиано (Tracy Boggiano).)

-- displays sync status, send rate, and redo rate of availability groups,
-- including distributed AG
SELECT ag.name AS [AG Name],
    ag.is_distributed,
    ar.replica_server_name AS [AG],
    dbs.name AS [Database],
    ars.role_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.log_send_rate,
    drs.redo_queue_size,
    drs.redo_rate,
    drs.suspend_reason_desc,
    drs.last_sent_time,
    drs.last_received_time,
    drs.last_hardened_time,
    drs.last_redone_time,
    drs.last_commit_time,
    drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
    ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
    ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
    ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO

Screenshot showing the health of an AG and distributed AG.

Динамические административные представления для просмотра метаданных распределенной группы доступности

Указанные ниже запросы отобразят сведения о URL-адресах конечных точек, используемых группами доступности, в том числе распределенной группой. (Воспроизводится с разрешения Дэвида Барбарин (David Barbarin).)

-- shows endpoint url and sync state for ag, and dag
SELECT
   ag.name AS group_name,
   ag.is_distributed,
   ar.replica_server_name AS replica_name,
   ar.endpoint_url,
   ar.availability_mode_desc,
   ar.failover_mode_desc,
   ar.primary_role_allow_connections_desc AS allow_connections_primary,
   ar.secondary_role_allow_connections_desc AS allow_connections_secondary,
   ar.seeding_mode_desc AS seeding_mode
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag
   ON ar.group_id = ag.group_id;
GO

Screenshot of the metadata DMV for distributed AG.

Динамическое административное представление для отображения текущего состояния заполнения

Указанный ниже запрос отображает сведения о текущем состоянии заполнения. Это помогает при устранении ошибок синхронизации между репликами. (Воспроизводится с разрешения Дэвида Барбарин (David Barbarin).)

-- shows current_state of seeding
SELECT ag.name AS aag_name,
    ar.replica_server_name,
    d.name AS database_name,
    has.current_state,
    has.failure_state_desc AS failure_state,
    has.error_code,
    has.performed_seeding,
    has.start_time,
    has.completion_time,
    has.number_of_attempts
FROM sys.dm_hadr_automatic_seeding AS has
INNER JOIN sys.availability_groups AS ag
    ON ag.group_id = has.ag_id
INNER JOIN sys.availability_replicas AS ar
    ON ar.replica_id = has.ag_remote_replica_id
INNER JOIN sys.databases AS d
    ON d.group_database_id = has.ag_db_id;
GO

Screenshot showing the current state of seeding.

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