Compartilhar via

Configurar o Grupo de Disponibilidade Always On do SQL Server no Windows e no Linux (multiplataforma)

  • Artigo

Aplica-se a: SQL Server 2017 (14.x) e versões posteriores

Este artigo explica as etapas para criar um AG (Grupo de Disponibilidade) Always On com uma réplica em um Windows Server e a outra réplica em um servidor Linux.

Importante

Os grupos de disponibilidade multiplataforma do SQL Server, que incluem réplicas heterogêneas com suporte completo para alta disponibilidade e recuperação de desastre, estão disponíveis com o DH2i DxEnterprise. Para obter mais informações, confira Grupos de disponibilidade do SQL Server com sistemas operacionais mistos.

Veja o vídeo a seguir para saber mais sobre grupos de disponibilidade multiplataforma com DH2i.

Essa configuração é multiplataforma porque as réplicas estão em sistemas operacionais diferentes. Use essa configuração para migrar de uma plataforma para a outra ou para DR (recuperação de desastre). Essa configuração não dá suporte à alta disponibilidade.

Diagrama do grupo de disponibilidade com o tipo de cluster Nenhum.

Antes de continuar, você deve estar familiarizado com a instalação e a configuração para instâncias do SQL Server no Windows e no Linux.

Cenário

Neste cenário, dois servidores estão em sistemas operacionais diferentes. Um Windows Server 2022 chamado WinSQLInstance hospeda a réplica primária. Um servidor Linux chamado LinuxSQLInstance hospeda a réplica secundária.

Configurar o AG

As etapas para criar o AG são as mesmas que as etapas para criar um AG de cargas de trabalho de escala de leitura. O tipo de cluster AG é NONE, porque não há gerenciador de cluster.

Para os scripts neste artigo, colchetes angulares < e > identificam os valores que você precisa substituir para o seu ambiente. Os colchetes angulares em si não são necessários para os scripts.

  1. Instale o SQL Server 2022 (16.x) no Windows Server 2022, habilite os Grupos de Disponibilidade Always On no SQL Server Configuration Manager e defina a autenticação de modo misto.

    Dica

    Se você estiver validando essa solução no Azure, coloque ambos os servidores no mesmo conjunto de disponibilidade para garantir que eles estejam separados no data center.

    Habilitar Grupos de Disponibilidade

    Para obter instruções, confira Habilitar ou desabilitar o recurso de grupo de disponibilidade Always On.

    Captura de tela mostrando como habilitar grupos de disponibilidade.

    O SQL Server Configuration Manager observa que o computador não é um nó em um cluster de failover.

    Depois de habilitar os Grupos de Disponibilidade, reinicie o SQL Server.

    Definir autenticação de modo misto

    Para obter instruções, confira Alterar o modo de autenticação do servidor.

  2. Instale o SQL Server 2022 (16.x) no Linux. Para obter instruções, confira Diretrizes de instalação para o SQL Server no Linux. Habilite hadr com mssql-conf.

    Para habilitar o hadr com o mssql-conf usando um prompt de shell, emita o seguinte comando:

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

    Depois de habilitar hadr, reinicie a instância do SQL Server:

    sudo systemctl restart mssql-server.service

  3. Configure o arquivo hosts nos dois servidores ou registre os nomes de servidor no DNS.

  4. Abra portas de firewall para TPC 1433 e 5022 no Windows e no Linux.

  5. Na réplica primária, crie um logon de banco de dados e uma senha.

    CREATE LOGIN dbm_login WITH PASSWORD = '<C0m9L3xP@55w0rd!>';
CREATE USER dbm_user FOR LOGIN dbm_login;
GO

  6. Na réplica primária, crie uma chave mestra e um certificado e, em seguida, faça backup do certificado com uma chave privada.

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<C0m9L3xP@55w0rd!>';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
WITH PRIVATE KEY (
        FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
        ENCRYPTION BY PASSWORD = '<C0m9L3xP@55w0rd!>'
    );
GO

  7. Copie o certificado e a chave privada para o servidor Linux (réplica secundária) em /var/opt/mssql/data. Você pode usar o pscp para copiar os arquivos para o servidor Linux.

  8. Defina o grupo e a propriedade da chave privada e o certificado como mssql:mssql.

    O script a seguir define o grupo e a propriedade dos arquivos.

    sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.pvk
sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.cer

    No diagrama, a propriedade e o grupo a seguir são definidos corretamente para o certificado e a chave.

    Captura de tela de uma janela do Git Bash mostrando o .cer e o .pvk na pasta /var/opt/mssql/data.

  9. Na réplica secundária, crie um logon de banco de dados e uma senha e crie uma chave mestra.

    CREATE LOGIN dbm_login WITH PASSWORD = '<C0m9L3xP@55w0rd!>';
CREATE USER dbm_user FOR LOGIN dbm_login;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<M@st3rKeyP@55w0rD!>'
GO

  10. Na réplica secundária, restaure o certificado que você copiou para /var/opt/mssql/data.

    CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '<C0m9L3xP@55w0rd!>'
)
GO

  11. Na réplica primária, crie um ponto de extremidade.

    CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_IP = (0.0.0.0), LISTENER_PORT = 5022)
    FOR DATA_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];
GO

    Importante

    O firewall deve estar aberto para a porta TCP do ouvinte. No script anterior, a porta é 5022. Use qualquer porta TCP disponível.

  12. Na réplica secundária, crie o ponto de extremidade. Repita o script anterior na réplica secundária para criar o ponto de extremidade.

  13. Na réplica primária, crie o AG com CLUSTER_TYPE = NONE. O script de exemplo usa SEEDING_MODE = AUTOMATIC para criar o AG.

    Observação

    Quando a instância do SQL Server do Windows usa caminhos diferentes para arquivos de dados e de log, a propagação automática apresenta falha na instância do SQL Server do Linux porque esses caminhos não existem na réplica secundária. Para usar o script a seguir para um AG multiplataforma, o banco de dados requer o mesmo caminho para os arquivos de log e de dados no Windows Server. Como alternativa, você pode atualizar o script para definir SEEDING_MODE = MANUAL e, em seguida, fazer backup e restaurar o banco de dados com o NORECOVERY para propagar o banco de dados.

    Esse comportamento se aplica a imagens do Azure Marketplace.

    Para saber mais sobre a propagação automática, confira Propagação Automática – Layout de Disco.

    Antes de executar o script, atualize os valores para seus AGs.

    • Substitua <WinSQLInstance> pelo nome do servidor da instância do SQL Server da réplica primária.

    • Substitua <LinuxSQLInstance> pelo nome do servidor da instância do SQL Server da réplica secundária.

    Para criar o AG, atualize os valores e execute o script na réplica primária.

    CREATE AVAILABILITY
GROUP [ag1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA
    ON N'<WinSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<WinSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)
    ),
    N'<LinuxSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<LinuxSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL);
    )
GO

    Para obter mais informações, confira CREATE AVAILABILITY GROUP.

  14. Na réplica secundária, ingresse no AG.

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

  15. Crie um banco de dados para o AG. As etapas de exemplo usam um banco de dados chamado TestDB. Se você estiver usando propagação automática, defina o mesmo caminho para os arquivos de dados e de log.

    Antes de executar o script, atualize os valores para seu banco de dados.

    • Substitua TestDB pelo nome do seu banco de dados.

    • Substitua <F:\Path> pelo caminho do banco de dados e dos arquivos de log. Use o mesmo caminho para os arquivos de log e de banco de dados.

    Você também pode usar os caminhos padrão.

    Para criar seu banco de dados, execute o script.

    CREATE DATABASE [TestDB]
   CONTAINMENT = NONE
  ON  PRIMARY ( NAME = N'TestDB', FILENAME = N'<F:\Path>\TestDB.mdf')
  LOG ON ( NAME = N'TestDB_log', FILENAME = N'<F:\Path>\TestDB_log.ldf');
GO

  16. Faça um backup completo do banco de dados.

  17. Se você não estiver usando a propagação automática, restaure o banco de dados no servidor de réplica secundária (Linux). Migrar um banco de dados do SQL Server do Windows para o Linux usando o recurso de backup e restauração. Restaure o banco de dados WITH NORECOVERY na réplica secundária.

  18. Adicione o banco de dados ao AG. Atualize o script de exemplo. Substitua TestDB pelo nome do seu banco de dados. Na réplica primária, execute a consulta T-SQL para adicionar o banco de dados ao AG.

    ALTER AG [ag1] ADD DATABASE TestDB;
GO

  19. Verifique se o banco de dados está sendo preenchido na réplica secundária.

Fazer failover da réplica primária

Cada grupo de disponibilidade tem apenas uma réplica primária. A réplica primária permite leituras e gravações. Para alterar qual réplica é a primária, faça failover. Em um grupo de disponibilidade típico, o gerenciador de cluster automatiza o processo de failover. Em um grupo de disponibilidade com o tipo de cluster NONE, o processo de failover é manual.

Há duas maneiras de fazer failover da réplica primária em um grupo de disponibilidade com o tipo de cluster NONE:

  • Failover manual sem perda de dados
  • Failover manual forçado com perda de dados

Failover manual sem perda de dados

Use esse método quando a réplica primária estiver disponível, mas você precisar alterar temporária ou permanentemente a instância que hospeda a réplica primária. Para evitar a perda potencial de dados, antes de emitir o failover manual, verifique se a réplica secundária de destino está atualizada.

Para fazer failover manualmente sem perda de dados:

  1. Torne a réplica atual primária e a de destino secundária do SYNCHRONOUS_COMMIT.

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

  2. Para identificar que as transações ativas foram confirmadas na réplica primária e em pelo menos uma réplica secundária síncrona, execute a consulta a seguir:

    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;

    A réplica secundária é sincronizada quando synchronization_state_desc é SYNCHRONIZED.

  3. Atualize REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT para 1.

    O script a seguir define REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1 em um grupo de disponibilidade chamado ag1. Antes de executar o script a seguir, substitua ag1 pelo nome do seu grupo de disponibilidade:

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

    Essa configuração garante que todas as transações ativas são confirmadas na réplica primária e em, pelo menos, uma réplica secundária síncrona.

    Observação

    Essa configuração não é específica do failover e deve ser definida com base nos requisitos do ambiente.

  4. Defina a réplica primária e as réplicas secundárias que não participam do failover offline para se prepararem para a alteração de função:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Promova a réplica secundária de destino para a primária.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Atualize a função da réplica primária antiga e outras secundárias para SECONDARY e execute o seguinte comando na instância do SQL Server que hospeda a réplica primária antiga:

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

    Observação

    Para excluir um grupo de disponibilidade, use DROP AVAILABILITY GROUP. Para um grupo de disponibilidade criado com o tipo de cluster NONE ou EXTERNAL, execute o comando em todas as réplicas que fazem parte do grupo de disponibilidade.

  7. Retome a movimentação de dados, execute o seguinte comando para cada banco de dado no grupo de disponibilidade da instância de SQL Server que hospeda a réplica primária:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Crie novamente qualquer ouvinte criado para fins de escala de leitura e que não seja gerenciado por um gerenciador de clusters. Se o ouvinte original apontar para a réplica primária antiga, descarte-o e crie-o novamente para apontar para a nova réplica primária.

Failover manual forçado com perda de dados

Se a réplica primária não estiver disponível e não puder ser recuperada imediatamente, você precisará forçar um failover para a réplica secundária com perda de dados. No entanto, se a réplica primária original for recuperada após o failover, ela assumirá a função primária. Para evitar que cada réplica esteja em um estado diferente, remova a primária original do grupo de disponibilidade após um failover forçado com perda de dados. Quando a primária original voltar a ficar online, remova-a totalmente do grupo de disponibilidade.

Para forçar um failover manual com perda de dados da réplica primária N1 para a réplica secundária N2, siga estas etapas:

  1. Na réplica secundária (N2), inicie o failover forçado:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Na nova réplica primária (N2), remova a primária original (N1):

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

  3. Valide se todo o tráfego do aplicativo é apontado para o ouvinte e/ou para a nova réplica primária.

  4. Se a primária original (N1) ficar online, use imediatamente o grupo de disponibilidade AGRScale offline na primária original (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Se houver dados ou alterações não sincronizadas, preserve esses dados por meio de backups ou de outras opções de replicação de dados que atendam às suas necessidades de negócios.

  6. Em seguida, remova o grupo de disponibilidade da primária original (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Remova o banco de dados do grupo de disponibilidade na réplica primária original (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Opcional) Se desejar, agora você poderá adicionar a N1 de volta como uma nova réplica secundária ao grupo de disponibilidade AGRScale.

Este artigo analisou as etapas para criar um AG multiplataforma para dar suporte a cargas de trabalho de migração ou de escala de leitura. Ele pode ser usado para recuperação manual de desastre. Ele também explicou como fazer failover do AG. Um AG multiplataforma usa o tipo de cluster NONE e não dá suporte à alta disponibilidade.

Conteúdo relacionado