Отработка отказа группы доступности AlwaysOn в Linux

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

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

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

Переход на другой ресурс вручную

Используйте средства управления кластером для отработки отказа в группе доступности, находящейся под управлением внешнего диспетчера кластера. Например, если решение использует Pacemaker для управления кластером Linux, используйте pcs для выполнения отработки отказа вручную в Red Hat Enterprise Linux (RHEL) или Ubuntu. В SUSE Linux Enterprise Server (SLES) используйте crm.

Этапы отработки отказа вручную

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

Отработка отказа вручную выполняется в два этапа.

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

   Кластер выполняет отработку отказа для ресурса группы доступности, после чего добавляет ограничение расположения. С помощью этого ограничения настраивается выполнение ресурса на новом узле. Чтобы успешно выполнять отработку отказа в дальнейшем, удалите это ограничение.

2. Во-вторых, удалите ограничение расположения.

Шаг 1. Выполнение отработки отказа вручную с перемещением ресурса группы доступности

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

• Пример для RHEL/Ubuntu

  sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S
  

• Пример для SLES

  crm resource migrate ag_cluster nodeName2 --lifetime=30S
  

При использовании параметра ограничение расположения, созданное --lifetime для перемещения ресурса, является временным в природе и допустимо в течение 30 секунд в предыдущем примере.

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

Шаг 2. Удаление ограничения расположения

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

• Пример для RHEL/Ubuntu

  sudo pcs constraint list --full
  

• Пример для SLES

  crm config show
  

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

  Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

  Примечание.

  Имя ресурса группы доступности в кластерах Pacemaker в Red Hat Enterprise Linux 8.x и Ubuntu 18.04 может выглядеть как ag_cluster-клонирование, так как nomenclature относительно ресурсов развивается для использования клона промотабельного.

• Пример для RHEL/Ubuntu

  В следующей команде указан идентификатор ограничения, cli-prefer-ag_cluster-master который необходимо удалить. sudo pcs constraint list --full возвращает этот код.

  sudo pcs resource clear ag_cluster-master
  

  Or

  sudo pcs constraint remove cli-prefer-ag_cluster-master
  

  Кроме того, вы можете выполнять перемещение и очистку автоматически созданных ограничений в одной строке, как показано ниже. В следующем примере термин клон используется в значении, употребляемом в Red Hat Enterprise Linux 8.x.

  sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
  

• Пример для SLES

  В следующей команде cli-prefer-ms-ag_cluster используется идентификатор ограничения. crm config show возвращает этот код.

  crm configure
  delete cli-prefer-ms-ag_cluster
  commit
  

Дополнительные сведения см. по ссылке .

• Red Hat — управление ресурсами кластера
• Pacemaker — перемещение ресурсов вручную
• Руководство по администрированию SLES — управление ресурсами кластера

Принудительное отработка отказа

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

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

Этот процесс принудительной отработки отказа относится к SQL Server на Linux.

1. Убедитесь, что кластер больше не управляет ресурсом группы доступности.

   • Переведите ресурс в неуправляемый режим на целевом узле кластера. Эта команда сигнализирует агенту ресурса о необходимости остановить мониторинг ресурса и управление им. Например:

     sudo pcs resource unmanage <resourceName>
     

   • Если при попытке перевести ресурс в неуправляемый режим происходит сбой, удалите ресурс. Рассмотрим пример.

     sudo pcs resource delete <resourceName>
     

     Примечание.

     При удалении ресурса также будут удалены все связанные с ним ограничения.

2. На экземпляре SQL Server, на котором размещается вторичная реплика, задайте переменную контекста сеанса external_cluster.

   EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
   

3. Выполните отработку отказа для группы доступности с использованием Transact-SQL. В следующем примере замените <MyAg> на имя группы доступности. Подключитесь к экземпляру SQL Server, в котором размещена целевая вторичная реплика, и выполните следующую команду:

   ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

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

5. Перезапустите мониторинг ресурса кластера и управление им:

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

   sudo pcs resource manage <resourceName>
   sudo pcs resource cleanup <resourceName>
   

   Если вы удалили ресурс кластера, создайте его повторно. Чтобы повторно создать ресурс кластера, выполните инструкции, приведенные в статье Создание ресурса группы доступности.

Мониторинг уровня базы данных и триггер отработки отказа

Для CLUSTER_TYPE=EXTERNAL используется отличная от WSFC семантика триггера отработки отказа. Если группа доступности размещается на экземпляре SQL Server в WSFC, переход из состояния ONLINE для базы данных приводит к появлению сообщения о потере работоспособности группы доступности. В ответ на это диспетчер кластера запускает процесс отработки отказа. В Linux экземпляр SQL Server не может взаимодействовать с кластером. Мониторинг работоспособности базы данных осуществляется извне. Если пользователь отказался от отработки отказа на уровне базы данных и отработки отказа (задав параметр DB_FAILOVER=ON при создании группы доступности), кластер проверяет состояние ONLINE базы данных при каждом запуске действия мониторинга. Кластер запрашивает сведения о состоянии в sys.databases. Для любого состояния, отличного от ONLINEдругого, он активирует отработку отказа автоматически (если выполняются автоматические условия отработки отказа). Фактическое время отработки отказа зависит от частоты действия мониторинга, а состояние базы данных обновляется в sys.databases.

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

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

• Настройка кластера Red Hat Enterprise Linux для ресурсов кластера группы доступности SQL Server
• Настройка кластера SUSE Linux Enterprise Server для ресурсов кластера группы доступности SQL Server
• Настройка кластера Ubuntu для ресурсов кластера группы доступности SQL Server

Примите участие в разработке документации по SQL

Знаете ли вы, что содержимое SQL можно изменить самостоятельно? Это не только улучшит нашу документацию, но и даст вам статус участника в создании этой страницы.

Дополнительные сведения см. в разделе Участие в работе над документацией по SQL Server.