Отработка отказа для группы доступности Always On на Linux

  • Статья

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

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

Общие сведения об отработке отказа см. в статье Отработка отказа и режимы отработки отказа.

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

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

Внимание

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

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

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

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

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

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

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

Шаг 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

Примечание.

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

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

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

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

Если вы не можете использовать средства управления кластером для взаимодействия с кластером, например если кластер не отвечает из-за аварии в основном центре обработки данных, вам может потребоваться выполнить принудительную отработку отказа, чтобы обойти внешний диспетчер кластера. Поскольку эта процедура сопряжена с риском потери данных, не рекомендуется выполнять ее в нормальных обстоятельствах. Она может потребоваться в тех случаях, когда не удается выполнить отработку отказа с применением средств управления кластером. С функциональной точки зрения эта процедура похожа на выполнение принудительной отработки отказа вручную для группы доступности в 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.

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

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

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

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

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