Группы доступности для SQL Server на Linux

Область применения: SQL Server — Linux

В этой статье описываются характеристики групп доступности (AG) в установках SQL Server на основе Linux. Здесь рассматриваются также различия между группами доступности на основе отказоустойчивых кластеров Linux и Windows Server (WSFC). Общие сведения о группе доступности AlwaysOn см. в разделе "Основные сведения о группах доступности", так как они работают в Windows и Linux, за исключением WSFC.

С точки зрения высокого уровня группы доступности в SQL Server на Linux совпадают с реализацией на основе WSFC. Это означает, что все ограничения и функции одинаковы, за некоторыми исключениями. Ниже приведены основные отличия.

• Координатор распределенных транзакций Майкрософт (DTC) поддерживается в Linux, начиная с SQL Server 2017 с накопительным пакетом обновления 16 (CU 16). Однако DTC пока не поддерживается в группах доступности в Linux. Если приложения требуют использования распределенных транзакций и требуют группы доступности, разверните SQL Server в Windows.
• В развертываниях на основе Linux, которым требуется высокий уровень доступности, для кластеризации вместо WSFC используется Pacemaker.
• В отличие от большинства конфигураций групп доступности в Windows, за исключением сценария работы с кластером рабочей группы, для Pacemaker не требуется домен Active Directory Services (AD DS).
• Переход с одного узла на другой в Linux и Windows различается.
• Некоторые параметры, такие как required_synchronized_secondaries_to_commit, могут быть изменены только через Pacemaker в Linux, в то время как установка на основе WSFC использует Transact-SQL.

Число реплик и узлов кластера

Группа доступности в выпуске SQL Server Standard может иметь две общие реплики: одну первичную и вторичную, которая может использоваться только для целей доступности. Его нельзя использовать для других компонентов, таких как доступные для чтения запросы. Группа доступности в выпуске SQL Server Enterprise может иметь до девяти общих реплик: один первичный и до восьми секундных реплик, из которых может быть синхронно (в том числе основной). При использовании базового кластера общее количество узлов может быть не более 16, если используется Corosync. Группа доступности может охватывать не более девяти узлов с выпуском SQL Server Enterprise и двумя выпусками SQL Server Standard.

Конфигурация с двумя репликами, для которой требуется возможность автоматического перехода на другую реплику, требует использования реплики, предназначенной только для конфигурации, как описано в разделе Реплика и кворум только для конфигурации. В SQL Server 2017 (14.x) накопительного обновления 1 (CU 1) появились только реплики конфигурации, поэтому для этой конфигурации должна быть минимальная версия.

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

Доступные для чтения вторичные реплики поддерживаются только в выпуске SQL Server Enterprise.

Тип кластера и режим отработки отказа

Новые возможности SQL Server 2017 (14.x) — это введение в тип кластера для групп доступности. Для Linux существует два допустимых значения: External и None. Тип кластера External означает, что Pacemaker используется под группой доступности. Использование внешнего для типа кластера требует, чтобы режим отработки отказа был задан как внешний, так и (также новый в SQL Server 2017 (14.x)). Автоматическая отработка отказа поддерживается, но, в отличие от WSFC, при использовании Pacemaker режим отработки отказа устанавливается как External, а не автоматический. В отличие от WSFC, часть группы доступности в Pacemaker создается после настройки группы доступности.

Тип кластера None означает, что не требуется использовать группу доступности, Pacemaker. Даже на серверах с настроенными Pacemaker, если группа доступности настроена с типом кластера None, Pacemaker не видит или управляет этой группой доступности. Тип кластера None поддерживает переход на другой ресурс вручную с первичной на вторичную реплику. Группа доступности, созданная с помощью None, в основном предназначена для обновлений и горизонтального масштабирования чтения. Хотя он может работать в таких сценариях, как аварийное восстановление или локальная доступность, когда автоматическая отработка отказа не требуется, рекомендуется. Настройка прослушивателя также будет более сложной без Pacemaker.

Тип кластера хранится в динамическом представлении управления SQL Server (DMV), sys.availability_groupsв столбцах cluster_type и cluster_type_desc.

required_synchronized_secondaries_to_commit

Новое для SQL Server 2017 (14.x) — это параметр, который используется группами required_synchronized_secondaries_to_commitAGS. Он указывает группе доступности количество вторичных реплик, которые должны быть в локстепе с базой данных-источником. Это позволяет выполнять такие действия, как автоматическая отработка отказа (только при интеграции с Pacemaker с типом внешнего кластера), и управляет поведением базы данных-источника, если нужное число вторичных реплик находится в режиме "в сети" или "вне сети". Подробные сведения см. в разделе Высокий уровень доступности и защита данных для конфигураций группы доступности. Значение required_synchronized_secondaries_to_commit задано по умолчанию и поддерживается Pacemaker/ SQL Server. Это значение можно переопределить вручную.

Сочетание required_synchronized_secondaries_to_commit и новый номер последовательности (который хранится в sys.availability_groups) сообщает Pacemaker и SQL Server, что, например, может произойти автоматическая отработка отказа. В этом случае вторичная реплика будет иметь тот же номер последовательности, что и основной, то есть это актуально со всеми последними сведениями о конфигурации.

Для required_synchronized_secondaries_to_commit можно задать три значения: 0, 1 или 2. Они управляют поведением в случае, когда реплика становится недоступной. Числа соответствуют количеству вторичных реплик, которые должны быть синхронизированы с базой данных-источником. В Linux это поведение выглядит следующим образом:

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

Чтобы изменить значение required_synchronized_secondaries_to_commit, используйте следующий синтаксис:

Red Hat Enterprise Linux (RHEL) и Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

В этом примере — имя ресурса, <AGResourceName> настроенного для группы доступности, и <value> равно 0, 1 или 2. Чтобы восстановить ситуацию по умолчанию, когда Pacemaker управляет этим параметром, выполните ту же инструкцию без значения.

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

• Для первичной и вторичной реплики задано синхронное перемещение данных.
• База данных-получатель синхронизирована (не синхронизируется), что означает, что обе базы находятся в одной и той же точке.
• Тип кластера установлен как External. Автоматическая отработка отказа невозможна с типом кластера None.
• Во вторичной реплике, которая станет первичной, sequence_number имеет наибольший порядковый номер — иными словами, sequence_number вторичной реплики соответствует значению исходной первичной реплики.

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

Реплика и кворум только для конфигурации

Кроме того, новая версия SQL Server 2017 (14.x) с накопительным пакетом обновления 1 — это реплика только для конфигурации. Так как Pacemaker отличается от WSFC, особенно когда речь идет о кворуме и требует ограждения неудающегося узла, имея только двухузловую конфигурацию не работает, когда дело доходит до группы доступности. Для FCI механизмы кворума, предоставляемые Pacemaker, могут быть достаточны, так как арбитраж при отработке отказа FCI происходит на уровне кластера. Для группы доступности арбитраж в Linux происходит в SQL Server, где хранятся все метаданные. Именно здесь вступает в дело реплика, предназначенная только для конфигурации.

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

Чтобы группа доступности поддерживала кворум и допускала автоматический переход на другой ресурс с типом кластера External, она должна:

• Есть три синхронные реплики (только выпуск SQL Server Enterprise); или
• Иметь две реплики (первичные и вторичные) и только реплику конфигурации.

Отработка отказа вручную может происходить при использовании типа кластера External или None для конфигураций группы доступности. Хотя реплика только для конфигурации может быть настроена с помощью группы доступности, которая имеет тип кластера None, не рекомендуется, так как это усложняет развертывание. Для этих конфигураций вручную измените required_synchronized_secondaries_to_commit значение не менее 1, чтобы иметь по крайней мере одну синхронизированную реплику.

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

Если используется реплика только для конфигурации, она реализует следующее поведение.

• По умолчанию параметр required_synchronized_secondaries_to_commit имеет значение 0. При необходимости это значение можно изменить вручную на 1.

• Если первичный сбой и required_synchronized_secondaries_to_commit равен 0, вторичная реплика становится новой первичной и становится доступной как для чтения, так и для записи. Если значение равно 1, происходит автоматическая отработка отказа, но не принимает новые транзакции, пока другая реплика не будет подключена к сети.

• Если вторичная реплика завершается ошибкой и required_synchronized_secondaries_to_commit имеет значение 0, первичная реплика по-прежнему принимает транзакции, но если первичный сбой на этом этапе, защита данных и отработка отказа не возможна (вручную или автоматически), так как вторичная реплика недоступна.

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

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

В накопительном пакете обновления 1 есть известная ошибка в журнале corosync.log в файле, созданном с помощью mssql-server-ha. Если вторичная реплика не может стать основной из-за количества необходимых реплик, говорится Expected to receive 1 sequence numbers but only received 2. Not enough replicas are online to safely promote the local replicaв текущем сообщении. Числа должны быть изменены, и он должен сказать Expected to receive 2 sequence numbers but only received 1. Not enough replicas are online to safely promote the local replica.

Множественные группы доступности

Для каждого кластера или набора серверов Pacemaker можно создать несколько групп доступности. Единственное ограничение — системные ресурсы. Владение группами доступности отображается основным. Разные группы доступности могут принадлежать различным узлам; Они не все должны работать на одном узле.

Расположение диска и папки для баз данных

Как и в случае с группами доступности на основе Windows, диск и структура папок для пользовательских баз данных, участвующих в группе доступности, должны быть идентичными. Например, если пользовательские базы данных находятся в /var/opt/mssql/userdata на сервере А, то эта папка должна существовать на сервере B. Единственное исключение указано в разделе Взаимодействие с группами доступности и репликами, основанными на Windows.

Прослушиватель в Linux

Прослушиватель является необязательным компонентом для группы доступности. Он предоставляет единую точку входа для всех подключений (чтение и запись в основную реплику и /или только для чтения для вторичных реплик), чтобы приложения и конечные пользователи не должны знать, какой сервер размещает данные. В WSFC это сочетание ресурса сетевого имени и IP-ресурса, который затем регистрируется в AD DS (при необходимости) и DNS. В сочетании с самим ресурсом AG оно и предоставляет эту абстракцию. Дополнительные сведения о прослушивателе см. в разделе "Подключение к прослушивателю группы доступности AlwaysOn".

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

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

Однако сочетания DNS-имени и IP-адреса по-прежнему недостаточно для предоставления всех функций прослушивателя в WSFC, например маршрутизации вторичных реплик только для чтения. При настройке группы доступности прослушиватель по-прежнему должен быть настроен в SQL Server. Это можно увидеть в мастере и синтаксисе Transact-SQL. Существует два способа настройки этого поведения так же, как в Windows:

• Для группы доступности с типом внешнего типа IP-адрес, связанный с прослушивателем, созданным в SQL Server, должен быть IP-адрес ресурса, созданного в Pacemaker.
• Для группы доступности, созданной с типом кластера None, используйте IP-адрес, связанный с первичной репликой.

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

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

Группа доступности с типом кластера external или one, которая является WSFC, не может иметь свои реплики между платформами. Это верно, является ли группа доступности выпуском SQL Server Standard или выпуском SQL Server Enterprise. Это означает, что в традиционной конфигурации группы доступности с базовым кластером одна реплика не может находиться в WSFC и другой в Linux с Pacemaker.

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

Распределенная группа доступности может также пересекать границы ОС. Базовые группы доступности привязаны к правилам настройки, таким как один, настроенный только для Linux, но группа доступности, присоединенная к ней, может быть настроена с помощью WSFC. Рассмотрим следующий пример:

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

• Настройка группы доступности AlwaysOn SQL Server для обеспечения высокой доступности в Linux
• Настройка группы доступности SQL Server для масштабирования на уровне чтения в Linux
• Добавление ресурса кластера группы доступности в Linux
• Настройка группы доступности SQL Server AlwaysOn в Windows и Linux (кроссплатформенная версия)