Partilhar via

Configurar o grupo de disponibilidade Always On do SQL Server no Windows e Linux (multiplataforma)

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

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

Importante

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

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

Essa configuração é multiplataforma porque as réplicas estão em sistemas operacionais diferentes. Use essa configuração para migração de uma plataforma para a outra ou recuperação de desastres (DR). Esta configuração não suporta alta disponibilidade.

grupo Diagrama de Disponibilidade com tipo de cluster Nenhum.

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

Cenário

Nesse 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 para cargas de trabalho escala de leitura. O tipo de cluster AG é NONE, já que não há um gestor de cluster.

Para os scripts neste artigo, parênteses angulares < e > identificam os valores que deve substituir para o seu ambiente. Os parênteses 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 de Grupos de Disponibilidade Always On do SQL Server Configuration Manager e defina a autenticação de modo misto.

    Dica

    Se estiver a validar esta solução no Azure, coloque ambos os servidores no mesmo conjunto de disponibilidade para garantir que estão separados no centro de dados.

    Habilitar grupos de disponibilidade

    Para obter instruções, consulte Ativar ou desativar o recurso de grupo de disponibilidade Always On.

    Captura de ecrã a mostrar como ativar os Grupos de Disponibilidade.

    O Gestor de Configurações do SQL Server indica 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, consulte Alterar o modo de autenticação do servidor.

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

    Para habilitar hadr por meio de mssql-conf a partir de um prompt de shell, execute o seguinte comando:

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

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

    sudo systemctl restart mssql-server.service

  3. Configure o arquivo hosts em ambos os servidores ou registre os nomes dos servidores com o DNS.

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

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

    CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

    Atenção

    A sua palavra-passe deve seguir a política de palavra-passe padrão do SQL Server . Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

  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 = '<master-key-password>';

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 = '<private-key-password>'
);
GO

    Atenção

    A sua palavra-passe deve seguir a política de palavra-passe padrão do SQL Server . Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

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

  8. Defina o grupo e a propriedade da chave privada e do 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 seguir, a propriedade e o grupo 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 login e senha de banco de dados e crie uma chave mestra.

    CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

    Atenção

    A sua palavra-passe deve seguir a política de palavra-passe padrão do SQL Server . Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

  10. Na réplica secundária, restaure o certificado copiado 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 = '<private-key-password>'
);
GO

    No exemplo anterior, substitua <private-key-password> pela mesma senha usada ao criar o certificado na réplica primária.

  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 DATABASE_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 precedentemente mencionado na réplica secundária para definir o ponto final.

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

    Esse comportamento se aplica às imagens do Azure Marketplace.

    Para obter mais informações sobre a propagação automática, consulte Automatic Seeding - Disk Layout.

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

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

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

    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, consulte CREATE AVAILABILITY GROUP.

  14. Na réplica secundária, junte-se ao 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 a propagação automática, defina o mesmo caminho para os dados e os arquivos de log.

    Antes de executar o script, atualize os valores do 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 o banco de dados e os arquivos de log.

    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 SQL Server do Windows para o Linux usando 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.

Failover da réplica principal

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, pode efetuar um failover. Em um grupo de disponibilidade típico, o gerenciador de cluster automatiza o processo de failover. Em um grupo de disponibilidade com cluster tipo 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 qual instância hospeda a réplica primária. Para evitar possíveis perdas 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 primária atual a secundária de destino SYNCHRONOUS_COMMIT.

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

  2. Para identificar que as transações ativas estão comprometidas com a réplica primária e pelo menos uma réplica secundária síncrona, execute a seguinte consulta:

    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 seguinte script, substituaag1 pelo nome do seu grupo de disponibilidade:

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

    Essa configuração garante que cada transação ativa seja confirmada para a réplica primária e pelo menos uma réplica secundária síncrona.

    Observação

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

  4. Defina a réplica primária e a(s) réplica(s) secundária(s) que não participa(m) 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 primária.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Atualize o papel do antigo primário e dos outros secundários para SECONDARY, 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 dados no grupo de disponibilidade na instância do SQL Server que hospeda a réplica primária:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Recrie qualquer ouvinte que tenha sido criado para fins de escalonamento de leitura e que não seja gerido por um gestor de cluster. Se o ouvinte original apontar para a primária antiga, solte-a e recrie-a para apontar para a nova 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, será necessário forçar um failover para a réplica secundária com perda de dados. No entanto, se a réplica primária original se recuperar após o failover, ela assumirá a função principal. Para evitar que cada réplica esteja em um estado diferente, remova o primário original do grupo de disponibilidade após um failover forçado com perda de dados. Quando o primário original voltar a ficar online, remova totalmente o 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 está apontado para o ouvinte e/ou para a nova réplica primária.

  4. Se o primário original (N1) ficar online, coloque imediatamente o grupo de disponibilidade AGRScale offline no primário 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 outras opções de replicação de dados que atendam às suas necessidades de negócios.

  6. Em seguida, remova o grupo de disponibilidade do servidor primário original (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Elimine a base 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ê pode adicionar N1 novamente 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 à migração ou cargas de trabalho em escala de leitura. Ele pode ser usado para recuperação manual de desastres. Também explicou como fazer o failover da AG. Um AG multiplataforma usa o tipo de cluster NONE e não suporta alta disponibilidade.

Conteúdo relacionado

  • Last updated on