Поделиться через

Выполнение планового ручного переключения для группы доступности "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 имя_группы ПЕРЕКЛЮЧЕНИЕ

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

    В следующем примере выполняется ручное переключение группы доступности 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 в качестве новой вторичной реплики.

См. также