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

Применимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions) Применимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions)

Распределенные группы доступности — это новая функция SQL Server 2016, схожая с функцией групп доступности AlwaysOn.Distributed availability groups are a new feature introduced in SQL Server 2016, as a variation of the existing Always On availability groups feature. Данная статья разъясняет некоторые аспекты распределенных групп доступности и дополняет существующую документацию по SQL Server.This article clarifies some aspects of distributed availability groups and complements the existing SQL Server documentation.

Примечание

Аббревиатура "DAG" не является официальным сокращением для распределенной группы доступности, поскольку уже используется для обозначения функции группы доступности базы данных Exchange."DAG" is not the official abbreviation for distributed availability group, because the abbreviation is already used for the Exchange Database Availability Group feature. Эта функция Exchange никак не связана с группами доступности SQL Server или распределенными группами доступности.This Exchange feature has no relation to SQL Server availability groups or distributed availability groups.

Сведения о настройке распределенной группы доступности см. в статье Настройка распределенных групп доступности.To configure a distributed availability group, see Configure distributed availability groups.

Что такое распределенные группы доступностиUnderstand distributed availability groups

Распределенная группа доступности — это особый тип группы доступности, который охватывает сразу две отдельные группы доступности.A distributed availability group is a special type of availability group that spans two separate availability groups. Группы доступности, участвующие в распределенной группе доступности, необязательно должны находиться в одном и том же месте.The availability groups that participate in a distributed availability group do not need to be in the same location. Они могут быть физическими, виртуальными или локальными, размещаться в общедоступном облаке или в любом другом месте, которое поддерживает развертывание групп доступности.They can be physical, virtual, on-premises, in the public cloud, or anywhere that supports an availability group deployment. Распределенные группы доступности могут включать группы из разных доменов и даже на разных платформах: например, одна группа доступности может быть размещена в Linux, а другая — в Windows.This includes cross-domain and even cross-platform - such as between an availability group hosted on Linux and one hosted on Windows. Если две группы доступности могут взаимодействовать, их можно включить в распределенную группу доступности.As long as two availability groups can communicate, you can configure a distributed availability group with them.

Ресурсы традиционной группы доступности настраиваются в кластере WSFC.A traditional availability group has resources configured in a WSFC cluster. Для распределенной группы доступности в кластере WSFC ничего настраивать не нужно.A distributed availability group does not configure anything in the WSFC cluster. Все необходимое хранится в SQL Server.Everything about it is maintained within SQL Server. Дополнительные сведения о просмотре данных распределенной группы доступности см. в статье Просмотр сведений о распределенной группе доступности.To learn how to view information for a distributed availability group, see Viewing distributed availability group information.

Для участия в распределенной группе доступности у группы доступности должен иметься прослушиватель.A distributed availability group requires that the underlying availability groups have a listener. Однако вместо имени базового сервера для автономного экземпляра (или, если речь идет об экземпляре отказоустойчивого кластера [FCI] SQL Server, то значения, связанного с ресурсом имени сети), необходимого для традиционной группы доступности, вы указываете прослушиватель, настроенный для распределенной группы доступности с параметром ENDPOINT_URL в процессе ее создания.Rather than provide the underlying server name for a standalone instance (or in the case of a SQL Server failover cluster instance [FCI], the value associated with the network name resource) as you would with a traditional availability group, you specify the configured listener for the distributed availability group with the parameter ENDPOINT_URL when you create it. Несмотря на то, что у каждой группы доступности, входящей в распределенную группу доступности, прослушиватель есть, у самой распределенной группы доступности его нет.Although each underlying availability group of the distributed availability group has a listener, a distributed availability group has no listener.

На следующем рисунке показано высокоуровневое представление распределенной группы доступности, охватывающий две группы доступности (AG 1 и AG2), каждая из которых настроена в собственном кластере WSFC.The following figure shows a high-level view of a distributed availability group that spans two availability groups (AG 1 and AG 2), each configured on its own WSFC cluster. Распределенная группа доступности имеет четыре реплики, по две в каждой группе доступности.The distributed availability group has a total of four replicas, with two in each availability group. Каждая группа доступности может поддерживать не больше максимального числа реплик, поэтому в распределенной группе доступности может быть до 18 реплик.Each availability group can support up to the maximum number of replicas, so a distributed availability can have up to 18 total replicas.

Высокоуровневое представление распределенной группы доступности

Перемещение данных в распределенной группе доступности можно настроить как синхронное или асинхронное.You can configure the data movement in distributed availability groups as synchronous or asynchronous. При этом в распределенных группах доступности данные перемещаются не так, как в традиционных.However, data movement is slightly different within distributed availability groups compared to a traditional availability group. Несмотря на то, что у каждой группы доступности есть первичная реплика, принимать вставки, обновления и удаления может только одна копия баз данных, участвующих в распределенной группе доступности.Although each availability group has a primary replica, there is only one copy of the databases participating in a distributed availability group that can accept inserts, updates, and deletions. Как показано на следующем рисунке, первичной группой доступности является AG1.As shown in the following figure, AG 1 is the primary availability group. Ее первичная реплика отправляет транзакции в обе вторичные реплики AG1 и в первичную реплику AG2.Its primary replica sends transactions to both the secondary replicas of AG 1 and the primary replica of AG 2. Первичная реплика AG2 также называется сервером пересылки.The primary replica of AG 2 is also known as a forwarder. Сервер пересылки — это первичная реплика во вторичной группе доступности в распределенной группе доступности.A forwarder is a primary replica in a secondary availability group in a distributed availability group. Сервер пересылки получает транзакции из первичной реплики в первичной группе доступности и пересылает их во вторичные реплики в собственной группе доступности.The forwarder receives transactions from the primary replica in the primary availability group and forwards them to the secondary replicas in its own availability group. После этого сервер пересылки обновляет вторичные реплики AG2.The forwarder then keeps the secondary replicas of AG 2 updated.

Распределенная группа доступности и перемещение данных в этой группе

Единственный способ сделать так, чтобы первичная реплика AG2 принимала вставки, обновления и удаления, — это вручную выполнить отработку отказа распределенной группы доступности из AG1.The only way to make AG 2's primary replica accept inserts, updates, and deletions is to manually fail over the distributed availability group from AG 1. Поскольку AG 1 содержит доступную для записи копию базы данных, после отработки отказа группа доступности AG2 сможет принимать вставки, обновления и удаления.In the preceding figure, because AG 1 contains the writeable copy of the database, issuing a failover makes AG 2 the availability group that can handle inserts, updates, and deletions. Сведения о том, как выполнить отработку отказа с переходом из одной группы доступности в другую, см. в статье Отработка отказа с переходом на вторичную группу доступности.For information about how to fail over one distributed availability group to another, see Failover to a secondary availability group.

Примечание

Распределенные группы доступности в SQL Server 2016 поддерживают отработку отказа только с переходом из одной группы доступности в другую с использованием параметра FORCE_FAILOVER_ALLOW_DATA_LOSS.Distributed availability groups in SQL Server 2016 support failover only from one availability group to another by using the option FORCE_FAILOVER_ALLOW_DATA_LOSS.

Примечание

При использовании репликации транзакций с распределенными группами доступности нельзя настроить реплику пересылки в качестве издателя.When using transactional replication with distributed availability groups the forwarder replica can't be configured as a publisher.

Требования версии и выпуска SQL Server к распределенным группам доступностиSQL Server version and edition requirements for distributed availability groups

В распределенных группах доступности в SQL Server 2017 или более поздней версии можно смешивать основные версии SQL Server в пределах одной и той же распределенной группы доступности.Distributed availability groups in SQL Server 2017 or later can mix major versions of SQL Server in the same distributed availability group. Группа доступности, содержащая основную реплику для чтения и записи, может иметь ту же версию или ниже, чем у других групп доступности, участвующих в распределенной группе доступности.The AG containing read/write primary can be the same version or lower than the other AGs participating in the distributed AG. Другие группы доступности могут относиться к той же или более поздней версии.The other AGs can be the same version or higher. Этот сценарий предназначен для обновления и миграции.This scenario is targeted to upgrade and migration scenarios. Например, если группа доступности, содержащая первичную реплику чтения и записи, — это SQL Server 2016, но требуется обновление или миграция на SQL Server 2017 или более поздние версии, другие группы доступности, участвующие в распределенной группе доступности, можно настроить с помощью SQL Server 2017.For example, if the AG containing the read/write primary replica is SQL Server 2016, but you want to upgrade/migrate to SQL Server 2017 or later, the other AG participating in the distributed AG can be configured with SQL Server 2017.

Поскольку в SQL Server 2012 или 2014 функция распределенных групп доступности еще не существовала, группы доступности, созданные с помощью этих версий, не могут участвовать в распределенных группах доступности.Because the distributed availability groups feature did not exist in SQL Server 2012 or 2014, availability groups that were created with these versions cannot participate in distributed availability groups.

Примечание

Распределенные группы доступности невозможно настроить с помощью выпуска Standard или сочетания выпусков Standard и Enterprise.Distributed availability groups can not be configured with Standard edition or mix of Standard and Enterprise edition.

Поскольку речь идет о двух отдельных группах доступности, процесс установки пакета обновления или накопительного пакета обновления в реплике, участвующей в распределенной группе доступности, будет выполняться несколько иначе, чем в традиционной группе доступности:Because there are two separate availability groups, the process of installing a service pack or cumulative update on a replica that's participating in a distributed availability group is slightly different from that of a traditional availability group:

  1. Начните с обновления реплик второй группы доступности в распределенной группе доступности.Start by updating the replicas of the second availability group in the distributed availability group.

  2. Установите исправления в реплики первичной группы доступности в распределенной группе доступности.Patch the replicas of the primary availability group in the distributed availability group.

  3. Как и в случае со стандартной группой доступности, выполните отработку отказа с переходом из первичной группы доступности в одну из ее собственных реплик (но не в первичную реплику второй группы доступности) и установите исправления.As with a standard availability group, fail over the primary availability group to one of its own replicas (not to the primary of the second availability group) and patch it. Если нет ни одной реплики, кроме первичной, отработку отказа с переходом во вторую группу доступности необходимо будет выполнить вручную.If there is no replica other than the primary, a manual failover to the second availability group will be necessary.

Примечание

Пока неизвестно, позволят ли дальнейшие версии SQL Server использовать более ранние версии в одной и той же распределенной группе доступности.No announcements have been made as to whether future versions of SQL Server will allow previous versions to participate in the same distributed availability group. Если бы это было возможно, распределенные группы доступности могли бы участвовать в плане обновления версий SQL Server.If that scenario were enabled, it would allow distributed availability groups to be part of a SQL Server version upgrade plan.

Версии Windows Server и распределенные группы доступностиWindows Server versions and distributed availability groups

Распределенная группа доступности охватывает несколько групп доступности, каждая из которых занимает собственный кластер WSFC и работает только в SQL Server.A distributed availability group spans multiple availability groups, each on its own underlying WSFC cluster, and a distributed availability group is a SQL Server-only construct. Это означает, что кластеры WSFC, в которых размещаются отдельные группы доступности, могут иметь различные основные версии Windows Server.This means the WSFC clusters that house the individual availability groups can have different major versions of Windows Server. Как уже говорилось в предыдущем разделе, основные версии SQL Server должны совпадать.The major versions of SQL Server must be the same, as discussed in the previous section. Как на исходном изображении, так и на изображении, представленном ниже, показаны группы AG1 и AG2, участвующие в распределенной группе доступности, но в этом случае кластеры WSFC имеют разные версии Windows Server.Much like the initial figure, the following figure shows AG 1 and AG 2 participating in a distributed availability group, but each of the WSFC clusters is a different version of Windows Server.

Распределенные группы доступности с кластерами WSFC, использующими различные версии Windows Server

Отдельные кластеры WSFC, а также соответствующие группы доступности отвечают традиционным правилам.The individual WSFC clusters and their corresponding availability groups follow traditional rules. Это значит, что они могут быть либо присоединенными к какому-либо домену, либо не присоединенными ни к одному из них (Windows Server 2016 или более поздней версии).That is, they can be joined to a domain or not joined to a domain (Windows Server 2016 or later). При объединении двух разных групп доступности в одну распределенную группу доступности возможны четыре сценария:When two different availability groups are combined in a single distributed availability group, there are four scenarios:

  • Оба кластера WSFC присоединяются к одному и тому же домену.Both WSFC clusters are joined to the same domain.
  • Каждый кластер WSFC присоединен к отдельному домену.Each WSFC cluster is joined to a different domain.
  • Один кластер WSFC присоединен к какому-либо домену, а другой — нет.One WSFC cluster is joined to a domain, and one WSFC cluster is not joined to a domain.
  • Ни один кластер WSFC не присоединен ни к одному домену.Neither WSFC cluster is joined to a domain.

Если оба кластера WSFC присоединены к одному и тому же домену (не к доверенным доменам), при создании группы доступности никакие дополнительные действия выполнять не нужно.When both WSFC clusters are joined to the same domain (not trusted domains), you don't need to do anything special when you create the distributed availability group. Для работы распределенной группы доступности, в которую входят группы доступности и кластеры WSFC, не присоединенные к одному и тому же домену, используйте сертификаты — во многом это напоминает создание группы доступности для группы доступности, не зависящей от домена.For availability groups and WSFC clusters that are not joined to the same domain, use certificates to make the distributed availability group work, much in the way that you might create an availability group for a domain-independent availability group. Чтобы настроить сертификаты для распределенной группы доступности, выполните шаги 3–13 в разделе Создание группы доступности, не зависящей от домена.To see how to configure certificates for a distributed availability group, follow steps 3-13 under Create a domain-independent availability group.

При использовании распределенной группы доступности первичные реплики в каждой соответствующей группе доступности должны иметь сертификаты друг друга.With a distributed availability group, the primary replicas in each underlying availability group must have each other's certificates. Если у вас уже есть конечные точки без сертификатов, перенастройте их с помощью параметра ALTER ENDPOINT, отобразив использование сертификатов.If you already have endpoints that are not using certificates, reconfigure those endpoints by using ALTER ENDPOINT to reflect the use of certificates.

Варианты применения распределенных групп доступностиDistributed availability group usage scenarios

Ниже представлены три основных варианта применения распределенной группы доступности.Here are the three main usage scenarios for a distributed availability group:

Сценарии аварийного восстановления и конфигураций с несколькими сайтамиDisaster recovery and multi-site scenarios

В традиционной группе доступности все серверы должны находиться в одном и том же кластере WSFC, из-за чего объединение нескольких центров обработки данных может быть затруднено.A traditional availability group requires that all servers be part of the same WSFC cluster, which can make spanning multiple data centers challenging. На следующем рисунке показана архитектура традиционной группы доступности с несколькими сайтами, включая поток данных.The following figure shows what a traditional multi-site availability group architecture looks like, including the data flow. Здесь есть только одна первичная реплика, которая отправляет транзакции во все вторичные реплики.There is one primary replica that sends transactions to all secondary replicas. В некотором отношении такая настройка является менее гибкой, чем распределенная группа доступности.This configuration is less in some ways than a distributed availability group. Например, она требует внедрения таких компонентов, как Active Directory (если применимо) и свидетель кворума в кластере WSFC.For example, you must implement such things as Active Directory (if applicable) and the witness for a quorum in the WSFC cluster. Кроме того, необходимо учитывать и другие аспекты кластера WSFC, например изменение голосов узлов.You might also need to take into account other aspects of a WSFC cluster, such as altering node votes.

Традиционная группа доступности с несколькими сайтами

Распределенные группы доступности представляют собой более гибкий вариант для развертывания групп доступности, охватывающих сразу несколько центров обработки данных.Distributed availability groups offer a more flexible deployment scenario for availability groups that span multiple data centers. Распределенные группы доступности можно использовать даже там, где раньше применялись такие функции, как доставка журналов, для таких сценариев, как аварийное восстановление.You can even use distributed availability groups where features such as log shipping were used in the past for scenarios such as disaster recovery. Но в отличие от доставки журналов для распределенных групп доступности не предусмотрено отложенное применение транзакций.However, unlike log shipping, distributed availability groups cannot have delayed application of transactions. Это означает, что группы доступности или распределенные группы доступности ничем не помогут в случае ошибки, связанной с человеческим фактором и ошибочным обновлением или удалением данных.This means that availability groups or distributed availability groups cannot help in the event of human error in which data is incorrectly updated or deleted.

Распределенные группы доступности связаны слабо — в данном случае это означает, что для них необязательно наличие только одного кластера WSFC или обслуживания в SQL Server.Distributed availability groups are loosely coupled, which in this case means that they don't require a single WSFC cluster and they're maintained by SQL Server. Поскольку кластеры WSFC обслуживаются отдельно, а синхронизация между двумя группами доступности в основном выполняется асинхронно, настроить аварийное восстановление на другом сайте гораздо проще.Because the WSFC clusters are maintained individually and the synchronization is primarily asynchronous between the two availability groups, it's easier to configure disaster recovery at another site. Первичные реплики в каждой группе доступности синхронизируют свои собственные вторичные реплики.The primary replicas in each availability group synchronize their own secondary replicas.

  • Для распределенной группы доступности поддерживается только отработка отказа вручную.Only manual failover is supported for a distributed availability group. В случае аварийного восстановления и необходимости переключения центров обработки данных настраивать автоматическую отработку отказа не следует (за редкими исключениями).In a disaster recovery situation where you are switching data centers, you should not configure automatic failover (with rare exceptions).
  • Скорее всего, вам не придется настраивать некоторые традиционные элементы или параметры для кластеров WSFC конфигураций с несколькими сайтами и подсетей, такие как CrossSubnetThreshold, но нужно будет проверить задержку сети на другом уровне транспортировки данных.You most likely will not need to set some of the traditional items or parameters for multi-site or subnet WSFC clusters, such as CrossSubnetThreshold, but you still need to see about network latency at a different layer for the data transport. Разница в том, что каждый кластер WSFC обеспечивает собственную доступность, а не является крупной сущностью, единой для четырех узлов.The difference is that each WSFC cluster maintains its own availability; the cluster isn't one big entity of four nodes. У вас есть два отдельных кластера WSFC, каждый из которых имеет по два узла, как показано на предыдущем рисунке.You have two separate two-node WSFC clusters as shown in the previous figure.
  • Мы рекомендуем асинхронное перемещение данных, поскольку этот вариант подходит для аварийного восстановления.We recommend asynchronous data movement, because this approach would be for disaster-recovery purposes.
  • При настройке синхронного перемещения данных между первичной и по крайней мере одной вторичной репликой второй группы доступности и синхронного перемещения данных в распределенной группе доступности распределенная группа доступности будет ждать, пока все синхронные копии подтвердят получение данных.If you configure synchronous data movement between the primary replica and at least one secondary replica of the second availability group, and you configure synchronous movement on the distributed availability group, a distributed availability group will wait until all synchronous copies acknowledge that they have the data.

Миграция с использованием распределенной группы доступностиMigrate by using a distributed availability group

Поскольку распределенные группы доступности поддерживают две совершенно различные конфигурации групп доступности, они упрощают не только аварийное восстановление и сценарии с несколькими узлами, но и сценарии миграции.Because distributed availability groups support two completely different availability group configurations, they enable not only easier disaster-recovery and multi-site scenarios, but also migration scenarios. Происходит ли миграция на новое оборудование или на виртуальные машины (локально или с помощью IaaS в общедоступном облаке), настройка распределенной группы доступности обеспечит ее выполнение даже там, где раньше могли потребоваться копия, резервная копия и восстановление или доставка журналов.Whether you are migrating to new hardware or virtual machines (on-premises or IaaS in the public cloud), configuring a distributed availability group allows a migration to occur where, in the past, you might have used backup, copy, and restore, or log shipping.

Возможность миграции особенно полезна в случаях изменения или обновления базовой операционной системы при сохранении прежней версии SQL Server.The ability to migrate is especially useful in scenarios where you're changing or upgrading the underlying OS while you keep the same SQL Server version. Несмотря на то, что Windows Server 2016 допускает последовательное обновление Windows Server 2012 R2 при неизменном оборудовании, большинство пользователей предпочитает выполнять развертывание на новое оборудование или виртуальные машины.Although Windows Server 2016 does allow a rolling upgrade from Windows Server 2012 R2 on the same hardware, most users choose to deploy new hardware or virtual machines.

Для завершения перехода на новую конфигурацию в конце процедуры его выполнения остановите весь трафик данных в исходную группу доступности и измените распределенную группу доступности, настроив для нее синхронное перемещение данных.To complete the migration to the new configuration, at the end of the process, stop all data traffic to the original availability group, and change the distributed availability group to synchronous data movement. Это действие гарантирует, что первичная реплика второй группы доступности будет полностью синхронизирована, а данные не пропадут.This action ensures that the primary replica of the second availability group is fully synchronized, so there would be no data loss. После проверки синхронизации проведите отработку отказа распределенной группы доступности во вторичную группу доступности.After you've verified the synchronization, fail over the distributed availability group to the secondary availability group. Дополнительные сведения см. в разделе Отработка отказа во вторичную группу доступности.For more information, see Fail over to a secondary availability group.

Поскольку после миграции вторая группа доступности становится новой первичной группой доступности, возможно, вам придется выполнить одно из следующих действий:Post-migration, where the second availability group is now the new primary availability group, you might need to do either of the following:

  • Переименовать прослушиватель во вторичной группе доступности (и, возможно, удалить или переименовать старый прослушиватель в исходной первичной группе доступности) или создать его заново, используя прослушиватель из исходной первичной группы доступности, чтобы приложения и пользователи имели доступ к новой конфигурации.Rename the listener on the secondary availability group (and possibly delete or rename the old one on the original primary availability group), or re-create it with the listener from the original primary availability group, so that applications and users can access the new configuration.
  • Если переименование или повторное создание невозможно, направьте приложения и пользователей на прослушиватель во второй группе доступности.If a rename or re-creation is not possible, point applications and users to the listener on the second availability group.

Горизонтальное увеличение масштаба доступных для чтения реплик с использованием распределенных групп доступностиScale out readable replicas with distributed availability groups

Одна распределенная группа доступности при необходимости может иметь до 16 вторичных реплик.A single distributed availability group can have up to 16 secondary replicas, as needed. В связи с этим у нее может быть до 18 доступных для чтения копий, включая две первичные реплики различных групп доступности.So it can have up 18 copies for reading, including the two primary replicas of the different availability groups. Это означает, что сразу несколько узлов могут обращаться к ней практически в режиме реального времени для передачи отчетов в различные приложения.This approach means that more than one site can have near-real-time access for reporting to various applications.

Распределенные группы доступности позволяют горизонтально увеличить масштаб для доступной для чтения фермы гораздо сильнее, чем при использовании единственной группы доступности.Distributed availability groups can help you scale out a read-only farm more than you can with just a single availability group. Распределенная группа доступности может выполнять горизонтальное увеличение масштаба для доступных для чтения реплик двумя способами:A distributed availability group can scale out readable replicas in two ways:

  • Используя первичную реплику второй группы доступности в распределенной группе доступности, можно создать другую распределенную группу доступности, даже если база данных не находится в режиме RECOVERY.You can use the primary replica of the second availability group in a distributed availability group to create another distributed availability group, even though the database is not in RECOVERY.
  • Используя первичную реплику первой группы доступности, можно создать другую распределенную группу доступности.You can also use the primary replica of the first availability group to create another distributed availability group.

Другими словами, первичная реплика может участвовать в двух различных распределенных группах доступности.In other words, a primary replica can participate in two different distributed availability groups. На следующем рисунке показаны AG1 и AG2, участвующие в распределенной группе доступности AG1, и AG2 и AG3, участвующие в распределенной группе доступности AG2.The following figure shows AG 1 and AG 2 both participating in Distributed AG 1, while AG 2 and AG 3 are participating in Distributed AG 2. Первичная реплика AG2 (или сервер пересылки) является одновременно вторичной репликой группы доступности AG1 и первичной репликой распределенной группы доступности AG2.The primary replica (or forwarder) of AG 2 is both a secondary replica for Distributed AG 1 and a primary replica of Distributed AG 2.

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

На следующем рисунке AG1 является первичной репликой двух различных распределенных групп доступности: распределенной группы доступности AG1 (состоящей из AG1 и AG2) и распределенной группы доступности AG2 (состоящей из AG1 и AG 3).The following figure shows AG 1 as the primary replica for two different distributed availability groups: Distributed AG 1 (composed of AG 1 and AG2) and Distributed AG 2 (composed of AG 1 and AG 3).

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

В каждом из приведенных выше примеров может быть до 27 реплик, распределенных между тремя группами доступности, и любая из них может использоваться для выполнения запросов на чтение.In both preceding examples, there can be up to 27 total replicas across the three availability groups, all of which can be used for read-only queries.

Маршрутизация только для чтения нестабильно работает с распределенными группами доступности.Read-only routing does not completely work with Distributed Availability Groups. В частностиMore specifically,

  1. Маршрутизация только для чтения, может быть настроена и будет работать для первичной группы доступности распределенной группы доступности.Read-Only Routing can be configured and will work for the primary availability group of the distributed availability group.
  2. Маршрутизация только для чтения, может быть настроена, но не будет работать для вторичной группы доступности распределенной группы доступности.Read-Only Routing can be configured, but will not work for the secondary availability group of the distributed availability group. Все запросы, если они используют прослушиватель для подключения к вторичной группе доступности, поступают на первичную реплику вторичной группы доступности.All queries, if they use the listener to connect to the secondary availability group, go to the primary replica of the secondary availability group. Если это не так, необходимо настроить каждую реплику так, чтобы она принимала все подключения как вторичная реплика и обращалась к ним напрямую.Otherwise, you need to configure each replica to allow all connections as a secondary replica and access them directly. Маршрутизация только для чтения будет работать, если вторичная группа доступности становится первичной после отработки отказа.However, read-only routing will work if the secondary availability group becomes primary after a failover. Это поведение может измениться в обновлении для SQL Server 2016 или в будущей версии SQL Server.This behavior might be changed in an update to SQL Server 2016 or in a future version of SQL Server.

Инициализация вторичных групп доступности в распределенной группе доступностиInitialize secondary availability groups in a distributed availability group

Изначально в распределенных группах доступности основным методом инициализации первичной реплики во второй группе доступности являлось автоматическое заполнение.Distributed availability groups were designed with automatic seeding to be the main method used to initialize the primary replica on the second availability group. Полное восстановление базы данных в первичной реплике второй группы доступности возможно при выполнении следующих действий:A full database restore on the primary replica of the second availability group is possible if you do the following:

  1. Восстановление резервных копий базы данных с ключевым словом WITH NORECOVERY.Restore the database backup WITH NORECOVERY.
  2. Восстановление резервных копий соответствующих журналов транзакций с ключевым словом WITH NORECOVERY (при необходимости).If necessary, restore the proper transaction log backups WITH NORECOVERY.
  3. Создание второй группы доступности без указания имени базы данных и с параметром SEEDING_MODE, имеющим значение AUTOMATIC.Create the second availability group without specifying a database name and with SEEDING_MODE set to AUTOMATIC.
  4. Создание распределенной группы доступности с помощью автоматического заполнения.Create the distributed availability group by using automatic seeding.

При добавлении первичной реплики второй группы доступности в распределенную группу доступности реплика проверяется по первичным базам данных первой группы доступности, а заполнение отслеживает базу данных до источника.When you add the second availability group's primary replica to the distributed availability group, the replica is checked against the first availability group's primary databases, and seeding catches the database up to the source. При этом необходимо учитывать несколько моментов:There are a few caveats:

  • Результат в переменной sys.dm_hadr_automatic_seeding, соответствующей первичной реплике второй группы доступности, будет содержать параметр current_state со значением FAILED и следующей причиной "Превышено время ожидания сообщения о проверке заполнения".The output shown in sys.dm_hadr_automatic_seeding on the primary replica of the second availability group will display a current_state of FAILED with the reason "Seeding Check Message Timeout."

  • В текущем журнале SQL Server в первичной реплике второй группы доступности будет указано, что заполнение произошло, а номера LSN синхронизированы.The current SQL Server log on the primary replica of the second availability group will show that seeding worked and that the LSNs were synchronized.

  • Результат в переменной sys.dm_hadr_automatic_seeding, соответствующей первичной реплике первой группы доступности, будет содержать параметр current_state со значением COMPLETED.The output shown in sys.dm_hadr_automatic_seeding on the primary replica of the first availability group will show a current_state of COMPLETED.

  • Заполнение может происходить в распределенных группах доступности по-разному.Seeding also has different behavior with distributed availability groups. Чтобы заполнение начиналось во второй реплике, необходимо выполнить в реплике команду ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE.For seeding to begin on the second replica, you must issue the command ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE command on the replica. Несмотря на то, что это условие относится к любой вторичной реплике, участвующей в базовой группе доступности, первичная реплика второй группы доступности уже имеет разрешения, необходимые для того, чтобы заполнение начиналось сразу после добавления в распределенную группу доступности.Although this condition is still true of any secondary replica that participates in the underlying availability group, the primary replica of the second availability group already has the right permissions to allow seeding to begin after it is added to the distributed availability group.

Мониторинг работоспособности распределенной группы доступностиMonitor distributed availability group health

Распределенная группа доступности является конструкцией исключительно SQL Server, и она не будет отображаться в применяемом кластере WSFC.A distributed availability group is a SQL Server-only construct, and it is not seen in the underlying WSFC cluster. На следующем рисунке показаны два разных кластера WSFC (CLUSTER_A и CLUSTER_B), каждый из которых имеет собственные группы доступности.The following figure shows two different WSFC clusters (CLUSTER_A and CLUSTER_B), each with its own availability groups. Здесь обсуждаются только группы доступности AG1 в CLUSTER_A и AG2 в CLUSTER_B.Only AG1 in CLUSTER_A and AG2 in CLUSTER_B are discussed here.

Два кластера WSFC с несколькими группами доступности при использовании команды PowerShell Get-ClusterGroupTwo WSFC clusters with multiple availability groups through PowerShell Get-ClusterGroup command

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, в частности в динамических административных представлениях группы доступности.All detailed information about a distributed availability group is in SQL Server, specifically in the availability-group dynamic management views. Сейчас в SQL Server Management Studio отображается только первичная реплика для групп доступности.Currently, the only information shown in SQL Server Management Studio for a distributed availability group is on the primary replica for the availability groups. Как показано на следующем рисунке, распределенная группа доступности отображается в папке "Группы доступности" SQL Server Management Studio.As shown in the following figure, under the Availability Groups folder, SQL Server Management Studio shows that there is a distributed availability group. На рисунке AG1 показана в качестве первичной реплики для отдельной группы доступности, которая является локальной для этого экземпляра, а не для распределенной группы доступности.The figure shows AG1 as a primary replica for an individual availability group that's local to that instance, not for a distributed availability group.

Просмотр первичной реплики в первом кластере WSFC распределенной группы доступности в SQL Server Management Studio

Если щелкнуть распределенную группу доступности правой кнопкой мыши, вы увидите, что доступные действия для нее отсутствуют (см. следующий рисунок), а развернутые папки "Базы данных доступности", "Прослушиватели группы доступности" и "Реплики доступности" пусты.However, if you right-click the distributed availability group, no options are available (see the following figure), and the expanded Availability Databases, Availability Group Listeners, and Availability Replicas folders are all empty. Это можно видеть SQL Server Management Studio 16, но ситуация измениться в будущих версиях SQL Server Management Studio.SQL Server Management Studio 16 displays this result, but it might change in a future version of SQL Server Management Studio.

Доступные действия отсутствуют

Как показано на следующем рисунке, вторичные реплики в SQL Server Management Studio не связаны с распределенной группой доступности.As shown in the following figure, secondary replicas show nothing in SQL Server Management Studio related to the distributed availability group. Эти имена групп доступности соответствуют ролям, показанным на предыдущем изображении с кластером WSFC CLUSTER_A.These availability group names map to the roles shown in the previous CLUSTER_A WSFC cluster image.

Просмотр вторичной реплики в SQL Server Management Studio

Динамическое административное представление для перечисления имен всех реплик доступностиDMV to list all availability replica names

Те же принципы применяются при использовании динамических административных представлений.The same concepts hold true when you use the dynamic management views. Выполнив следующий запрос, вы увидите все группы доступности (обычные и распределенные) и входящие в них узлы.By using the following query, you can see all the availability groups (regular and distributed) and the nodes participating in them. Этот результат отображается только при отправке запроса к первичной реплике в одном из кластеров WSFC, которые входят в распределенную группу доступности.This result is displayed only if you query the primary replica in one of the WSFC clusters that are participating in the distributed availability group. В динамическом административном представлении sys.availability_groups появился новый столбец с именем is_distributed. Этот столбец содержит значение 1, если группа доступности является распределенной.There is a new column in the dynamic management view sys.availability_groups named is_distributed, which is 1 when the availability group is a distributed availability group. Чтобы просмотреть этот столбец:To see this column:

-- 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, входящего в распределенную группу доступности.An example of output from the second WSFC cluster that's participating in a distributed availability group is shown in the following figure. SPAG1 состоит из двух реплик: DENNIS и JY.SPAG1 is composed of two replicas: DENNIS and JY. При этом распределенная группа доступности SPDistAG включает имена двух входящих в нее групп доступности (SPAG1 и SPAG2), а не имена экземпляров как в традиционных группах доступности.However, the distributed availability group named SPDistAG has the names of the two participating availability groups (SPAG1 and SPAG2) rather than the names of the instances, as with a traditional availability group.

Пример выходных данных для предыдущего запроса

Динамическое административное представление для просмотра работоспособности распределенных групп доступностиDMV to list Distributed AG health

Любое состояние, отображаемое на панели мониторинга и в других областях SQL Server Management Studio, относится только к локальной синхронизации в этой группе доступности.In SQL Server Management Studio, any status shown on the Dashboard and other areas are for local synchronization only within that availability group. Для отображения сведений о работоспособности распределенной группы доступности отправьте запрос в динамических административных представлениях.To display the health of a distributed availability group, query the dynamic management views. В следующем примере предыдущий запрос расширяется и уточняется.The following example query extends and refines the previous query:

-- 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

Состояние распределенной группы доступности

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

Для дальнейшего расширения предыдущего запроса также можно просмотреть производительность запроса, указав sys.dm_hadr_database_replicas_states в динамических административных представлениях.To further extend the previous query, you can also see the underlying performance via the dynamic management views by adding in sys.dm_hadr_database_replicas_states. Сейчас в динамическом административном представлении хранятся только сведения о вторичной группе доступности.The dynamic management view currently stores information about the second availability group only. При выполнении следующего примера запроса в первичной группе доступности будет получен следующий результат.The following example query, run on the primary availability group, produces the sample output shown below:

-- 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

Сведения о производительности для распределенной группы доступности

Динамическое административное представление для просмотра счетчиков производительности распределенной группы доступностиDMV to view performance counters for distributed AG

Указанный ниже запрос отображает счетчики производительности, связанные с конкретной распределенной группой доступности.The below query displays performance counters specifically associated with the 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%'

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

Примечание

Фильтр LIKE должен иметь имя распределенной группы доступности.The LIKE filter should have the name of the distributed availability group. В этом примере имя распределенной группы доступности — "distributedag".In this example, the name of the distributed availability group is 'distributedag'. Измените модификатор LIKE, чтобы он отражал имя вашей распределенной группы доступности.Change the LIKE modifier to reflect the name of your distributed availability group.

Динамическое административное представление для отображения работоспособности обычной и распределенной групп доступностиDMV to display health of both AG and Distributed AG

Указанный ниже запрос отображает подробные сведения о работоспособности обычной и распределенной групп доступности.The below query displays a wealth of information about the health of both the availability group, and the distributed availability group. Выражаем благодарность Трейси Боггиано (Tracy Boggiano)!Thanks 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

Работоспособность обычной и распределенной групп доступности

Динамические административные представления для просмотра метаданных распределенной группы доступностиDMVs to view metadata of distributed AG

Указанные ниже запросы отобразят сведения о URL-адресах конечных точек, используемых группами доступности, в том числе распределенной группой.The below queries will display information about endpoint URLs used by the availability groups, including the distributed availability group. Выражаем благодарность Дэвиду Барбарину (David Barbarin)!Thanks 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

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

Динамическое административное представление для отображения текущего состояния заполненияDMV to show current state of seeding

Указанный ниже запрос отображает сведения о текущем состоянии заполнения.The below query displays information about the current state of seeding. Это помогает при устранении ошибок синхронизации между репликами.This is useful for troubleshooting synchronization errors between replicas. Еще раз благодарим Дэвида Барбарина (David Barbarin)!Thanks again 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
JOIN sys.availability_groups AS ag
   ON ag.group_id = has.ag_id
JOIN sys.availability_replicas AS ar
   ON ar.replica_id = has.ag_remote_replica_id
JOIN sys.databases AS d
   ON d.group_database_id = has.ag_db_id
GO

Текущее состояние заполнения

Дальнейшие действияNext steps