Compartilhar via

Criar e configurar um grupo de disponibilidade para SQL Server em Linux

  • Artigo

Aplica-se a: SQL Server – Linux

Este tutorial aborda como criar e configurar um AG (grupo de disponibilidade) para SQL Server no Linux. Ao contrário do SQL Server 2016 (13.x) e anteriores no Windows, você pode habilitar um AG tendo ou não criado anteriormente um cluster do Pacemaker subjacente. A integração com o cluster, se necessária, só será feita mais tarde.

O tutorial inclui as seguintes tarefas:

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

Pré-requisitos

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

Habilitar o recurso grupos de disponibilidade

Ao contrário do Windows, você não pode usar o PowerShell nem o SQL Server Configuration Manager para habilitar o recurso de AG (grupos de disponibilidade). No Linux, você deve usar o mssql-conf para habilitar o recurso. Há duas maneiras de habilitar o recurso de grupos de disponibilidade: usar o utilitário mssql-conf ou editar o arquivo mssql.conf manualmente.

Importante

O recurso AG deve ser habilitado para réplicas somente de configuração, mesmo em SQL Server Express.

Usar o utilitário mssql-conf

Em um prompt, emita o seguinte comando:

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

Editar o arquivo mssql.conf

Você também pode modificar o arquivo mssql.conf, localizado sob a pasta /var/opt/mssql, para adicionar as seguintes linhas:

[hadr]

hadr.hadrenabled = 1

Reinicie o SQL Server

Depois de habilitar grupos de disponibilidade, como acontece no Windows, você deve reiniciar o SQL Server usando o seguinte comando:

sudo systemctl restart mssql-server

Criar os pontos de extremidade do grupo de disponibilidade e certificados

Um grupo de disponibilidade usa pontos de extremidade TCP para comunicação. No Linux, os pontos de extremidade para um AG só terão suporte se os certificados forem usados para autenticação. Você precisa restaurar o certificado de uma instância em todas as outras instâncias que participarão como réplicas do mesmo AG. O processo de certificado é necessário até mesmo para uma réplica somente de configuração.

A criação de pontos de extremidade e a restauração de certificados só podem ser feitas por meio do Transact-SQL. Você também pode usar certificados não gerados pelo SQL Server. Você também precisará de um processo para gerenciar e substituir todos os certificados que expirarem.

Importante

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

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

Observação

Embora você esteja criando um grupo de disponibilidade, o tipo de ponto de extremidade usa FOR DATABASE_MIRRORING, porque alguns aspectos subjacentes antes eram compartilhados com esse recurso agora preterido.

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

  1. Execute o seguinte script no LinAGN1 para criar a chave mestra, o certificado e o ponto de extremidade, e para fazer backup do certificado. Para este exemplo, a porta TCP típica 5022 é usada para o ponto de extremidade.

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
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

  2. Faça o mesmo no LinAGN2:

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
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

  3. Por fim, execute a mesma sequência no LinAGN3:

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
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

  4. Usando scp o ou outro utilitário, copie os backups do certificado para cada nó que fará parte do 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.

  5. Altere a propriedade e o grupo associado aos arquivos de certificado copiados para o mssql.

    sudo chown mssql:mssql <CertFileName>

  6. Crie os logons e os usuário associados a LinAGN2 e LinAGN3 no LinAGN1 no nível da instância.

    CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

  7. Restaure LinAGN2_Cert e LinAGN3_Cert no LinAGN1. Ter os certificados de outras réplicas é um aspecto importante da comunicação e da segurança do 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

  8. Conceda aos logons associados a LinAG2 e LinAGN3 permissão para se conectarem ao ponto de extremidade no LinAGN1.

    GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO

  9. Crie os logons e os usuário associados a LinAGN1 e LinAGN3 no LinAGN2 no nível da instância.

    CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

  10. 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

  11. Conceda aos logons associados a LinAG1 e LinAGN3 permissão para se conectarem ao ponto de extremidade no LinAGN2.

    GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO

  12. Crie os logons e os usuário associados a LinAGN1 e LinAGN2 no LinAGN3 no nível da instância.

    CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

  13. 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

  14. Conceda aos logons associados a LinAG1 e LinAGN2 permissão para se conectarem ao ponto de extremidade no LinAGN3.

    GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO

Crie o grupo de disponibilidade

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

Use SQL Server Management Studio.

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

  1. No SSMS, expanda Alta Disponibilidade Always On, clique com o botão direito do mouse em Grupos de Disponibilidade e selecione Assistente de Novo Grupo de Disponibilidade.

  2. No diálogo Introdução, selecione Avançar.

  3. Na caixa de diálogo Especificar Opções do Grupo de Disponibilidade, insira um nome para o grupo de disponibilidade e selecione um tipo de cluster EXTERNAL ou NONE no menu suspenso. Externo deve ser usado quando o Pacemaker for ser implantado. Nenhum é para cenários especializados, como expansão de leitura. A seleção da opção de detecção de integridade no nível do banco de dados é opcional. Para obter mais informações sobre essa opção, confira Opção de failover de detecção de integridade no nível do banco de dados do grupo de disponibilidade. Selecione Avançar.

    Captura de tela de Criar Grupo de Disponibilidade mostrando o tipo de cluster.

  4. Na caixa de diálogo Selecionar Bancos de Dados, selecione os bancos de dados que participarão do AG. Cada banco de dados deve ter um backup completo antes que possa ser adicionado a um AG. Selecione Avançar.

  5. No diálogo Especificar Réplicas, selecione Adicionar Réplica.

  6. Na caixa de diálogo Conectar-se ao Servidor, digite o nome da instância do Linux SQL Server que será a réplica secundária e as credenciais para conectar-se. Selecione Conectar.

  7. Repita as duas etapas anteriores para a instância que conterá uma réplica somente de configuração ou outra réplica secundária.

  8. Agora, todas as três instâncias devem ser listadas na caixa de diálogo Especificar Réplicas. Se estiver usando um tipo de cluster Externo, para a réplica secundária que será verdadeiramente secundária, verifique se o Modo de Disponibilidade corresponde ao da réplica primária e o modo de failover está definido como Externo. Para a réplica somente de configuração, selecione um modo de disponibilidade somente de Configuração.

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

    Captura de tela de Criar Grupo de Disponibilidade mostrando a opção secundária para leitura.

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

    Captura de tela de Criar Grupo de Disponibilidade mostrando a página Réplicas.

  9. Se você quiser alterar as preferências de backup, selecione a guia Preferências de Backup. Para obter mais informações sobre preferências de backup com AGs, consulte Configurar backups nas réplicas secundárias de um grupo de disponibilidade Always On.

  10. Se estiver usando secundários legíveis ou criando um AG com um tipo de cluster de Nenhum para escala de leitura, você poderá criar um ouvinte selecionando a guia Ouvinte. Um ouvinte também pode ser adicionado posteriormente. Para criar um ouvinte, escolha a opção Criar um ouvinte de grupo de disponibilidade e insira um nome, uma porta TCP/IP e se deseja usar um endereço IP DHCP atribuído automaticamente ou estático. Lembre-se de que, para um AG com um tipo de cluster de Nenhum, o IP deve ser estático e definido como o endereço IP do primário.

    Captura de tela de Criar Grupo de Disponibilidade mostrando a opção de ouvinte.

  11. Se um ouvinte for criado para cenários legíveis, o SSMS 17.3 ou posterior permitirá a criação do roteamento somente leitura no assistente. Ele também pode ser adicionado posteriormente por meio de SSMS ou Transact-SQL. Para adicionar o roteamento somente leitura agora:

    1. Selecione a guia Roteamento Somente Leitura.

    2. Insira as URLs para as réplicas somente leitura. Essas URLs são semelhantes aos pontos de extremidade, exceto pelo fato de usarem a porta da instância, e não o ponto de extremidade.

    3. Selecione cada URL e, na parte inferior, selecione as réplicas legíveis. Para seleção múltipla, mantenha pressionada a tecla SHIFT ou selecione e arraste.

  12. Selecione Avançar.

  13. Escolha como as réplicas secundárias serão inicializadas. O padrão é usar a propagação automática, que requer o mesmo caminho em todos os servidores que participam do AG. Você também usar o assistente para fazer uma cópia de backup e restauração (a segunda opção); ingressar, se você tiver feito manualmente o backup, a cópia e a restauração do banco de dados nas réplicas (terceira opção), ou adicionar o banco de dados mais tarde (última opção). Assim como ocorre com os certificados, se você estiver fazendo backups e copiando-os manualmente, as permissões nos arquivos de backup precisarão ser definidas em outras réplicas. Selecione Avançar.

  14. Na caixa de diálogo Validação, se tudo não for retornado como Sucesso, investigue. Alguns avisos são aceitáveis e não fatais, como se você não criar um ouvinte. Selecione Avançar.

  15. No diálogo Resumo, selecione Concluir. O processo de criação do AG começa agora.

  16. Quando a criação do AG for concluída, selecione Fechar nos Resultados. Agora, você pode ver o AG nas réplicas nas exibições de gerenciamento dinâmico e também na pasta Alta Disponibilidade Always On no SSMS.

Usar o Transact-SQL

Esta seção mostra exemplos de como criar um AG usando o Transact-SQL. O ouvinte e o roteamento somente leitura podem ser configurados após a criação do AG. O AG em si pode ser modificado com ALTER AVAILABILITY GROUP, mas não é possível alterar o tipo de cluster no SQL Server 2017 (14.x). Se você não pretender criar um AG com um tipo de cluster Externo, deverá excluí-lo e recriá-lo com um tipo de cluster Nenhum. Mais informações e outras opções podem ser encontradas nos seguintes links:

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

Esse exemplo mostra como criar um AG de duas réplicas que usa uma réplica somente de configuração.

  1. Execute no nó que será a réplica primária que contém a cópia completa de leitura/gravação dos bancos de dados. Este exemplo usa propagação 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

  2. Em uma janela de consulta conectada à outra réplica, execute o seguinte para unir a réplica ao AG e iniciar o processo de propagação 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

  3. Em uma janela de consulta conectada à réplica somente de configuração, ingresse-a no AG.

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

Exemplo B: três réplicas com roteamento somente leitura (tipo de cluster Externo)

Este exemplo mostra três réplicas completas e como o roteamento somente leitura pode ser configurado como parte da criação inicial do AG.

  1. Execute no nó que será a réplica primária que contém a cópia completa de leitura/gravação dos bancos de dados. Este exemplo usa propagação 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

    Alguns pontos a serem observados sobre essa configuração:

    • AGName é o nome do grupo de disponibilidade.
    • DBName é o nome do banco de dados que é usado com o grupo de disponibilidade. Também pode ser uma lista de nomes separados por vírgulas.
    • ListenerName é um nome diferente de todos os nomes de servidores/nós subjacentes. Ele será registrado no DNS junto com o IPAddress.
    • IPAddress é um endereço IP associado ao ListenerName. É também exclusivo e não é igual ao de nenhum dos servidores/nós. Aplicativos e usuários finais usarão ListenerName ou IPAddress para se conectarem ao AG.
    • SubnetMask é a máscara de sub-rede do IPAddress. No SQL Server 2019 (15.x) e versões anteriores, isso é 255.255.255.255. No SQL Server 2022 (16.x) e versões posteriores, isso é 0.0.0.0.

  2. Em uma janela de consulta conectada à outra réplica, execute o seguinte para unir a réplica ao AG e iniciar o processo de propagação 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

  3. Repita a Etapa 2 para a terceira réplica.

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

Este exemplo mostra a criação de uma configuração de duas réplicas usando um tipo de cluster Nenhum. Ele é usado para o cenário de escala de leitura em que não é esperado nenhum failover. Isso cria o ouvinte que é, na verdade, a réplica primária, e o roteamento somente leitura usando a funcionalidade de distribuição uniforme.

  1. Execute no nó que será a réplica primária que contém a cópia completa de leitura/gravação dos bancos de dados. Este exemplo usa propagação 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

Onde:

  • AGName é o nome do grupo de disponibilidade.
  • DBName é o nome do banco de dados que será usado com o grupo de disponibilidade. Também pode ser uma lista de nomes separados por vírgulas.
  • PortOfEndpoint é o número da porta usada pelo ponto de extremidade criado.
  • PortOfInstance é o número da porta usada pela instância do SQL Server.
  • ListenerName é um nome diferente de todos os nomes de réplicas subjacentes, mas que não é realmente usado.
  • 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, isso é 255.255.255.255. No SQL Server 2022 (16.x) e versões posteriores, isso é 0.0.0.0.

  1. Ingresse a réplica secundária no AG e inicie a propagação automática.

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

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

Criar o logon SQL Server e as permissões para o Pacemaker

Um cluster de alta disponibilidade do Pacemaker subjacente ao SQL Server no Linux precisa de acesso à instância do SQL Server e de permissões no próprio grupo de disponibilidade. Essas etapas criam o logon e as permissões associadas, juntamente com um arquivo que informa ao Pacemaker como fazer logon no SQL Server.

  1. Em um período de consulta conectado à primeira réplica, execute o seguinte script:

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

GRANT VIEW SERVER STATE TO PMLogin;
GO

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

  2. No Nó 1, insira o comando

    sudo emacs /var/opt/mssql/secrets/passwd

    Isso abre o editor Emacs.

  3. Insira as duas linhas a seguir no editor:

    PMLogin

<StrongPassword>

  4. Mantenha pressionada a tecla Ctrl e, em seguida, pressione X e depois C para sair e salvar o arquivo.

  5. Execute (executar)

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

    para bloquear o arquivo.

  6. Repita as Etapas 1-5 nos outros servidores que funcionarão como réplicas.

Crie os recursos do grupo de disponibilidade em um cluster do Pacemaker (somente tipo Externo)

Depois que um grupo de disponibilidade foi criado no SQL Server, os recursos correspondentes devem ser criados no Pacemaker quando um tipo de cluster Externo é especificado. Há dois recursos associados a um AG: o AG em si e um endereço IP. A configuração do recurso de endereço IP é opcional se você não estiver usando a funcionalidade de ouvinte, mas é recomendada.

O recurso de AG que você criou é um tipo especial de recurso chamado de clone. Basicamente, o recurso de AG tem cópias em cada nó e existe um recurso de controle chamado mestre. O mestre está associado ao servidor que hospeda a réplica primária. Os outros recursos hospedam réplicas secundárias (regulares ou somente de configuração) e podem ser promovidos para mestre em um failover.

Observação

Comunicação livre de desvio

Este artigo contém referências ao termo subordinado, um termo que a Microsoft considera ofensivo quando usado neste contexto. O termo aparece neste artigo porque ele atualmente aparece no software. Quando o termo for removido do software, também o removeremos do artigo.

  1. Crie o recurso do AG com a seguinte sintaxe:

    sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s --master meta notify=true

    Em que NameForAGResource é o nome exclusivo fornecido a esse recurso de cluster para o AG e AGName é o nome do AG que foi criado.

    No RHEL 7.7 e no Ubuntu 18.04 e versões posteriores, você pode encontrar um aviso com o uso de --master ou um erro como sqlag_monitor_0 on ag1 'not configured' (6): call=6, status=complete, exitreason='Resource must be configured with notify=true'. Para evitar essa situação, use:

    sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s master notify=true

  2. Crie o recurso de endereço IP para o AG que será associado à funcionalidade de ouvinte.

    sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>

    Em que NameForIPResource é o nome exclusivo do recurso de IP e IPAddress é o endereço IP estático atribuído ao recurso.

  3. Para garantir que o endereço IP e o recurso do AG estejam em execução no mesmo nó, uma restrição de colocalização deve ser configurada.

    sudo pcs constraint colocation add <NameForIPResource> <NameForAGResource>-master INFINITY with-rsc-role=Master

    Em que NameForIPResource é o nome do recurso de IP e NameForAGResource é o nome do recurso de AG.

  4. Crie uma restrição de ordenação para garantir que o recurso AG esteja em funcionamento antes do endereço IP. Enquanto a restrição de colocalização implica uma restrição de ordenação, isso a impõe.

    sudo pcs constraint order promote <NameForAGResource>-master then start <NameForIPResource>

    Em que NameForIPResource é o nome do recurso de IP e NameForAGResource é o nome do recurso de AG.

Próxima etapa

Neste tutorial, você aprendeu a criar e configurar um grupo de disponibilidade para SQL Server no Linux. Você aprendeu a:

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

Para a maioria das tarefas de administração do AG, incluindo atualizações e failover, confira:

Operar um grupo de HA para o SQL Server em Linux