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

  • Статья
  • Чтение занимает 11 мин

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

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

С высокоуровневой точки зрения группы доступности с 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. Группа доступности может охватывать не более девяти узлов из 16 с 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 будет использоваться в основе группы доступности. Использование режима External для типа кластера требует, чтобы режим отработки отказа был также установлен как внешний (также появился в 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_commit. Он указывает группе доступности количество вторичных реплик, которые должны быть в локстепе с базой данных-источником. Это позволяет выполнять такие действия, как автоматическая отработка отказа (только при интеграции с 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); с версии 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 или WSFC не может иметь свои реплики на разных платформах. Это верно как для групп доступности SQL Server Standard, так и для SQL Server Enterprise. Это означает, что в традиционной конфигурации группы доступности с базовым кластером одна реплика не может находиться в WSFC, а другая — в Linux с Pacemaker.

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

Гибридная нет.

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

Гибридная группа доступности Dist.

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