Настройка прослушивателя для группы доступности always on

Масштабируемость и производительность реляционных СУБД

1 Размер данных выполняющейся в памяти OLTP и кэша сегмента Columnstore ограничены объемом памяти, указанным в выпуске в разделе . Степень параллелизма (DOP) для операций ограничена 2 для выпуска SQL Server Standard и 1 для выпусков SQL Server Web и Express. Это относится к индексам columnstore, созданным на основе таблиц на диске и оптимизированных для памяти таблиц.

2 Передача агрегата, передача предиката строки и оптимизация SIMD — улучшения масштабируемости в выпуске SQL Server Enterprise Edition. Дополнительные сведения см. в статье Новые возможности индексов columnstore.

3 Эта функция не включена в вариант установки LocalDB.

Требования версии и выпуска SQL Server к распределенным группам доступности

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

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

Примечание

Распределенные группы доступности невозможно настроить с помощью выпуска Standard или сочетания выпусков Standard и Enterprise.

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

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

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

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

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

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

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

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

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

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

Когда командлет перезапускает службу SQL Server?

В запущенном экземпляре сервера использование командлетов Enable-SqlAlwaysOn или Disable-SqlAlwaysOn для смены текущей настройки функции AlwaysOn может стать причиной перезапуска службы SQL Server. Алгоритм перезапуска зависит от следующих условий:

Network Access

Каждый экземпляр сервера, на котором размещается реплика доступности, должен иметь доступ к порту каждого другого экземпляра сервера по протоколу TCP

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

• Для проверки подключения используйте команду Telnet. Вот примеры команд, которые можно использовать:

• If the Endpoint is listening and connection is successful, then you will see a blank screen. If not, you will receive a connection error from Telnet

• If Telnet connection to the IP address works but to the ServerName it does not, there is likely a DNS or name resolution issue

• If connection works by ServerName and not by IP address, then there could be more than one endpoint defined on that server (another SQL instance perhaps) that is listening on that port. Though the status of the endpoint on the instance in question shows «STARTED» another instance may actually have the port binding and prevent the correct instance from listening and establishing TCP connections.

• If Telnet fails to connect, look for Firewall and/or Anti-virus software that may be blocking the endpoint port in question. Check the firewall setting to see if it allows the endpoint port communication between the server instances that host primary replica and the secondary replica (port 5022 by default).
  Run the following PowerShell script to examine for disabled inbound traffic rules

• If Telnet fails to connect, look for Firewall and/or antivirus software that may be blocking the endpoint port in question. If you are running SQL Server on Azure VM, additionally you would need to . Check the firewall (and NSG, for Azure VM) setting to see if it allows the endpoint port communication between the server instances that host primary replica and the secondary replica (port 5022 by default)

• Capture a NETSTAT -a output and verify the status is a LISTENING or ESTABLISHED on the IP:Port for the endpoint specified

Процесс синхронизации данных

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

Предварительные требования

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

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

Примечание

В Linux группу доступности необходимо создать перед тем, как добавить ее в качестве кластерного ресурса, управляемого кластером. В этом документе приводится пример создания группы доступности. Инструкции по созданию кластера и добавлению группы доступности в качестве кластерного ресурса для конкретных сред см. по ссылкам в разделе «Дальнейшие действия».

1. Обновление имени компьютера для каждого узла.

   Каждое имя SQL Server должно отвечать следующим требованиям:

   • 15 символов или меньше;
   • уникальность в пределах сети.

   Чтобы указать имя компьютера, измените файл . Следующий сценарий позволяет изменить с помощью :

2. Настройка файла hosts.

   Примечание

   Если имена узлов зарегистрированы с их IP-адресами на DNS-сервере, указанные ниже действия выполнять не нужно. Убедитесь, что все узлы, которые требуется включить в конфигурацию группы доступности, могут взаимодействовать друг с другом. (Команда проверки связи с узлом должна возвращать ответ с соответствующим IP-адресом.) Кроме того, проверьте, не содержит ли файл /etc/hosts запись, которая сопоставляет IP-адрес localhost 127.0.0.1 с именем узла.

   Файл hosts на каждом сервере содержит IP-адреса и имена всех серверов, которые будут участвовать в группе доступности.

   Следующая команда возвращает IP-адрес текущего сервера:

   Обновите . Следующий сценарий позволяет изменить с помощью :

   В следующем примере показан файл на узле node1 с дополнениями для узлов node1, node2 и node3. В этом документе node1 относится к серверу, на котором размещается первичная реплика, а node2 и node3 относятся к серверам, на которых размещаются вторичные реплики.

   

   

   

   

   

   

   

   

   

   

Установка SQL Server

Установите SQL Server. Инструкции по установке SQL Server для различных сред см. по указанным ниже ссылкам:

• Red Hat Enterprise Linux
• SUSE Linux Enterprise Server
• Ubuntu

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

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

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

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

Настройка голосов кворума

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

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

Изменение режима доступности и режима отработки отказа

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

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

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

Создание моментального снимка базы данных
Создание моментального снимка базы данных (Transact-SQL)
Возобновление базы данных доступности
Возобновление базы данных доступности (SQL Server)

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

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

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

пункт «Риск использования принудительной отработки отказа» в разделе «Принудительный переход на другой ресурс вручную (с возможной потерей данных)» статьи Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).
Создание резервной копии журнала
Создание резервной копии журнала транзакций (SQL Server)

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

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

В этом разделе.

Контрольный список. Требования (базы данных доступности)

Для добавления в группу доступности база данных должна соответствовать следующим требованиям.

Примечание

Группы доступности AlwaysOn работает с любым поддерживаемым уровнем совместимости базы данных.

Ограничения (базы данных доступности)

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

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

  • RESTORE WITH MOVE: для создания базы данных-получателя файлы базы данных должны иметь атрибут RESTORED WITH MOVE в каждом экземпляре SQL Server, в котором размещена вторичная реплика.

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

    Примечание

    Дополнительные сведения об отсутствии отклика на неудачную операцию добавления файла см. в разделе Устранение неполадок с операцией добавления файлов, давшей сбой (группы доступности AlwaysOn).

    

    

    

    

    

    

    

    

    

    

• Нельзя удалить базу данных, которая принадлежит какой-либо группе доступности.

Дальнейшие действия для баз данных, защищаемых прозрачным шифрованием

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

Связанные задачи (базы данных доступности)

Типы отработки отказа

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. далее в подразделе Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).

Рекомендации для компьютеров, на которых размещены реплики доступности (ОС Windows)

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

• Выделенные сетевые адаптеры. Для оптимальной производительности следует использовать для Группы доступности AlwaysOn отдельный сетевой адаптер (сетевую карту).

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

Разрешения (ОС Windows)

Для администрирования кластера WSFC пользователь должен быть системным администратором на каждом узле кластера.

Дополнительные сведения об учетной записи для администрирования кластера см. в Приложении A. Требования к отказоустойчивому кластеру.

Связанные задачи (ОС Windows)

Изменение параметра HostRecordTTL (с помощью Windows PowerShell)

1. Откройте окно Powershell с помощью варианта Запуск от имени администратора.

2. Импортируйте модуль FailoverClusters.

3. С помощью командлета Get-ClusterResource найдите ресурс сетевого имени, а затем с помощью командлета Set-ClusterParameter задайте значение HostRecordTTL следующим образом:

   Get-ClusterResource » <NetworkResourceName> » | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   В следующем примере для PowerShell задается значение HostRecordTTL в 300 секунд для сетевого ресурса сетевого имени .

   Совет

   Каждый раз при открытии нового окна PowerShell потребуется импортировать модуль FailoverClusters .

См. также (PowerShell)

• Кластеризация и высокая доступность (блог группы отказоустойчивой кластеризации и балансировки сетевой нагрузки)