Criar e configurar um grupo de disponibilidade para o SQL Server no Linux

Aplica-se a:SQL Server em Linux

Este tutorial mostra como criar e configurar um grupo de disponibilidade (AG) para SQL Server no Linux. Ao contrário do SQL Server 2016 (13.x) e versões anteriores no Windows, pode ativar um AG com ou sem criar primeiro o cluster Pacemaker subjacente. A integração com o cluster, se necessário, acontece mais tarde.

O tutorial inclui as seguintes tarefas:

Habilite grupos de disponibilidade.
Crie pontos de extremidade e certificados do grupo de disponibilidade.
Use o SQL Server Management Studio (SSMS) ou Transact-SQL para criar um grupo de disponibilidade.
Crie o logon e as permissões do SQL Server para o Pacemaker.
Crie recursos de grupo de disponibilidade em um cluster do Pacemaker (somente tipo externo).

Pré-requisitos

Implante o cluster de alta disponibilidade do Pacemaker conforme descrito em Implantar um cluster do Pacemaker para SQL Server no Linux.

Ativar o recurso de grupos de disponibilidade

Ao contrário do Windows, você não pode usar o PowerShell ou o SQL Server Configuration Manager para habilitar o recurso de grupos de disponibilidade (AG). No Linux, pode ativar a funcionalidade de grupos de disponibilidade de duas formas: usar a utilidade mssql-conf ou editar o mssql.conf ficheiro manualmente.

Importante

Tem de ativar a funcionalidade AG para réplicas apenas de configuração, mesmo no SQL Server Express.

Use o utilitário mssql-conf

No terminal, execute o seguinte comando:

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

Editar o arquivo mssql.conf

Também pode modificar o mssql.conf ficheiro, localizado na /var/opt/mssql pasta. Adicione as seguintes linhas:

[hadr]

hadr.hadrenabled = 1

Reiniciar o SQL Server

Depois de ativar os grupos de disponibilidade, deve reiniciar o SQL Server. Use o seguinte comando:

sudo systemctl restart mssql-server

Criar pontos finais e certificados do grupo de disponibilidade

Um grupo de disponibilidade utiliza endpoints TCP para comunicação. No Linux, o SQL Server suporta endpoints para um AG apenas se usar certificados para autenticação. Deve restaurar o certificado de uma instância em todas as outras instâncias que participam como réplicas no mesmo Grupo de Disponibilidade (AG). É necessário o processo de certificação mesmo que seja para uma réplica de apenas configuração.

Só pode criar endpoints e restaurar certificados usando o Transact-SQL. Também pode usar certificados gerados por servidores não SQL. Você também precisa de um processo para gerenciar e substituir quaisquer certificados que expiram.

Importante

Se você planeja usar o assistente do SQL Server Management Studio para criar o AG, ainda precisará criar e restaurar os certificados usando Transact-SQL no Linux.

Para a sintaxe completa das opções disponíveis para os vários comandos (incluindo segurança), veja:

Observação

Embora estejas a criar um grupo de disponibilidade, o tipo de ponto de extremidade utiliza FOR DATABASE_MIRRORING, porque alguns aspetos subjacentes foram anteriormente partilhados com essa funcionalidade agora obsoleta.

Este exemplo cria certificados para uma configuração de três nós. Os nomes de instâncias são LinAGN1, LinAGN2e LinAGN3.

Execute o script a seguir no LinAGN1 para criar a chave mestra, o certificado e o ponto de extremidade e faça backup do certificado. Neste exemplo, usa-se a porta TCP típica 5022 para o ponto de extremidade.

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

CREATE CERTIFICATE LinAGN1_Cert
WITH SUBJECT = 'LinAGN1 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN1_Cert
TO FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN1_Cert,
    ROLE = ALL
);
GO

Faça o mesmo em LinAGN2:

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

CREATE CERTIFICATE LinAGN2_Cert
WITH SUBJECT = 'LinAGN2 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN2_Cert
TO FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN2_Cert,
    ROLE = ALL
);
GO

Finalmente, execute a mesma sequência em LinAGN3:

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

CREATE CERTIFICATE LinAGN3_Cert
WITH SUBJECT = 'LinAGN3 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN3_Cert
TO FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN3_Cert,
    ROLE = ALL
);
GO

Usando scp ou outra utilidade, copie as cópias de segurança do certificado para cada nó que pretende incluir no AG.

Para este exemplo:
- Copie LinAGN1_Cert.cer para LinAGN2 e LinAGN3.
- Copie LinAGN2_Cert.cer para LinAGN1 e LinAGN3.
- Copie LinAGN3_Cert.cer para LinAGN1 e LinAGN2.
Altere a propriedade e o grupo associado aos arquivos de certificado copiados para mssql.
```
sudo chown mssql:mssql <CertFileName>
```
Crie os logins e usuários no nível da instância associados ao LinAGN2 e LinAGN3 no LinAGN1.
```
CREATE LOGIN LinAGN2_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN2_User
FOR LOGIN LinAGN2_Login;
GO

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

CREATE USER LinAGN3_User
FOR LOGIN LinAGN3_Login;
GO
```
Atenção

Sua senha deve seguir a política de senha de 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.

Restaure LinAGN2_Cert e LinAGN3_Cert no LinAGN1. Ter os certificados das outras réplicas é um aspeto importante da comunicação e segurança da AG.

CREATE CERTIFICATE LinAGN2_Cert
    AUTHORIZATION LinAGN2_User
    FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
    AUTHORIZATION LinAGN3_User
    FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Conceda permissão aos logins associados a LinAGN2 e LinAGN3 para se ligarem ao endpoint no LinAGN1.

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;

Crie os logins e usuários no nível da instância associados ao LinAGN1 e LinAGN3 no LinAGN2.

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

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

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

CREATE USER LinAGN3_User
FOR LOGIN LinAGN3_Login;
GO

Restaure LinAGN1_Cert e LinAGN3_Cert no LinAGN2.

CREATE CERTIFICATE LinAGN1_Cert
    AUTHORIZATION LinAGN1_User
    FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
    AUTHORIZATION LinAGN3_User
    FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Conceda permissão aos logins associados a LinAGN1 e LinAGN3 para se ligarem ao endpoint no LinAGN2.

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO

Crie os logins e usuários no nível da instância associados ao LinAGN1 e LinAGN2 no LinAGN3.

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

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

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

CREATE USER LinAGN2_User
FOR LOGIN LinAGN2_Login;
GO

Restaure LinAGN1_Cert e LinAGN2_Cert no LinAGN3.

CREATE CERTIFICATE LinAGN1_Cert
    AUTHORIZATION LinAGN1_User
    FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN2_Cert
    AUTHORIZATION LinAGN2_User
    FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

Conceda permissão aos logins associados a LinAG1 e LinAGN2 para se ligarem ao endpoint no LinAGN3.

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO

Criar o grupo de disponibilidade

Esta secção mostra como usar o SQL Server Management Studio (SSMS) ou Transact-SQL para criar o grupo de disponibilidade do SQL Server.

Utilize o SQL Server Management Studio

Esta seção mostra como criar um Grupo de Disponibilidade com um tipo de cluster externo usando SSMS com o Assistente de Novo Grupo de Disponibilidade.

No SSMS, expanda Always On Alta Disponibilidade, clique com o botão direito do rato em Grupos de Disponibilidadee selecione Assistente para Novo Grupo de Disponibilidade.
Na caixa de diálogo Introdução, selecione Avançar.
No diálogo Especificar Opções de Grupo de Disponibilidade, introduza um nome para o AG e selecione um tipo de cluster de EXTERNAL ou NONE na lista suspensa. Use EXTERNAL quando usar o Pacemaker. Utilize NONE para cenários especializados, como escalamento de leitura. Selecionar a opção para detecção de integridade a nível da base de dados é opcional. Para mais informações sobre esta opção, consulte a opção de failover de deteção de saúde ao nível da base de dados do grupo de disponibilidade. Selecione Avançar.
No diálogo Selecionar Bases de Dados, selecione as bases de dados em que quer participar no AG. Cada base de dados deve ter um backup completo antes de a poderes adicionar a um AG. Selecione Avançar.
Na caixa de diálogo Especificar réplicas, selecione Adicionar réplica.
Na caixa de diálogo Conectar ao Servidor, digite o nome da instância Linux do SQL Server que será a réplica secundária e as credenciais para se conectar. Selecione Conectar.
Repita as duas etapas anteriores para a instância que conterá uma réplica somente de configuração ou outra réplica secundária.
As três instâncias aparecem no diálogo Especificar Réplicas. Se usares um tipo de cluster de Externo, para a réplica secundária que é um verdadeiro secundário, certifica-te de que o Modo de Disponibilidade corresponde ao da réplica primária e que o modo de failover está definido para Externo. Para a réplica apenas de configuração, selecione um modo de disponibilidade apenas de Configuração.

O exemplo a seguir mostra um AG com duas réplicas, um tipo de cluster Externo, e uma réplica apenas de configuração.

O exemplo a seguir mostra um AG com duas réplicas, tipo de cluster Nenhum, e uma réplica apenas de configuração.
Se quiseres alterar as preferências de backup, seleciona o separador Preferências de Backup. Para mais informações sobre preferências de backup com AGs, consulte Configurar backups em réplicas secundárias de um grupo de disponibilidade Always On.
Se usar secundários legíveis ou criar um AG com um cluster tipo None para escala de leitura, pode criar um listener selecionando o separador Listener. Também pode adicionar um listener mais tarde. Para criar um ouvinte, escolha a opção Criar um grupo de disponibilidade e insira um nome, uma porta TCP/IP, e se deve usar um endereço IP DHCP estático ou atribuído automaticamente. Para um AG com um tipo de cluster Nenhum, o IP deve ser estático e ser configurado para coincidir com o endereço IP do primário.
Se criares um ouvinte para cenários legíveis, o SSMS permite a criação do encaminhamento só de leitura no assistente. Também podes adicioná-lo mais tarde via SSMS ou Transact-SQL. Para adicionar roteamento somente leitura agora:
1. Selecione a guia Encaminhamento Read-Only.
2. Insira as URLs para as réplicas somente leitura. Essas URLs são semelhantes aos pontos de extremidade, mas utilizam a porta da instância em vez do ponto de extremidade.
  1. Selecione cada URL e, na parte inferior, selecione as réplicas legíveis. Para selecionar múltiplos, manter Shift pressionado ou arrastar para selecionar.
Selecione Avançar.
Escolha como inicializar as réplicas secundárias. O padrão é usar de semeadura automática, que requer o mesmo caminho em todos os servidores que participam do AG. Podes também solicitar ao assistente que faça um backup, uma cópia e uma restauração (a segunda opção); que o sistema seja associado se fizeste anteriormente o backup, a cópia e a restauração manualmente na base de dados das réplicas (terceira opção); ou adicionar a base de dados mais tarde (última opção). Tal como nos certificados, se estiveres a fazer backups manualmente e a copiá-los, define permissões nos ficheiros de backup das outras réplicas. Selecione Avançar.
No diálogo de Validação, se o assistente não devolver Sucesso em todas as verificações, investigue mais a fundo. Alguns avisos são aceitáveis e não são fatais, como se não criares um ouvinte. Selecione Avançar.
Na caixa de diálogo Resumo, selecione Concluir. Começa agora o processo de criação da AG.
Quando a criação do AG estiver concluída, selecione Fechar nos Resultados. Agora você pode ver o AG nas réplicas nas exibições de gerenciamento dinâmico e na pasta Always On High Availability no SSMS.

Utilize o Transact-SQL

Esta seção mostra exemplos de criação de um AG usando Transact-SQL. Podes configurar o ouvinte e o encaminhamento só de leitura depois de criares o AG. Pode modificar o próprio AG usando ALTER AVAILABILITY GROUP, mas não pode alterar o tipo de cluster no SQL Server 2017 (14.x). Se você não pretendia criar um AG com um tipo de cluster de Externo, deverá excluí-lo e recriá-lo com um tipo de cluster de Nenhum. Para mais informações e outras opções, consulte os seguintes links:

Exemplo A: Duas réplicas com uma réplica somente de configuração (tipo de cluster externo)

Este exemplo mostra como criar um AG de duas réplicas que utiliza uma réplica apenas de configuração.

Execute a seguinte instrução no nó que atua como réplica primária e contém a cópia totalmente lida/escrita das bases de dados. Este exemplo usa a semeadura automática.

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE <DBName>
REPLICA ON
N'LinAGN1' WITH (
   ENDPOINT_URL = N' TCP://LinAGN1.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
N'LinAGN2' WITH (
   ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   SEEDING_MODE = AUTOMATIC
),
N'LinAGN3' WITH (
   ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
   AVAILABILITY_MODE = CONFIGURATION_ONLY
);
GO

Numa janela de consulta ligada à outra réplica, execute a seguinte instrução para ligar a réplica ao AG e iniciar o processo de seed da réplica primária para a secundária.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO
```
Numa janela de consulta ligada à réplica apenas de configuração, execute a seguinte instrução para a ligar ao AG.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
```

Exemplo B: Três réplicas com encaminhamento de leitura somente (tipo de cluster externo)

Este exemplo mostra três réplicas completas e como é que pode configurar o roteamento de leitura apenas como parte da criação inicial do AG.

Execute a seguinte instrução no nó que atua como réplica primária e contém a cópia totalmente lida/escrita das bases de dados. Este exemplo usa a semeadura automática.

CREATE AVAILABILITY GROUP [<AGName>] WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE < DBName > REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN2.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:1433')
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:1433')
    ),
    N'LinAGN3' WITH (
        ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN2.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN3.FullyQualified.Name:1433')
    )
    LISTENER '<ListenerName>' (
        WITH IP = ('<IPAddress>', '<SubnetMask>'), Port = 1433
    );
GO

Algumas coisas a observar sobre essa configuração:

AGName é o nome do AG.
DBName é o nome da base de dados que você utiliza com o AG. Também pode ser uma lista de nomes separados por vírgulas.
ListenerName é um nome que é diferente de qualquer um dos servidores ou nós subjacentes. Está registado no DNS juntamente com IPAddress.
IPAddress é um endereço IP associado a ListenerName. Também é único e não é igual a nenhum dos servidores ou nós. Aplicativos e usuários finais usam ListenerName ou IPAddress para se conectar ao AG.
- SubnetMask é a máscara de sub-rede do IPAddress. No SQL Server 2019 (15.x) e versões anteriores, este valor é 255.255.255.255. No SQL Server 2022 (16.x) e versões posteriores, este valor é 0.0.0.0.

Numa janela de consulta ligada à outra réplica, execute a seguinte instrução para ligar a réplica ao AG e iniciar o processo de seed da réplica primária para a secundária.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO
```
Repita a etapa 2 para a terceira réplica.

Exemplo C: Duas réplicas com roteamento somente leitura (Nenhum tipo de cluster)

Este exemplo mostra a criação de uma configuração de duas réplicas usando um tipo de cluster de None. Use esta configuração para o cenário de read-scale onde não se espera failover. Esta etapa cria o listener que é na verdade a réplica principal e implementa o roteamento de apenas leitura, utilizando a funcionalidade round robin.

Execute a seguinte instrução no nó que atua como réplica primária e contém a cópia com leitura e escrita completas das bases de dados. Este exemplo usa a semeadura automática.

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE)
FOR DATABASE <DBName> REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name: <PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(
            ALLOW_CONNECTIONS = READ_WRITE,
            READ_ONLY_ROUTING_LIST = (('LinAGN1.FullyQualified.Name'.'LinAGN2.FullyQualified.Name'))
        ),
        SECONDARY_ROLE(
            ALLOW_CONNECTIONS = ALL,
            READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:<PortOfInstance>'
        )
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
                 ('LinAGN1.FullyQualified.Name',
                    'LinAGN2.FullyQualified.Name')
                 )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfInstance>')
    ),
    LISTENER '<ListenerName>' (WITH IP = (
             '<PrimaryReplicaIPAddress>',
             '<SubnetMask>'),
            Port = <PortOfListener>
    );
GO

Neste exemplo:

AGName é o nome do AG.
DBName é o nome da base de dados que utiliza com o AG. Também pode ser uma lista de nomes separados por vírgulas.
PortOfEndpoint é o número de porta usado pelo endpoint que crias.
- PortOfInstance é o número da porta usado pela instância do SQL Server.
ListenerName é um nome distinto de qualquer uma das réplicas subjacentes, mas que efetivamente não é utilizado.
PrimaryReplicaIPAddress é o endereço IP da réplica primária.
- SubnetMask é a máscara de sub-rede do IPAddress. No SQL Server 2019 (15.x) e versões anteriores, este valor é 255.255.255.255. No SQL Server 2022 (16.x) e versões posteriores, este valor é 0.0.0.0.

Junte a réplica secundária ao AG e inicie a semeadura automática.

ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = NONE);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO

Um cluster de alta disponibilidade Pacemaker que utiliza SQL Server no Linux precisa de acesso à instância SQL Server e de permissões no próprio AG. Estes passos criam o login e as permissões associadas, juntamente com um ficheiro que indica ao Pacemaker como autenticar-se no SQL Server.

Em uma janela de consulta conectada à primeira réplica, execute o seguinte script:

CREATE LOGIN PMLogin
    WITH PASSWORD = '<password>';
GO

GRANT VIEW SERVER STATE TO PMLogin;
GO

GRANT ALTER, CONTROL, VIEW DEFINITION
ON AVAILABILITY GROUP::<AGThatWasCreated> TO PMLogin;
GO

No Node 1, introduza o comando:
```
sudo emacs /var/opt/mssql/secrets/passwd
```
Este comando abre o editor do Emacs.
Insira as duas linhas a seguir no editor:
```
PMLogin

<password>
```
Mantenha pressionada a tecla Ctrl, pressione Xe, em seguida, C, para sair e salvar o arquivo.

Execute:

sudo chmod 400 /var/opt/mssql/secrets/passwd

para bloquear o ficheiro.

Repita os Passos 1-5 nos outros servidores que servem como réplicas.

Criar os recursos do grupo de disponibilidade no cluster do Pacemaker (somente externo)

Depois de criar um AG no SQL Server, deve criar os recursos correspondentes no Pacemaker ao especificar um tipo de cluster Externo. Um AG necessita de dois recursos: o recurso do grupo de disponibilidade e um recurso de endereço IP. Configurar o recurso do endereço IP é opcional se não estiveres a usar um ouvinte. No entanto, é recomendado quando precisas de funcionalidades de ouvinte.

O recurso AG que crias é um tipo de recurso chamado clone. O recurso AG tem cópias em cada nó e um recurso controlador chamado master. O mestre está associado ao servidor que hospeda a réplica principal. Os outros recursos alojam réplicas secundárias (regulares ou apenas configuração) e podem ser promovidos a mestre em caso de failover.

Pacemaker HA agent v2 (pré-visualização)

No SQL Server 2025 (17.x) com Cumulative Update () 3 e versões posteriores, está disponível um novo agente Pacemaker HA v2 (mssql-server-ha) para Red Hat Enterprise Linux (RHEL) e Ubuntu.

O Pacemaker HA agente v2 introduz melhorias de fiabilidade e desempenho em relação ao agente anterior, incluindo:

Melhoria do desempenho do failover para reduzir os tempos de failover planeados e não planeados.
Suporte para políticas automáticas flexíveis de failover, incluindo a configuração do timeout da verificação de saúde e do nível de condição de falha.
Suporte para TLS 1.3 para comunicação entre o cluster Pacemaker e SQL Server.

O agente Pacemaker HA v2 está atualmente em visualização prévia. O agente Pacemaker HA existente (v1) mantém-se totalmente suportado para implementações em produção.

Red Hat Enterprise Linux (RHEL) e Ubuntu
Servidor SUSE Linux Enterprise (SLES)

Crie o recurso AG no Pacemaker usando o agente HA existente do Pacemaker (v1):
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s promotable notify=true
```
Neste exemplo, NameForAGResource é o nome único que atribui a este recurso de cluster do AG, e AGName é o nome do AG que criou.

Para usar o agente HA do Pacemaker v2, crie o recurso AG usando o agente de recurso agv2:
```
sudo pcs resource create <NameForAGResource> ocf:mssql:agv2 ag_name=<AGName> meta failure-timeout=30s promotable notify=true
```
Novas implementações no SQL Server 2025 (17.x) podem avaliar o agente HA do Pacemaker v2. As implementações de produção existentes devem ser atualizadas quando apropriado.

Ao atualizar ou implementar o agente HA do Pacemaker v2, crie o novo recurso AG usando o agv2 agente em vez do agente anterior ag . Se já configurou um recurso AG existente, remova-o e crie um novo recurso usando agv2:
```
sudo pcs resource delete <NameForAGResource>
```
Esta operação interrompe temporariamente a sincronização do AG enquanto o recurso está a ser recriado. Apagar e recriar o recurso Pacemaker AG não apaga o AG. Depois de o recurso ser recriado, o Pacemaker retoma automaticamente a gestão e a sincronização do AG.
Crie o recurso de endereço IP para o AG que você associa à funcionalidade listener.
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
Neste exemplo, NameForIPResource é o nome único do recurso IP, e IPAddress é o endereço IP estático que atribui ao recurso.
Para garantir que o endereço IP e o recurso AG correm no mesmo nó, configure uma restrição de colocation.
```
sudo pcs constraint colocation add <NameForIPResource> with promoted <NameForAGResource>-clone INFINITY
```
Neste exemplo, NameForIPResource é o nome do recurso IP, e NameForAGResource é o nome do recurso AG.
Crie uma restrição de ordenação para garantir que o recurso AG esteja ativo e funcionando antes do endereço IP. Embora a restrição de colocação implique uma restrição de ordenação, este passo reforça-a.
```
sudo pcs constraint order promote <NameForAGResource>-clone then start <NameForIPResource>
```
Neste exemplo, NameForIPResource é o nome do recurso IP, e NameForAGResource é o nome do recurso AG.

Observação

A partir do SQL Server 2025 (17.x), o SUSE Linux Enterprise Server (SLES) não é suportado.

Crie o recurso AG com a seguinte sintaxe:

primitive <NameForAGResource> \
ocf:mssql:ag \
params ag_name="<AGName>" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Promoted" \
op notify timeout=60s
clone ms-ag_cluster <NameForAGResource> \
meta promoted-max="1" promoted-node-max="1" clone-max="3" \
    promotable="true" clone-node-max="1" notify="true" \
commit

Neste exemplo, NameForAGResource é o nome único que atribui a este recurso de cluster do AG, e AGName é o nome do AG que criou.

Crie o recurso de endereço IP para o AG que você associa à funcionalidade listener.
```
crm configure \
primitive <NameForIPResource> \
   ocf:heartbeat:IPaddr2 \
   params ip=<IPAddress> \
      cidr_netmask=<Netmask>
```
Neste exemplo, NameForIPResource é o nome único do recurso IP, e IPAddress é o endereço IP estático que atribui ao recurso. No sistema SLES, você também precisa fornecer a máscara de rede. Por exemplo, 255.255.255.0 tem um valor de 24 para Netmask.
Para garantir que o endereço IP e o recurso AG correm no mesmo nó, configure uma restrição de colocation.
```
crm configure <NameForConstraint> inf: \
<NameForIPResource> <NameForAGResource>:Promoted
commit
```
Neste exemplo, NameForIPResource é o nome do recurso IP, NameForAGResource é o nome do recurso AG, e NameForConstraint é o nome da restrição.
Crie uma restrição de ordenação para garantir que o recurso AG esteja ativo e funcionando antes do endereço IP. Embora a restrição de colocação implique uma restrição de ordenação, este passo reforça-a.
```
crm configure \
order <NameForConstraint> Mandatory: <NameForAGResource>:promote <NameForIPResource>:start
commit
```
Neste exemplo, NameForIPResource é o nome do recurso IP, NameForAGResource é o nome do recurso AG, e NameForConstraint é o nome da restrição.

Failover de Grupo de Disponibilidade Always On no Linux

Comentários

Esta página foi útil?

Last updated on 2026-03-20