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 documento 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 deve-se ao facto de os agentes de fencing serem específicos da plataforma. Consulte Políticas para Clusters Convidados.

Roteiro

As etapas para criar um AG em servidores Linux para alta disponibilidade são diferentes das etapas em um cluster de failover do Windows Server. A lista a seguir descreve as etapas de alto nível:

  1. Diretrizes de instalação do 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. Destinam-se apenas a 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 várias 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, você precisa:

  • Defina seu ambiente para que todos os servidores que hospedarão réplicas de disponibilidade possam se comunicar.
  • Instale o SQL Server.

No Linux, você deve criar um grupo de disponibilidade antes de adicioná-lo como um recurso de cluster a ser gerenciado pelo cluster. Este documento 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 script a seguir permite que você edite /etc/hostname com vi:

    sudo vi /etc/hostname

  2. Configure o arquivo hosts.

    Observação

    Se os nomes de host estiverem registrados com seu endereço IP no servidor DNS, você não precisará executar as etapas a seguir. 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 arquivo hosts em cada servidor contém os endereços IP e nomes de todos os servidores que participarão do grupo de disponibilidade.

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

    sudo ip addr show

    Atualização /etc/hosts. O script a seguir permite que você edite /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:

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 utiliza certificados para autenticar a comunicação entre os pontos terminais 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 hospedarão 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 valores <node2> pelos nomes das instâncias do SQL Server que hospedarão 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.

Crie os pontos de extremidade de espelhamento de bases de dados em todas as réplicas

Os pontos de extremidade de espelhamento de banco de dados usam o protocolo TCP (Transmission Control Protocol) para enviar e receber mensagens entre as instâncias do servidor que participam de sessões de espelhamento de banco de dados ou réplicas de disponibilidade do host. O ponto de extremidade de espelhamento de bases de dados escuta em um 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. Inicia o endpoint e dá permissão de conexão ao certificado que criou. Antes de executar o script, substitua os valores entre < ... >. Opcionalmente, você pode incluir um endereço IP LISTENER_IP = (0.0.0.0). 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;

A porta TCP no firewall deve estar aberta 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 você cria um AG com o assistente, ele retorna um erro quando você une as réplicas ao AG. Para corrigir isso, conceda ALTER, CONTROLe VIEW DEFINITIONS ao marca-passo no AG em todas as réplicas. Depois que as permissões forem concedidas na réplica primária, junte os nós ao AG por meio do assistente, mas para que o HA funcione corretamente, conceda permissão em 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 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. Utilize 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.

Importante

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 nó for nó1, certifique-se de que SERVERPROPERTY('ServerName') retorna node1 na instância do SQL Server. Se houver uma incompatibilidade, suas réplicas entrarão em um estado de resolução depois que o recurso de marcapasso for criado.

Um cenário em que essa regra é importante é ao usar nomes de domínio totalmente qualificados. Por exemplo, se você usar node1.yourdomain.com como o nome do nó durante a configuração do cluster, certifique-se de que SERVERPROPERTY('ServerName') retorna node1.yourdomain.com, e não apenas node1. As possíveis soluções alternativas para esse problema são:

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

Execute apenas um dos seguintes scripts:

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

Crie o 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 o 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 o 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 requer permissões de ALTER, CONTROLe VIEW DEFINITION no grupo de disponibilidade em todas as réplicas. Para conceder permissões, execute o seguinte script Transact-SQL depois que o grupo de disponibilidade for criado na réplica primária e cada réplica secundária imediatamente após serem adicionadas ao grupo de disponibilidade. Antes de executar o script, substitua <pacemakerLogin> pelo nome da conta de usuário 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;

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

Importante

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 você seguiu as etapas neste documento, você tem um AG que ainda não está clusterizado. A próxima etapa é adicionar o cluster. Esta configuração é válida para cenários de escala de leitura/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.

Comentários

Importante

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. No RHEL ou Ubuntu use pcs. No caso do SLES, use crm.

Importante

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. Isso será corrigido na próxima versão. O failover manual ou automático para uma réplica síncrona é bem-sucedido.

Conteúdo relacionado

  • Last updated on