Высокий уровень доступности и защита данных для конфигураций группы доступности

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

Эта статья описывает поддерживаемые конфигурации развертывания для групп доступности Always On SQL Server на серверах Linux. Группа доступности поддерживает высокую доступность и защиту данных. Автоматическое обнаружение сбоев, автоматическая отработка отказа и прозрачное переподключение после отработки отказа обеспечивают высокую доступность. Синхронизированные реплики обеспечивают защиту данных.

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

WSFC синхронизирует метаданные конфигурации для арбитража отработки отказа между репликами группы доступности и файловым ресурсом-свидетелем. Если группа доступности не находится в WSFC, экземпляры SQL Server хранят метаданные конфигурации в master базе данных.

Например, группа доступности в кластере Linux имеет CLUSTER_TYPE = EXTERNAL. WSFC для арбитража отработки отказа отсутствует. В этом случае метаданные конфигурации управляются и обслуживаются экземплярами SQL Server. Так как в этом кластере нет следящего сервера, для хранения метаданных состояния конфигурации требуется третий экземпляр SQL Server. Вместе все три экземпляра SQL Server предоставляют распределенное хранилище метаданных для кластера.

Диспетчер кластеров может запрашивать экземпляры SQL Server в группе доступности и управлять отработкой отказа для обеспечения высокой доступности. В кластере Linux Pacemaker является диспетчером кластеров.

SQL Server 2017 с накопительным пакетом обновления 1 обеспечивает высокую доступность для группы доступности с CLUSTER_TYPE = EXTERNAL для двух синхронных реплик и репликой, поддерживающей только конфигурацию. Реплика, поддерживающая только конфигурацию, может размещаться в любом выпуске SQL Server 2017 с накопительным пакетом обновления 1 или более поздней версии, включая выпуск SQL Server Express. Конфигурация только реплика поддерживает сведения о конфигурации группы доступности в master базе данных, но не содержит пользовательские базы данных в группе доступности.

Влияние конфигурации на параметры ресурсов по умолчанию

SQL Server 2017 представляет параметр ресурса кластера REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Этот параметр гарантирует, что указанное число вторичных реплик записывает транзакционные данные в журнал до фиксации каждой транзакции первичной репликой. При использовании внешнего диспетчера кластеров этот параметр влияет как на высокую доступность, так и на защиту данных. Значение по умолчанию для этого параметра зависит от архитектуры на момент создания ресурса кластера. При установке агента ресурсов SQL Server mssql-server-ha и создании ресурса кластера для группы доступности диспетчер кластеров определяет конфигурацию группы доступности и задает REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT соответствующим образом.

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

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

Выберите структуру группы доступности, соответствующую конкретным бизнес-требования по обеспечению высокой доступности, защиты данных и масштабирования для чтения.

Следующие конфигурации описывают конструктивные шаблоны группы доступности и возможности каждого из них. Эти конструктивные шаблоны применяются к группам доступности с CLUSTER_TYPE = EXTERNAL для решений высокой доступности.

  • Три синхронные реплики
  • Две синхронные реплики
  • Две синхронные реплики и реплика, поддерживающая только конфигурацию

Три синхронные реплики

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

Diagram showing three synchronous replicas.

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

Режим доступности Масштабирование для чтения Высокая доступность и
защита данных
Защита данных
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Сбой первичной реплики Автоматический переход на другой ресурс. Возможна потеря данных. Новая первичная реплика доступна для чтения и записи.  Автоматический переход на другой ресурс. Новая первичная реплика доступна для чтения и записи. Автоматический переход на другой ресурс. Новая первичная реплика будет недоступна для пользовательских транзакций обновления до тех пор, пока предыдущая первичная реплика не будет восстановлена и не присоединится к группе доступности в качестве вторичной. 
Один дополнительный реплика сбой Первичная реплика доступна для чтения и записи. Первичная реплика доступна для чтения и записи. Первичная реплика будет недоступна для пользовательских транзакций обновления до тех пор, пока вторичная реплика, находящаяся в состоянии сбоя, не будет восстановлена и не присоединится к группе доступности.

1 По умолчанию

Две синхронные реплики

Эта конфигурация обеспечивает защиту данных. Как и в других конфигурациях групп доступности, она может включать масштабирование для чтения. Конфигурация из двух синхронных реплик не обеспечивает автоматическую высокую доступность. Конфигурация из двух реплик применима только к SQL Server 2017 RTM и больше не поддерживается в более поздних версиях SQL Server 2017 (с накопительным пакетом обновления 1 и выше).

Diagram showing two synchronous replicas.

Группа доступности с двумя синхронными репликами обеспечивает масштабирование для чтения и защиту данных. В следующей таблице описан режим доступности.

Режим доступности Масштабирование для чтения Защита данных
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Сбой первичной реплики Автоматический переход на другой ресурс. Возможна потеря данных. Новая первичная реплика доступна для чтения и записи. Автоматический переход на другой ресурс. Новая первичная реплика будет недоступна для пользовательских транзакций обновления до тех пор, пока предыдущая первичная реплика не будет восстановлена и не присоединится к группе доступности в качестве вторичной.
Один дополнительный реплика сбой Первичная реплика доступна для чтения и записи и подвержена риску потери данных.  Первичная реплика будет недоступна для пользовательских транзакций обновления до тех пор, пока вторичная реплика не будет восстановлена.

1 По умолчанию

Две синхронные реплики и реплика, поддерживающая только конфигурацию

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

Diagram showing a configuration-only availability group.

  1. Синхронная репликация пользовательских данных на вторичную реплику. Она также включает метаданные конфигурации группы доступности.
  2. Синхронная репликация метаданных конфигурации группы доступности. Она не включает пользовательские данные.

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

Примечание.

Группа доступности с репликой, поддерживающей только конфигурацию, впервые появилась в SQL Server 2017 с накопительным пакетом обновления 1. Все экземпляры SQL Server в группе доступности должны быть экземплярами SQL Server 2017 с накопительным пакетом обновления 1 или более поздней версии.

Значение по умолчанию для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT равно 0. В следующей таблице описан режим доступности.

Режим доступности Высокая доступность и
защита данных
Защита данных
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Сбой первичной реплики Автоматический переход на другой ресурс. Новая первичная реплика доступна для чтения и записи. Возможна потеря данных. Автоматический переход на другой ресурс. Новая первичная реплика недоступна для пользовательских транзакций обновления.
Сбой вторичной реплики Первичная реплика доступна для чтения и записи и подвержена риску потери данных (если на первой произошел сбой и ее не удается восстановить). Также отсутствие автоматической отработки отказа при сбое первичной реплики.  Первичная реплика недоступна для пользовательских транзакций обновления. Также отсутствие реплики для отработки отказа при сбое первичной реплики. 
Сбой реплики, поддерживающей только конфигурацию Первичная реплика доступна для чтения и записи. Также отсутствие автоматической отработки отказа при сбое первичной реплики.  Первичная реплика доступна для чтения и записи. Также отсутствие автоматической отработки отказа при сбое первичной реплики. 
Синхронный сбой вторичной реплики и реплики, поддерживающей только конфигурацию Первичная реплика недоступна для пользовательских транзакций обновления. Отсутствие автоматической отработки отказа.  Первичная реплика недоступна для пользовательских транзакций обновления. Также отсутствие реплики для отработки отказа при сбое первичной реплики. 

1 По умолчанию

Примечание.

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

Requirements

  • Все реплики в группе доступности с репликой, поддерживающей только конфигурацию, должны использовать SQL Server 2017 с накопительным пакетом обновления 1 или более поздней версии.
  • Реплика, поддерживающая только конфигурацию, может размещаться в любом выпуске SQL Server, включая SQL Server Express.
  • В дополнение к первичной реплике для группы доступности требуется по меньшей мере одна вторичная реплика.
  • Реплики, поддерживающие только конфигурацию, не учитываются при подсчете максимального количества реплик на экземпляр SQL Server. Выпуск SQL Server Standard поддерживает до трех реплик, SQL Server Enterprise — до 9.

Рекомендации

  • Не более одной реплики, поддерживающей только конфигурацию, для каждой группы доступности.
  • Реплика, поддерживающая только конфигурацию, не может быть первичной.
  • Невозможно изменить режим доступности для реплики, поддерживающей только конфигурацию. Чтобы переключиться с реплики, поддерживающей только конфигурацию, на синхронную или асинхронную вторичную реплику, удалите реплику, поддерживающую только конфигурацию, и добавьте вторичную реплику с требуемым режимом доступности.
  • Реплика, поддерживающая только конфигурацию, синхронна с метаданными группы доступности. Пользовательские данные отсутствуют.
  • Группа доступности с одной первичной репликой и одной репликой, поддерживающей только конфигурацию, но не имеющая вторичной реплики, является недопустимой.
  • Вы не можете создать группу доступности на экземпляре выпуска SQL Server Express.

Общие сведения об агенте ресурсов SQL Server для Pacemaker

SQL Server 2017 (14.x), представленный sequence_number для sys.availability_groups отображения актуальности репликаSYNCHRONOUS_COMMIT. sequence_number — это монотонно возрастающий BIGINT, который показывает, насколько актуальна локальная реплика группы доступности относительно остальных реплик в этой группе доступности. Это число обновляется при отработках отказа, добавлении или удалении реплик, а также выполнении других операций в группах доступности. Сначала оно обновляется в первичной реплике, а затем во вторичных. Таким образом, вторичный реплика, который является актуальной, имеет то же самое, sequence_number что и основной.

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

Повышение уровня гарантируется только тем, что по крайней мере один реплика, доступный для продвижения, имеет тот же порядковый номер, что и предыдущий первичный. Поведение по умолчанию предназначено для агента ресурсов Pacemaker для автоматического заданияREQUIRED_COPIES_TO_COMMIT, чтобы по крайней мере одна синхронная фиксация вторичная реплика была актуальной и доступной, чтобы быть целью автоматической отработки отказа. При каждом действии мониторинга значение REQUIRED_COPIES_TO_COMMIT вычисляется (и, если нужно, обновляется) как ("число реплик синхронной фиксации"/2). Затем во время отработки отказа агент ресурсов должен (total number of replicas - required_copies_to_commitреплика) реагировать на уведомление предварительного повышения, чтобы иметь возможность повысить уровень одного из них до основного. Реплика с самым высоким значение sequence_number повышается до первичной.

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

  • REQUIRED_COPIES_TO_COMMIT — это 3 / 2 = 1

  • Количество реплик, которые должны отреагировать на предварительное действие: 3 – 1 = 2. Поэтому для активации отработки отказа необходимо выполнить два реплика. Когда происходит основной сбой, если один из вторичных реплика не отвечает, и только один из вторичных файлов отвечает на действие предварительного повышения, агент ресурсов не может гарантировать, что вторичный, который ответил, имеет наибольшее sequence_numberзначение, и отработка отказа не активируется.

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

Важно!

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

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

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Эквивалентная команда с помощью crm (в SLES) — это:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

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

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Примечание.

При обновлении свойств ресурсов все реплики останавливаются и перезапускаются. Это означает, что первичный ресурс временно будет понижен до дополнительного, а затем снова повышен, что приведет к временной недоступности записи. Новое значение REQUIRED_COPIES_TO_COMMIT будет задано только после перезапуска реплика, поэтому оно не будет мгновенно с выполнением команды pcs.

Балансируйте высокий уровень доступности и защиту данных

Приведенное выше поведение по умолчанию применяется к примеру двух синхронных реплика (первичный и вторичный). Pacemaker по умолчанию REQUIRED_COPIES_TO_COMMIT = 1 гарантирует, что вторичная реплика всегда актуальна для максимальной защиты данных.

Предупреждение

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

sudo pcs resource update <ag1> required_copies_to_commit=0

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

В следующих таблицах описывается результат сбоя для основных или вторичных реплика в разных конфигурациях ресурсов группы доступности:

Группа доступности — две реплика синхронизации

Настройка Сбой первичной реплики Сбой одной вторичной реплики
REQUIRED_COPIES_TO_COMMIT = 0 Пользователь должен выдавать вручную FAILOVER.
Возможна потеря данных.
Новая первичная реплика доступна для чтения и записи.
Первичная реплика доступна для чтения и записи и подвержена риску потери данных.
REQUIRED_COPIES_TO_COMMIT = 11 Автоматические проблемы с кластером FAILOVER
Потери данных нет.
Новый первичный отклоняет все подключения до тех пор, пока бывшая первичная группа доступности не будет восстановлена и присоединяется к группе доступности в качестве вторичной.
Основной отклоняет все подключения, пока не будет восстановлен вторичный.

1 агент ресурсов SQL Server для поведения Pacemaker по умолчанию.

Группа доступности — три реплика синхронизации

Настройка Сбой первичной реплики Сбой одной вторичной реплики
REQUIRED_COPIES_TO_COMMIT = 0 Пользователь должен выдавать вручную FAILOVER.
Возможна потеря данных.
Новая первичная реплика доступна для чтения и записи.
Первичная реплика доступна для чтения и записи.
REQUIRED_COPIES_TO_COMMIT = 11 Кластер автоматически выдает проблемы FAILOVER.
Потери данных нет.
Новая первичная реплика доступна для чтения и записи.
Первичная реплика доступна для чтения и записи.

1 агент ресурсов SQL Server для поведения Pacemaker по умолчанию.