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

  • Статья

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

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

Примечание.

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

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

  • Координатор распределенных транзакций Майкрософт (DTC) поддерживается в Linux начиная с версии SQL Server 2017 с накопительным пакетом обновления 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 (CU1) появились только реплика конфигурации, поэтому для этой конфигурации должна быть минимальная версия.

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

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

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

Новые возможности SQL Server 2017 (14.x) — это введение в тип кластера для групп доступности. Для Linux существует два допустимых значения: External (Внешний) и None (Нет). Тип внешнего кластера означает, что 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 это поведение выглядит следующим образом:

  • 0 — вторичные реплика не должны находиться в синхронизированном состоянии с основным. Однако если вторичные файлы не синхронизированы, автоматической отработки отказа не будет.
  • 1 — одна вторичная реплика должна находиться в состоянии синхронизации с источником; возможен автоматический переход на другой ресурс. База данных-источник недоступна, пока не будет доступна вторичная синхронная реплика.
  • 2 — обе вторичные реплики в трех конфигурациях группы доступности узла или более должны быть синхронизированы с базой данных-источником; возможен автоматический переход на другой ресурс.

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 (CU1) — это только реплика конфигурации. Так как Pacemaker отличается от WSFC, особенно когда дело доходит до кворума и требования STONITH, имея только двухузловую конфигурацию не будет работать, когда речь идет о группе доступности. Для 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. Если вторичный реплика не может стать основным из-за количества доступных необходимых реплика, текущее сообщение говорит: "Ожидается получать 1 порядковые номера, но только получено 2. Недостаточно реплик в сети для безопасного повышения уровня локальной реплики". Номера должны стоять в обратном порядке: "Ожидалось получение 2 порядковых номеров, но получен только 1. Недостаточно реплик в сети для безопасного повышения уровня локальной реплики".

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

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

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

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

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

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

Прослушиватель в Linux настраивается иначе, но его функциональные возможности аналогичны. В Pacemaker нет концепции ресурса сетевого имени, а также объекта, созданного в AD DS; в Pacemaker можно создать только ресурс IP-адреса, который может выполняться на любом из узлов. Для прослушивателя в 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.

Hybrid None.

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

Hybrid Dist AG.

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