Бөлісу құралы:

Выполнение планового перехода на другой ресурс вручную для группы доступности Always On (SQL Server)

  • Мақала

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

Этот раздел описывает, как выполнить переход на другой ресурс вручную без потери данных (запланированный переход на другой ресурс вручную) в группе доступности Always On с помощью SQL Server Management Studio, Transact-SQL или PowerShell в SQL Server. Группа доступности выполняет переход на другой ресурс на уровне реплики доступности. Запланированный переход на другой ресурс вручную, как и любая другая отработка отказа для группы доступности Always On, переводит вторичную реплику на основную роль. При этом бывшая первичная реплика принимает роль вторичной.

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

Примечание.

Если и первичная, и вторичная реплики настроены на автоматический переход на другой ресурс, то вторичная реплика может служить целевой и для этого перехода после синхронизации. Дополнительные сведения см. в разделе Режимы доступности (группы доступности Always On).

Подготовка к работе

Внимание

Существуют определенные процедуры по отработке отказа группы доступности для чтения и масштабирования без диспетчера кластеров. Если в группе доступности задан параметр CLUSTER_TYPE = NONE (тип кластера — отсутствует), следуйте процедурам, описанным в разделе Отработка отказа первичной реплики в группе доступности для чтения и масштабирования.

ограничения

Предварительные требования и ограничения

  • Первичная и целевая вторичная реплики должны работать в режиме доступности с синхронной фиксацией.

  • Целевая вторичная реплика сейчас должна быть синхронизирована с первичной репликой. Все базы данных — получатели в этой вторичной реплике должны быть подключены к группе доступности. Они также должны быть синхронизированы с соответствующими базами данных — источниками (то есть локальные базы данных — получатели должны быть в состоянии SYNCHRONIZED).

    Совет

    Чтобы определить готовность вторичной реплики к отработке отказа, запросите столбец is_failover_ready в динамическом административном представлении sys.dm_hadr_database_replica_cluster_states. Для этого можно также проверить значение столбца Готовность к отработке отказа панели мониторинга группы Always On.

  • Эта задача поддерживается только в целевой вторичной реплике. Необходимо подключиться к экземпляру сервера, на котором размещается целевая вторичная реплика.

Безопасность

Разрешения

Группе доступности необходимо предоставить разрешение ALTER AVAILABILITY GROUP. Также необходимо разрешение CONTROL AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP или CONTROL SERVER.

Использование SQL Server Management Studio

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

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

  2. Разверните узел Высокий уровень доступности AlwaysOn и узел Группы доступности .

  3. Щелкните правой кнопкой мыши группу доступности для отработки отказа и выберите Отработка отказа.

  4. Запустится мастер отработки отказа группы доступности. Дополнительные сведения см. в статье Использование мастера отработки отказа группы доступности (среда SQL Server Management Studio).

Использование Transact-SQL

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

  1. Подключитесь к экземпляру сервера, на котором находится целевая вторичная реплика.

  2. Инструкция ALTER AVAILABILITY GROUP используется следующим образом:

    ALTER AVAILABILITY GROUP имя_группы FAILOVER

    В этой инструкции имя_группы — это имя группы доступности.

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

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

С помощью PowerShell

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

  1. Перейдите в каталог (cd) экземпляра сервера, на котором размещена целевая вторичная реплика.

  2. Используйте командлет Switch-SqlAvailabilityGroup .

    Примечание.

    Чтобы просмотреть синтаксис командлета, используйте командлет Get-Help в среде SQL Server PowerShell. Дополнительные сведения: Получение справки по SQL Server PowerShell.

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

    Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg

    Настройка и использование поставщика SQL Server PowerShell:

Дальнейшие действия. После отработки отказа группы доступности вручную

Если вы выполнили отработку отказа за пределами автоматического набора отработки отказа группы доступности, измените голоса кворума узлов отказоустойчивой кластеризации Windows Server, чтобы отразить новую конфигурацию группы доступности. Дополнительные сведения см. в статье Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server.

Отработка отказа первичной реплики в группе доступности для чтения и масштабирования

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

Существует два способа отработки отказа первичной реплики в группе доступности с типом кластера NONE.

  • Переход на другой ресурс вручную без потери данных
  • Принудительный переход на другой ресурс вручную с потерей данных

Переход на другой ресурс вручную без потери данных

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

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

  1. Сделайте текущую основную и целевую вторичную реплику SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

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

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    Вторичная реплика синхронизируется, если synchronization_state_desc имеет значение SYNCHRONIZED.

  3. Обновите REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT до 1.

    Следующий скрипт задает для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 в группе доступности ag1. Перед запуском скрипта замените ag1 именем группы доступности.

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Этот параметр означает, что все активные транзакции фиксируются на первичной реплике и по меньшей мере на одной синхронной вторичной реплике.

    Примечание.

    Этот параметр не относится к отработке отказа и должен быть задан в зависимости от требований среды.

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

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Повысьте уровень целевой вторичной реплики до первичной.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

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

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Примечание.

    Для удаления группы доступности используйте DROP AVAILABILITY GROUP. Для группы доступности, созданной с типом кластера NONE или EXTERNAL, выполните команду на всех репликах, входящих в группу доступности.

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

    ALTER DATABASE [db1]
     SET HADR RESUME

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

Принудительный переход на другой ресурс вручную с потерей данных

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

Для принудительной отработки отказа вручную с потерей данных с первичной реплики N1 на вторичную реплику N2 выполните следующие действия.

  1. На вторичной реплике (N2) инициируйте принудительную отработку отказа.

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. На новой первичной реплике (N2) удалите исходную первичную реплику (N1).

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Убедитесь, что весь трафик приложения направляется на прослушиватель и (или) новую первичную реплику.

  4. Если исходная первичная реплика (N1) переходит в сетевой режим, немедленно переведите группу доступности AGRScale в автономный режим на исходной первичной реплике (N1).

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

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

  6. Затем удалите группу доступности из исходной первичной реплики (N1).

    DROP AVAILABILITY GROUP [AGRScale];

  7. Удалите базу данных группы доступности на исходной первичной реплике (N1).

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Необязательно) При необходимости можно добавить N1 обратно в группу доступности AGRScale в качестве новой вторичной реплики.

См. также