Partilhar via

Configurar o grupo de disponibilidade do SQL Server para alta disponibilidade no Linux

Aplica-se a:SQL Server em Linux

Este artigo descreve como criar um grupo de disponibilidade Always On (AG) do SQL Server para alta disponibilidade no Linux. Existem dois tipos de configuração para os AGs. Uma configuração de alta disponibilidade usa um gerenciador de cluster para fornecer continuidade de negócios. Essa configuração também pode incluir réplicas em escala de leitura. Este artigo explica como criar o AG para alta disponibilidade.

Você também pode criar um AG sem um gerenciador de cluster para escala de leitura. O AG para escala de leitura fornece apenas réplicas somente leitura para dimensionamento de desempenho. Não oferece alta disponibilidade. Para criar um AG para escala de leitura, consulte Configurar um grupo de disponibilidade do SQL Server para escala de leitura no Linux.

As configurações que garantem alta disponibilidade e proteção de dados exigem duas ou três réplicas de confirmação síncronas. Com três réplicas síncronas, o AG pode se recuperar automaticamente mesmo que um servidor não esteja disponível. Para obter mais informações, consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Todos os servidores devem ser físicos ou virtuais, e os servidores virtuais devem estar na mesma plataforma de virtualização. Este requisito existe porque os agentes de vedação são específicos para a plataforma. Consulte Políticas para Clusters Convidados.

Etapas de instalação

As etapas para criar um Grupo de Disponibilidade (AG) em servidores Linux para alta disponibilidade diferem das etapas num cluster de failover do Windows Server. A lista a seguir descreve as etapas de alto nível:

  1. Diretrizes de instalação para SQL Server no Linux.

    Importante

    Todos os três servidores no AG precisam estar na mesma plataforma - física ou virtual - porque a alta disponibilidade do Linux usa agentes de vedação para isolar recursos em servidores. Os agentes de esgrima são específicos para cada plataforma.

  2. Crie o AG. Esta etapa é abordada neste artigo atual.

  3. Configure um gerenciador de recursos de cluster, como o Pacemaker.

    A maneira de configurar um gerenciador de recursos de cluster depende da distribuição Linux específica. Consulte os seguintes links para obter instruções específicas de distribuição:

    Importante

    Os ambientes de produção exigem um agente de vedação para alta disponibilidade. Os exemplos neste artigo não utilizam agentes de proteção. São apenas para testes e validação.

    Um cluster de Pacemaker usa fencing para retornar o cluster a um estado conhecido. A maneira de configurar a vedação depende da distribuição e do ambiente. Atualmente, a esgrima não está disponível em alguns ambientes de nuvem. Para obter mais informações, consulte Políticas de suporte para clusters de alta disponibilidade RHEL - Plataformas de virtualização.

    Para SLES, consulte SUSE Linux Enterprise High Availability Extension.

  4. Adicione o AG como um recurso no cluster.

    A maneira de adicionar o AG como um recurso no cluster depende da distribuição Linux. Consulte os seguintes links para obter instruções específicas de distribuição:

Considerações para múltiplas interfaces de rede (NICs)

Para obter informações sobre como configurar um grupo de disponibilidade para servidores com várias NICs, consulte as seções relevantes para:

Pré-requisitos

Antes de criar o grupo de disponibilidade, complete os seguintes passos:

  • Configura o teu ambiente para que todos os servidores que alojam réplicas de disponibilidade possam comunicar.
  • Instale o SQL Server.

No Linux, deve criar um grupo de disponibilidade antes de o adicionar como recurso de cluster, para que o cluster possa geri-lo. Este artigo fornece um exemplo que cria o grupo de disponibilidade.

  1. Atualize o nome do computador para cada host.

    Cada nome de instância do SQL Server deve ser:

    • 15 caracteres ou menos.
    • Único dentro da rede.

    Para definir o nome do computador, edite/etc/hostname. O exemplo seguinte mostra como editar /etc/hostname com vi:

    sudo vi /etc/hostname

  2. Configure o ficheiro hosts.

    Observação

    Se o servidor DNS registar nomes de host com os seus endereços IP, não precisa de completar os passos seguintes. Valide se todos os nós destinados a fazer parte da configuração do grupo de disponibilidade podem se comunicar entre si. (Um ping para o nome do anfitrião deve responder com o endereço IP correspondente.) Além disso, certifique-se de que o arquivo /etc/hosts não contém um registo que mapeia o endereço IP 127.0.0.1 do localhost com o nome do anfitrião do nó.

    O ficheiro hosts em cada servidor contém os endereços IP e nomes de todos os servidores que participam no grupo de disponibilidade.

    O comando a seguir retorna o endereço IP do servidor atual:

    sudo ip addr show

    Atualização /etc/hosts. O exemplo seguinte mostra como editar /etc/hosts com vi:

    sudo vi /etc/hosts

    O exemplo a seguir mostra /etc/hosts em node1 com adições para node1, node2e node3. Neste exemplo, node1 refere-se ao servidor que hospeda a réplica primária e node2 e node3 referem-se aos servidores que hospedam as réplicas secundárias.

    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

Instalar o SQL Server

Instale o SQL Server. Os links a seguir apontam para instruções de instalação do SQL Server para várias distribuições:

Observação

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

Ativar os grupos de disponibilidade Always On

Habilite os grupos de disponibilidade Always On para cada nó que aloja uma instância do SQL Server e, em seguida, reinicie mssql-server. Execute o seguinte script:

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

Ativar uma sessão de evento AlwaysOn_health

Opcionalmente, você pode habilitar os Eventos Estendidos (XE) para ajudar com o diagnóstico de causa básica ao solucionar problemas de um grupo de disponibilidade. Execute o seguinte comando em cada instância do SQL Server:

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

Para obter mais informações sobre esta sessão XE, consulte Configurar eventos estendidos para grupos de disponibilidade.

Criar um certificado

O serviço SQL Server no Linux usa certificados para autenticar a comunicação entre os endpoints de espelhamento.

O script Transact-SQL a seguir cria uma chave mestra e um certificado. Em seguida, ele faz backup do certificado e protege o arquivo com uma chave privada. Atualize o script com senhas fortes. Conecte-se à instância primária do SQL Server. Para criar o certificado, execute o seguinte script Transact-SQL:

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>'
);

Neste ponto, sua réplica primária do SQL Server tem um certificado em /var/opt/mssql/data/dbm_certificate.cer e uma chave privada em /var/opt/mssql/data/dbm_certificate.pvk. Copie esses dois arquivos para o mesmo local em todos os servidores que hospedam réplicas de disponibilidade. Use o usuário mssql ou dê permissão ao usuário mssql para acessar esses arquivos.

Por exemplo, no servidor de origem, o comando a seguir copia os arquivos para a máquina de destino. Substitua os <node2> valores pelos nomes das instâncias do SQL Server que alojam as réplicas.

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

Em cada servidor de destino, dê permissão ao usuário mssql para acessar o certificado.

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

Criar o certificado em servidores secundários

O script Transact-SQL a seguir cria uma chave mestra e um certificado do backup que você criou na réplica primária do SQL Server. Atualize o script com senhas fortes. A palavra-passe de desencriptação é a mesma palavra-passe que usou para criar o ficheiro .pvk num passo anterior. Para criar o certificado, execute o seguinte script em todos os servidores secundários:

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>'
);

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

Criar os endpoints de espelhamento da base de dados em todas as réplicas

Os endpoints de espelhamento de bases de dados utilizam o protocolo TCP (Transmission Control Protocol) para enviar e receber mensagens entre as instâncias do servidor que participam nas sessões de espelhamento de bases de dados ou nas réplicas de disponibilidade do host. O ponto de extremidade de espelhamento da base de dados escuta num número de porta TCP único.

O script Transact-SQL a seguir cria um ponto de escuta chamado Hadr_endpoint para o grupo de disponibilidade. Ele inicia o endpoint e dá permissão de conexão ao certificado que criaste. Antes de executar o script, substitua os valores entre < ... >. Opcionalmente, pode incluir um endereço LISTENER_IP = (0.0.0.0)IP . O endereço IP do ouvinte deve ser um endereço IPv4. Você também pode usar 0.0.0.0.

Atualize o seguinte script de Transact-SQL para seu ambiente em todas as instâncias do SQL Server:

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;

Observação

Se você usar o SQL Server Express edition em um nó para hospedar uma réplica somente de configuração, o único valor válido para ROLE será WITNESS. Execute o seguinte script no 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;

Tens de abrir a porta TCP no firewall para a porta do ouvinte.

Importante

O único método de autenticação suportado para o endpoint de espelhamento de base de dados é CERTIFICATE. A opção WINDOWS não está disponível.

Para obter mais informações, consulte O ponto de extremidade de espelhamento de banco de dados (SQL Server).

Criar a AG

Os exemplos nesta seção explicam como criar o grupo de disponibilidade usando o Transact-SQL. Você também pode usar o Assistente de Grupo de Disponibilidade do SQL Server Management Studio. Quando crias um AG usando o assistente, ele devolve um erro quando juntas as réplicas ao AG. Para corrigir este erro, conceda ALTER, CONTROL, e VIEW DEFINITIONS ao marcapasso na AG em todas as réplicas. Depois de concederes permissões à réplica primária, junta os nós ao AG através do assistente, mas para o HA funcionar corretamente, concede permissão a todas as réplicas.

Para uma configuração de alta disponibilidade que garante failover automático, o AG requer pelo menos três réplicas. Qualquer uma das seguintes configurações pode oferecer suporte à alta disponibilidade:

Para obter mais informações, consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Observação

Os grupos de disponibilidade podem incluir réplicas síncronas ou assíncronas adicionais.

Crie o AG (Grupo de Disponibilidade) para alta disponibilidade no Linux. Use a instrução CREATE AVAILABILITY GROUP com CLUSTER_TYPE = EXTERNAL.

  • Grupo de disponibilidade: CLUSTER_TYPE = EXTERNAL.

    Especifica que uma entidade de cluster externa gerencia o AG. O Pacemaker é um exemplo de uma entidade de cluster externa. Quando o tipo de cluster AG é externo,

  • Definir réplicas primárias e secundárias: FAILOVER_MODE = EXTERNAL.

    Especifica que a réplica interage com um gerenciador de cluster externo, como o Pacemaker.

Os scripts de Transact-SQL a seguir criam um AG para alta disponibilidade chamado ag1. O script configura as réplicas AG com SEEDING_MODE = AUTOMATIC. Essa configuração faz com que o SQL Server crie automaticamente o banco de dados em cada servidor secundário. Atualize o script a seguir para seu ambiente. Substitua os valores <node1>, <node2>ou <node3> pelos nomes das instâncias do SQL Server que hospedam as réplicas. Substitua o <5022> pela porta definida para o terminal de espelhamento de dados. Para criar o AG, execute o seguinte Transact-SQL na instância do SQL Server que hospeda a réplica primária.

Execute apenas um dos seguintes scripts:

Associe o nome do nó à propriedade ServerName

Na implementação atual do agente de recursos do SQL Server, o nome do nó deve corresponder à propriedade ServerName da sua instância. Por exemplo, se o nome do seu nó for node1, certifique-se de que SERVERPROPERTY('ServerName') retorne node1 na sua instância do SQL Server. Se houver uma incompatibilidade, as suas réplicas entram num estado de resolução após a criação do recurso Pacemaker.

Esta regra é importante quando utilizas nomes de domínio totalmente qualificados. Por exemplo, se usar node1.yourdomain.com como nome do nó durante a configuração do cluster, certifique-se de que SERVERPROPERTY('ServerName') retorne node1.yourdomain.com, e não apenas node1. Para resolver este problema, pode:

  • Renomeie o nome do seu anfitrião para o FQDN e use os procedimentos armazenados sp_dropserver e sp_addserver para garantir que os metadados do SQL Server correspondem à alteração.
  • Use a opção addr no comando pcs cluster auth para corresponder o nome do nó ao valor SERVERPROPERTY('ServerName') e utilizar um IP estático como endereço do nó.

Criar grupo de disponibilidade com três réplicas síncronas

Crie um AG com três réplicas síncronas:

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
      FOR REPLICA ON
         N'<node1>'
               WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node2>'
         WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node3>'
         WITH(
            ENDPOINT_URL = N'tcp://<node3>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Importante

Depois de executar o script anterior para criar um AG com três réplicas síncronas, não execute o seguinte script:

Criar grupo de disponibilidade com duas réplicas síncronas e uma réplica de configuração

Crie um AG com duas réplicas síncronas e uma réplica de configuração:

Importante

Essa arquitetura permite que qualquer edição do SQL Server hospede a terceira réplica. Por exemplo, a terceira réplica pode ser hospedada no SQL Server Express Edition. No Express Edition, o único tipo de ponto de extremidade válido é WITNESS.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
      N'<node1>' WITH (
         ENDPOINT_URL = N'tcp://<node1>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node2>' WITH (
         ENDPOINT_URL = N'tcp://<node2>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node3>' WITH (
         ENDPOINT_URL = N'tcp://<node3>:<5022>',
         AVAILABILITY_MODE = CONFIGURATION_ONLY
         );
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Criar grupo de disponibilidade com duas réplicas síncronas

Crie um AG com duas réplicas síncronas.

Inclua duas réplicas em modo de disponibilidade síncrona. Por exemplo, o script a seguir cria um AG chamado ag1. node1 e node2 hospedam réplicas no modo síncrono, com semeadura automática e failover automático.

Importante

Execute apenas o script a seguir para criar um AG com duas réplicas síncronas. Não execute o script a seguir se você executou um script anterior.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
   N'node1' WITH (
      ENDPOINT_URL = N'tcp://node1:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   ),
   N'node2' WITH (
      ENDPOINT_URL = N'tcp://node2:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Você também pode configurar um AG com CLUSTER_TYPE=EXTERNAL usando o SQL Server Management Studio ou o PowerShell.

Adicione réplicas secundárias ao Grupo de Disponibilidade

O utilizador do Pacemaker precisa de ALTER, CONTROL e VIEW DEFINITION permissões no grupo de disponibilidade de todas as réplicas. Para conceder estas permissões, execute o seguinte script de Transact-SQL após criar o grupo de disponibilidade na réplica primária. Execute o script em cada réplica secundária imediatamente após as adicionar ao grupo de disponibilidade. Antes de executar o script, substitua <pacemakerLogin> pelo nome da conta de utilizador do Pacemaker. Se você não tiver um login para o Pacemaker, crie um login do SQL Server para o Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

O script Transact-SQL a seguir une uma instância do SQL Server a um AG chamado ag1. Atualize o script para o seu ambiente. Em cada instância do SQL Server que hospeda uma réplica secundária, execute o seguinte Transact-SQL para associar-se ao AG.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Observação

Para uma réplica de configuração, apenas é necessário o passo de junção.

Adicionar um banco de dados ao grupo de disponibilidade

Verifique se o banco de dados adicionado ao grupo de disponibilidade está no modelo de recuperação completa e tem um backup de log válido. Se o banco de dados for um banco de dados de teste ou um banco de dados recém-criado, faça um backup de banco de dados. No SQL Server primário, execute o seguinte script Transact-SQL (T-SQL) para criar e fazer backup de um banco de dados chamado db1:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';

Na réplica primária do SQL Server, execute o seguinte script T-SQL para adicionar um banco de dados chamado db1 a um grupo de disponibilidade chamado ag1:

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

Verifique se o banco de dados foi criado nos servidores secundários

Em cada réplica secundária do SQL Server, execute a seguinte consulta para ver se o banco de dados db1 foi criado e está sincronizado:

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;
GO

Depois de criar o AG, você deve configurar a integração com uma tecnologia de cluster como o Pacemaker para alta disponibilidade. Para uma configuração de escala de leitura usando AGs, a partir do SQL Server 2017 (14.x), não é necessário configurar um cluster.

Se seguiu os passos deste artigo, tem um AG que ainda não está agrupado. A próxima etapa é adicionar o cluster. Esta configuração é válida para escalabilidade de leitura e balanceamento de carga, mas não é suficiente para garantir alta disponibilidade. Para alta disponibilidade, você precisa adicionar o AG como um recurso de cluster. Consulte conteúdo relacionado para obter instruções.

Observações

Depois de configurar o cluster e adicionar o AG como um recurso de cluster, você não pode usar Transact-SQL para fazer failover dos recursos AG. Os recursos de cluster do SQL Server no Linux não são acoplados tão fortemente ao sistema operacional quanto em um WSFC (Cluster de Failover do Windows Server). O serviço SQL Server não está ciente da presença do cluster. Toda a orquestração é feita através das ferramentas de gerenciamento de cluster. Em RHEL ou Ubuntu, use pcs. Em SLES, usa crm.

Se o AG for um recurso de cluster, há um problema conhecido na versão atual em que o failover forçado com perda de dados para uma réplica assíncrona não funciona. Este problema será corrigido numa próxima edição. O failover manual ou automático para uma réplica síncrona é bem-sucedido.

Conteúdo relacionado

  • Last updated on