Настройка группы доступности SQL Server для чтения и масштабирования в LinuxConfigure a SQL Server Availability Group for read-scale on Linux

Область применения:  ДаSQL Server (только в Linux) НетБаза данных SQL Azure НетХранилище данных SQL AzureНетParallel Data Warehouse APPLIES TO: yesSQL Server (Linux only) noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

Группу доступности Always On SQL Server для рабочих нагрузок для чтения и масштабирования можно настроить в Linux.You can configure a SQL Server Always On Availability Group (AG) for read-scale workloads on Linux. Существует два типа архитектур для групп доступности.There are two types of architectures for AGs. Архитектура для высокого уровня доступности использует диспетчер кластера для улучшенного обеспечения непрерывности бизнес-процессов.A architecture for high availability uses a cluster manager to provide improved business continuity. Она может также содержать реплики для чтения и масштабирования.This architecture also can include read-scale replicas. Сведения о создании архитектуры с высоким уровнем доступности см. в статье Настройка группы доступности Always On SQL Server для обеспечения высокой доступности в Linux.To create the high-availability architecture, see Configure SQL Server Always On Availability Group for high availability on Linux. Другая архитектура поддерживает только рабочие нагрузки для чтения и масштабирования.The other architecture supports only read-scale workloads. В этой статье описывается создание группы доступности для рабочих нагрузок чтения и масштабирования без диспетчера кластеров.This article explains how to create an AG without a cluster manager for read-scale workloads. Эта архитектура обеспечивает только чтение и масштабирование.This architecture provides read-scale only. Она не поддерживает высокий уровень доступности.It doesn't provide high availability.

Примечание

В группу доступности с CLUSTER_TYPE = NONE могут входить реплики, размещенные на различных платформах операционных систем.An availability group with CLUSTER_TYPE = NONE can include replicas hosted on different operating system platforms. Она не поддерживает высокий уровень доступности.It cannot support high availability.

предварительные требованияPrerequisites

Перед созданием группы доступности необходимо выполнить следующие действия:Before you create the availability group, you need to:

  • Настроить среду таким образом, чтобы все серверы, в которых будут находиться группы доступности, могли взаимодействовать между собой.Set your environment so that all the servers that will host availability replicas can communicate.
  • Установите SQL Server.Install SQL Server.

Примечание

В Linux группу доступности необходимо создать перед тем, как добавить ее в качестве кластерного ресурса, управляемого кластером.On Linux, you must create an availability group before you add it as a cluster resource to be managed by the cluster. В этом документе приводится пример создания группы доступности.This document provides an example that creates the availability group. Инструкции по созданию кластера и добавлению группы доступности в качестве кластерного ресурса для конкретных сред см. по ссылкам в разделе "Дальнейшие действия".For distribution-specific instructions to create the cluster and add the availability group as a cluster resource, see the links under "Next steps."

  1. Обновление имени компьютера для каждого узла.Update the computer name for each host.

    Каждое имя SQL Server должно отвечать следующим требованиям:Each SQL Server name must be:

    • 15 символов или меньше;15 characters or less.
    • уникальность в пределах сети.Unique within the network.

    Чтобы указать имя компьютера, измените файл /etc/hostname.To set the computer name, edit /etc/hostname. Следующий сценарий позволяет изменить /etc/hostname с помощью vi:The following script lets you edit /etc/hostname with vi:

    sudo vi /etc/hostname
    
  2. Настройка файла hosts.Configure the hosts file.

    Примечание

    Если имена узлов зарегистрированы с их IP-адресами на DNS-сервере, указанные ниже действия выполнять не нужно.If hostnames are registered with their IP in the DNS server, you don't need to do the following steps. Убедитесь, что все узлы, которые требуется включить в конфигурацию группы доступности, могут взаимодействовать друг с другом.Validate that all the nodes intended to be part of the availability group configuration can communicate with each other. (Команда проверки связи с узлом должна возвращать ответ с соответствующим IP-адресом.) Кроме того, проверьте, не содержит ли файл /etc/hosts запись, которая сопоставляет IP-адрес localhost 127.0.0.1 с именем узла.(A ping to the hostname should reply with the corresponding IP address.) Also, make sure that the /etc/hosts file doesn't contain a record that maps the localhost IP address 127.0.0.1 with the hostname of the node.

    Файл hosts на каждом сервере содержит IP-адреса и имена всех серверов, которые будут участвовать в группе доступности.The hosts file on every server contains the IP addresses and names of all servers that will participate in the availability group.

    Следующая команда возвращает IP-адрес текущего сервера:The following command returns the IP address of the current server:

    sudo ip addr show
    

    Обновите /etc/hosts.Update /etc/hosts. Следующий сценарий позволяет изменить /etc/hosts с помощью vi:The following script lets you edit /etc/hosts with vi:

    sudo vi /etc/hosts
    

    В следующем примере показан файл /etc/hosts на узле node1 с дополнениями для узлов node1, node2 и node3.The following example shows /etc/hosts on node1 with additions for node1, node2, and node3. В этом документе node1 относится к серверу, на котором размещается первичная реплика,In this document, node1 refers to the server that hosts the primary replica. а node2 и node3 относятся к серверам, на которых размещаются вторичные реплики.And node2 and node3 refer to servers that host the secondary replicas.

    127.0.0.1   localhost localhost4 localhost4.localdomain4
    ::1       localhost localhost6 localhost6.localdomain6
    10.128.18.12 node1
    10.128.16.77 node2
    10.128.15.33 node3
    

Установка SQL ServerInstall SQL Server

Установите SQL Server.Install SQL Server. Инструкции по установке SQL Server для различных сред см. по указанным ниже ссылкам:The following links point to SQL Server installation instructions for various distributions:

Включение групп доступности AlwaysOn и перезапуск mssql-serverEnable AlwaysOn availability groups and restart mssql-server

Включите группы доступности Always On на каждом узле с экземпляром SQL Server.Enable AlwaysOn availability groups on each node that hosts a SQL Server instance. Затем перезапустите mssql-server.Then restart mssql-server. Выполните следующий скрипт:Run the following script:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled  1
sudo systemctl restart mssql-server

Включение сеанса событий AlwaysOn_healthEnable an AlwaysOn_health event session

При необходимости вы можете включить расширенные события групп доступности AlwaysOn, что может помочь в устранении их неполадок.You can optionally enable AlwaysOn availability groups extended events to help with root-cause diagnosis when you troubleshoot an availability group. На каждом экземпляре SQL Server выполните следующую команду:Run the following command on each instance of SQL Server:

ALTER EVENT SESSION  AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Дополнительные сведения о сеансах расширенных событий см. в разделе Расширенные события Always On.For more information about this XE session, see AlwaysOn extended events.

Создание сертификатаCreate a certificate

Служба SQL Server на Linux использует сертификаты для проверки подлинности при обмене данными между конечными точками с зеркальным отображением.The SQL Server service on Linux uses certificates to authenticate communication between the mirroring endpoints.

Следующий сценарий Transact-SQL создает главный ключ и сертификат.The following Transact-SQL script creates a master key and a certificate. Затем он создает резервную копию сертификата и защищает файл закрытым ключом.It then backs up the certificate and secures the file with a private key. Обновите сценарий, задав надежные пароли.Update the script with strong passwords. Подключение к первичному экземпляру SQL Server.Connect to the primary SQL Server instance. Чтобы создать сертификат, выполните следующий скрипт Transact-SQL:To create the certificate, run the following Transact-SQL script:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
       );

На этом этапе первичная реплика SQL Server имеет сертификат в файле /var/opt/mssql/data/dbm_certificate.cer и закрытый ключ в файле var/opt/mssql/data/dbm_certificate.pvk.At this point, your primary SQL Server replica has a certificate at /var/opt/mssql/data/dbm_certificate.cer and a private key at var/opt/mssql/data/dbm_certificate.pvk. Скопируйте эти файлы в одно и то же место на всех серверах, где будут размещаться реплики доступности.Copy these two files to the same location on all servers that will host availability replicas. Выберите пользователя mssql или предоставьте пользователю mssql разрешения на доступ к этим файлам.Use the mssql user, or give permission to the mssql user to access these files.

Например, на исходном сервере указанная ниже команда копирует файлы на целевой компьютер.For example, on the source server, the following command copies the files to the target machine. Замените значения **<node2>** на имена экземпляров SQL Server, где будут размещены реплики.Replace the **<node2>** values with the names of the SQL Server instances that will host the replicas.

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

На каждом целевом сервере предоставьте пользователю mssql разрешение на доступ к сертификату.On each target server, give permission to the mssql user to access the certificate.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Создание сертификата на серверах-получателяхCreate the certificate on secondary servers

Следующий сценарий Transact-SQL создает главный ключ и сертификат из резервной копии, созданной в первичной реплике SQL Server.The following Transact-SQL script creates a master key and a certificate from the backup that you created on the primary SQL Server replica. Обновите сценарий, задав надежные пароли.Update the script with strong passwords. Для расшифровки используется тот же пароль, что и при создании PVK-файла в предыдущем шаге.The decryption password is the same password that you used to create the .pvk file in a previous step. Выполните следующий скрипт на всех серверах-получателях для создания сертификата:To create the certificate, run the following script on all secondary servers:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
            );

Создайте конечные точки на всех репликах зеркального отображения базы данныхCreate the database mirroring endpoints on all replicas

Для передачи и получения сообщений между экземплярами серверов, участвующими в сеансах зеркального отображения базы данных или размещающих реплики доступности, в конечных точках зеркального отображения базы данных используется протокол TCP.Database mirroring endpoints use the Transmission Control Protocol (TCP) to send and receive messages between the server instances that participate in database mirroring sessions or host availability replicas. Конечная точка зеркального отображения базы данных прослушивает порт TCP с уникальным номером.The database mirroring endpoint listens on a unique TCP port number.

Следующий запрос Transact-SQL создает конечную точку прослушивания с именем Hadr_endpoint для группы доступности.The following Transact-SQL script creates a listening endpoint named Hadr_endpoint for the availability group. Он запускает конечную точку и предоставляет созданному вами сертификату разрешение на подключение.It starts the endpoint and gives connection permission to the certificate that you created. Перед выполнением данного сценария замените значения между **< ... >**.Before you run the script, replace the values between **< ... >**. При необходимости можно включить IP-адрес LISTENER_IP = (0.0.0.0).Optionally you can include an IP address LISTENER_IP = (0.0.0.0). IP-адрес прослушивателя должен быть IPv4-адресом.The listener IP address must be an IPv4 address. Также можно использовать 0.0.0.0.You can also use 0.0.0.0.

Обновите следующий сценарий Transact-SQL для среды на всех экземплярах SQL Server:Update the following Transact-SQL script for your environment on all SQL Server instances:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Примечание

Если вы используете выпуск SQL Server Express на одном узле для размещения реплики, поддерживающей только конфигурацию, единственным допустимым значением для ROLE является WITNESS.If you use SQL Server Express Edition on one node to host a configuration-only replica, the only valid value for ROLE is WITNESS. Выполните следующий скрипт в выпуске SQL Server Express:Run the following script on SQL Server Express Edition:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

TCP-порт в брандмауэре должен быть открыт для порта прослушивателя.The TCP port on the firewall must be open for the listener port.

Важно!

Для выпуска SQL Server 2017 единственный поддерживаемый способ проверки подлинности для конечной точки с зеркальным отображением базы данных — CERTIFICATE.For the SQL Server 2017 release, the only authentication method supported for the database mirroring endpoint is CERTIFICATE. Параметр WINDOWS будет включен в будущем выпуске.The WINDOWS option will be enabled in a future release.

Дополнительные сведения см. в статье Конечная точка зеркального отображения базы данных (SQL Server).For more information, see The database mirroring endpoint (SQL Server).

Создание группы доступностиCreate the AG

Создайте группу доступности.Create the AG. Задайте CLUSTER_TYPE = NONE.Set CLUSTER_TYPE = NONE. Кроме того, задайте для каждой реплики FAILOVER_MODE = MANUAL.In addition, set each replica with FAILOVER_MODE = MANUAL. Клиентские приложения с рабочими нагрузками в области аналитики и отчетности могут напрямую подключаться к базам данных-получателям.Client applications running analytics or reporting workloads can directly connect to the secondary databases. Также можно создать список маршрутизации только для чтения.You also can create a read-only routing list. Подключения к первичной реплике будут переадресовывать запросы на подключение для чтения к каждой из содержащихся в нем вторичных реплик по принципу циклического перебора.Connections to the primary replica forward read connection requests to each of the secondary replicas from the routing list in a round-robin fashion.

Следующий сценарий Transact-SQL создает группу доступности ag1.The following Transact-SQL script creates an AG named ag1. Сценарий настраивает реплики группы доступности с параметром SEEDING_MODE = AUTOMATIC.The script configures the AG replicas with SEEDING_MODE = AUTOMATIC. Если этот параметр задан, SQL Server будет автоматически создавать базы данных на каждом сервере-получателе после его добавления в группу доступности.This setting causes SQL Server to automatically create the database on each secondary server after it is added to the AG. Обновите следующий сценарий для своей среды.Update the following script for your environment. Замените значения <node1> и <node2> на имена экземпляров SQL Server, где размещаются реплики.Replace the <node1> and <node2> values with the names of the SQL Server instances that host the replicas. Замените значение <5022> на порт, заданный для конечной точки.Replace the <5022> value with the port you set for the endpoint. Выполните следующий сценарий Transact-SQL на первичной реплике SQL Server:Run the following Transact-SQL script on the primary SQL Server replica:

CREATE AVAILABILITY GROUP [ag1]
    WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON
        N'<node1>' WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
                    SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            ),
        N'<node2>' WITH ( 
            ENDPOINT_URL = N'tcp://<node2>:<5022>', 
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
            SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
            );
        
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Присоединение дополнительных серверов SQL к группе доступностиJoin secondary SQL Servers to the AG

Следующий сценарий Transact-SQL создает группу доступности ag1.The following Transact-SQL script joins a server to an AG named ag1. Обновите сценарий для своей среды.Update the script for your environment. На каждой вторичной реплике SQL Server выполните следующий сценарий Transact-SQL для присоединения группы доступности:On each secondary SQL Server replica, run the following Transact-SQL script to join the AG:

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
         
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Добавление базы данных в группу доступностиAdd a database to the availability group

Убедитесь, что база данных, добавляемая в группу доступности, находится в режиме полного восстановления и имеет действительную резервную копию журналов.Ensure that the database you add to the availability group is in full recovery mode and has a valid log backup. Если база данных тестовая или только что создана, сделайте ее резервную копию.If this is a test database or a newly created database, take a database backup. На первичной реплике SQL Server выполните следующий сценарий Transact-SQL, чтобы создать базу данных с именем db1 и ее резервную копию.On the primary SQL Server, run the following Transact-SQL script to create and back up a database called db1:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1] 
   TO DISK = N'/var/opt/mssql/data/db1.bak';

На первичной реплике SQL Server выполните следующий сценарий Transact-SQL, чтобы добавить базу данных с именем db1 в группу доступности с именем ag1.On the primary SQL Server replica, run the following Transact-SQL script to add a database called db1 to an availability group called ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Убедитесь, что база данных создана на вторичных серверах.Verify that the database is created on the secondary servers

На каждой вторичной реплике SQL Server выполните следующий запрос, чтобы убедиться, что база данных db1 создана и синхронизирована.On each secondary SQL Server replica, run the following query to see if the db1 database was created and is synchronized:

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

У этой группы доступности нет конфигурации высокого уровня доступности.This AG isn't a high-availability configuration. Если вам требуется высокий уровень доступности, следуйте инструкциям в статье Настройка группы доступности Always On для SQL Server в Linux.If you need high availability, follow the instructions at Configure an Always On Availability Group for SQL Server on Linux. В частности, создайте группу доступности с параметром CLUSTER_TYPE=WSFC (в Windows) или CLUSTER_TYPE=EXTERNAL (в Linux).Specifically, create the AG with CLUSTER_TYPE=WSFC (in Windows) or CLUSTER_TYPE=EXTERNAL (in Linux). Затем выполните интеграцию с диспетчером кластеров с помощью отказоустойчивой кластеризации Windows Server в Windows или Pacemaker в Linux.Then integrate with a cluster manager by using either Windows Server failover clustering on Windows or Pacemaker on Linux.

Подключение к вторичным репликам только для чтенияConnect to read-only secondary replicas

Существует два способа подключения к вторичным репликам только для чтения.There are two ways to connect to read-only secondary replicas. Приложения могут подключаться непосредственно к экземпляру SQL Server, на котором размещена вторичная реплика, и отправлять запросы к базам данных.Applications can connect directly to the SQL Server instance that hosts the secondary replica and query the databases. Они также могут использовать маршрутизацию только для чтения, для которой требуется прослушиватель.They also can use read-only routing, which requires a listener.

Отработка отказа первичной реплики в группе доступности для чтения и масштабированияFail over the primary replica on a read-scale Availability Group

Каждая группа доступности имеет только одну первичную реплику.Each availability group has only one primary replica. Первичная реплика позволяет выполнять операции чтения и записи.The primary replica allows reads and writes. Чтобы изменить первичную реплику, можно выполнить переход на другой ресурс.To change which replica is primary, you can fail over. В группе доступности для обеспечения высокой доступности диспетчер кластеров автоматизирует процесс перехода на другой ресурс.In an availability group for high availability, the cluster manager automates the failover process. В группе доступности с типом кластера NONE принудительная отработка отказа выполняется вручную.In an availability group with cluster type NONE, the failover process is manual.

Существует два способа отработки отказа первичной реплики в группе доступности с типом кластера NONE.There are two ways to fail over the primary replica in an availability group with cluster type NONE:

  • Принудительный переход на другой ресурс вручную с потерей данныхForced manual failover with data loss
  • Переход на другой ресурс вручную без потери данныхManual failover without data loss

Принудительный переход на другой ресурс вручную с потерей данныхForced manual failover with data loss

Это метод можно использовать, если первичная реплика недоступна и не может быть восстановлена.Use this method when the primary replica isn't available and can't be recovered.

Для принудительной отработки отказа с потерей данных подключитесь к экземпляру SQL Server, в котором размещена целевая вторичная реплика, и выполните следующие команды:To force failover with data loss, connect to the SQL Server instance that hosts the target secondary replica and then run the following command:

ALTER AVAILABILITY GROUP [ag1] FORCE_FAILOVER_ALLOW_DATA_LOSS;

При восстановлении предыдущей первичной реплики требуется первичная роль.When the previous primary replica recovers, it will also assume the primary role. Чтобы убедиться, что предыдущая первичная реплика переходит на вторичную роль, выполните на ней приведенную ниже команду.To ensure that the previous primary replica transitions into a secondary role run the following command on the previous primary replica.

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

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

Это метод можно использовать, если первичная реплика доступна, но необходимо временно или навсегда изменить конфигурацию и изменить экземпляр SQL Server, на котором размещена первичная реплика.Use this method when the primary replica is available, but you need to temporarily or permanently change the configuration and change the SQL Server instance that hosts the primary replica. Чтобы избежать возможной потери данных, перед началом ручной отработки отказа убедитесь, что целевая вторичная реплика находится в актуальном состоянии.To avoid potential data loss, before you issue the manual failover, ensure that the target secondary replica is up to date.

Чтобы перейти на другой ресурс вручную без потери данных, выполните следующие действия.To manually fail over without data loss:

  1. Выполните для целевой вторичной реплики SYNCHRONOUS_COMMIT.Make the target secondary replica SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [ag1] 
         MODIFY REPLICA ON N'<node2>' 
         WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
    
  2. Чтобы определить, что активные транзакции фиксируются в первичной реплике и по меньшей мере в одной синхронной вторичной реплике, выполните следующий запрос:To identify that active transactions are committed to the primary replica and at least one synchronous secondary replica, run the following query:

    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.The secondary replica is synchronized when synchronization_state_desc is SYNCHRONIZED.

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

    Следующий скрипт задает для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 в группе доступности ag1.The following script sets REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT to 1 on an availability group named ag1. Перед запуском скрипта замените ag1 именем группы доступности.Before you run the following script, replace ag1 with the name of your availability group:

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

    Этот параметр означает, что все активные транзакции фиксируются на первичной реплике и по меньшей мере на одной синхронной вторичной реплике.This setting ensures that every active transaction is committed to the primary replica and at least one synchronous secondary replica.

  4. Понизьте роль первичной реплики до вторичной.Demote the primary replica to a secondary replica. После понижения роли первичная реплика становится доступной только для чтения.After the primary replica is demoted, it's read-only. Чтобы изменить ее роль на SECONDARY, выполните на экземпляре SQL Server, где размещена первичная реплика, следующую команду:To update the role to SECONDARY, run the following command on the SQL Server instance that hosts the primary replica:

    ALTER AVAILABILITY GROUP [ag1] 
         SET (ROLE = SECONDARY); 
    
  5. Повысьте уровень целевой вторичной реплики до первичной.Promote the target secondary replica to primary.

    ALTER AVAILABILITY GROUP ag1 FORCE_FAILOVER_ALLOW_DATA_LOSS; 
    

    Примечание

    Для удаления группы доступности используйте DROP AVAILABILITY GROUP.To delete an availability group, use DROP AVAILABILITY GROUP. Для группы доступности, созданной с типом кластера NONE или EXTERNAL, выполните команду на всех репликах, входящих в группу доступности.For an availability group that's created with cluster type NONE or EXTERNAL, execute the command on all replicas that are part of the availability group.

Следующие шагиNext steps