Переключение на резерв группы доступности Always On в Linux

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

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

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

Ручное переключение

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

Внимание

Не переключайтесь на резервные копии с помощью средств управления, таких как Transact-SQL, SQL Server Management Studio (SSMS) или PowerShell, в обычных операциях. Если CLUSTER_TYPE = EXTERNAL, единственным допустимым значением для FAILOVER_MODE является EXTERNAL. При таких настройках все вручные или автоматические действия по отказоустойчивости реализуются внешним диспетчером кластера. Инструкции по выполнению принудительной отработки отказа с возможной потерей данных см. в Принудительная обработка отказа.

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

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

Переключитесь вручную в два этапа.

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)

  Примечание.

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

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

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

  sudo pcs resource clear ag_cluster-master
  

  Или

  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 возвращает этот ID.

  crm configure
  delete cli-prefer-ms-ag_cluster
  commit
  

Примечание.

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

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

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

Принудительное переключение

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

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

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

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

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

     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> на имя вашей AG. Подключитесь к экземпляру 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.