Partilhar via

Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade

Aplica-se a:SQL Server em Linux

Este artigo apresenta configurações de implantação com suporte para grupos de disponibilidade Always On do SQL Server em servidores Linux. Um grupo de disponibilidade suporta alta disponibilidade e proteção de dados. A deteção automática de falhas, o failover automático e a reconexão transparente após o failover fornecem alta disponibilidade. Réplicas sincronizadas fornecem proteção de dados.

Em um WSFC (Cluster de Failover do Windows Server), uma configuração comum para alta disponibilidade usa duas réplicas síncronas e um terceiro servidor ou compartilhamento de arquivos para fornecer quórum. A testemunha de compartilhamento de arquivos valida a configuração do grupo de disponibilidade - status de sincronização e a função da réplica, por exemplo. Essa configuração garante que a réplica secundária escolhida como destino de failover tenha as alterações mais recentes na configuração do grupo de dados e disponibilidade.

O WSFC sincroniza metadados de configuração para arbitragem de failover entre as réplicas do grupo de disponibilidade e a testemunha de compartilhamento de arquivos. Quando um grupo de disponibilidade não está em um WSFC, as instâncias do SQL Server armazenam metadados de configuração no master banco de dados.

Por exemplo, um grupo de disponibilidade em um cluster Linux tem CLUSTER_TYPE = EXTERNAL. Não há WSFC para arbitrar failover. Nesse caso, os metadados de configuração são gerenciados e mantidos pelas instâncias do SQL Server. Como não há nenhum servidor testemunha nesse cluster, uma terceira instância do SQL Server é necessária para armazenar metadados do estado de configuração. Todas as três instâncias do SQL Server juntas fornecem armazenamento de metadados distribuídos para o cluster.

O gerenciador de cluster pode consultar as instâncias do SQL Server no grupo de disponibilidade e orquestrar o failover para manter a alta disponibilidade. Em um cluster Linux, o Pacemaker é o gerenciador de cluster.

A partir do SQL Server 2017 (14.x), CU 1, a alta disponibilidade para um grupo de disponibilidade com CLUSTER_TYPE = EXTERNAL está habilitada com duas réplicas síncronas, além de uma réplica somente de configuração. A réplica somente de configuração pode ser hospedada em qualquer edição do SQL Server 2017 (14.x) 1 ou versões posteriores (incluindo a edição SQL Server Express). A réplica de configuração apenas mantém informações de configuração sobre o grupo de disponibilidade no banco de dados, master mas não contém os bancos de dados de usuário no grupo de disponibilidade.

Como a configuração afeta as configurações de recursos padrão

A REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT configuração de recurso de cluster garante que o número especificado de réplicas secundárias grave dados de transação no log antes que a réplica primária confirme cada transação. Quando você usa um gerenciador de cluster externo, essa configuração afeta a alta disponibilidade e a proteção de dados. O valor padrão para a configuração depende da arquitetura no momento em que o recurso de cluster é criado. Quando você instala o agente de recursos do SQL Server - mssql-server-ha - e cria um recurso de cluster para o grupo de disponibilidade, o gerenciador de cluster deteta a configuração do grupo de disponibilidade e define REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT de acordo.

Se suportado pela configuração, o parâmetro REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT resource agent é definido como o valor que fornece alta disponibilidade e proteção de dados. Para obter mais informações, consulte Compreender o agente de recursos do SQL Server para marcapasso.

As seções a seguir explicam o comportamento padrão para o recurso de cluster.

Escolha um design de grupo de disponibilidade para atender aos requisitos de negócios específicos de alta disponibilidade, proteção de dados e escala de leitura.

As configurações a seguir descrevem os padrões de design do grupo de disponibilidade e os recursos de cada padrão. Esses padrões de design se aplicam a grupos de disponibilidade com CLUSTER_TYPE = EXTERNAL soluções de alta disponibilidade.

  • Três réplicas síncronas
  • Duas réplicas síncronas
  • Duas réplicas síncronas e uma réplica somente de configuração

Três réplicas síncronas

Essa configuração consiste em três réplicas síncronas. Por padrão, ele fornece alta disponibilidade e proteção de dados. Ele também pode fornecer escala de leitura.

Diagrama mostrando três réplicas síncronas.

Um grupo de disponibilidade com três réplicas síncronas pode fornecer escala de leitura, alta disponibilidade e proteção de dados. A tabela a seguir descreve o comportamento de disponibilidade.

Comportamento de disponibilidade escala de leitura Alta disponibilidade &
proteção de dados		 Proteção de dados
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Interrupção primária Failover automático. Pode ter perda de dados. O novo primário é R/W. Failover automático. O novo primário é R/W. Failover automático. O novo primário não está disponível para transações de leitura ou gravação até que o primário anterior se recupere e volte ao grupo de disponibilidade como secundário.
Uma interrupção de réplica secundária O primário é R/W. O secundário disponível está disponível para leituras. O primário é R/W. O secundário disponível está disponível para leituras. O primário permanece indisponível para transações de leitura ou gravação até que o secundário com falha recupere e reingresse no grupo de disponibilidade.
Interrupção de duas réplicas secundárias O primário está disponível apenas para leituras e não para gravações até que uma das réplicas secundárias recupere e volte ao grupo de disponibilidade. O primário está disponível apenas para leituras e não para gravações até que uma das réplicas secundárias recupere e volte ao grupo de disponibilidade. O primário permanece indisponível para transações de leitura ou gravação até que todas as réplicas secundárias com falha se recuperem e voltem ao grupo de disponibilidade.
Interrupção primária e uma réplica secundária Failover automático. Pode ter perda de dados. O novo primário está disponível apenas para leituras e não para gravações até que uma das réplicas secundárias recupere e reingresse no grupo de disponibilidade. Failover automático. O novo primário está disponível apenas para leituras e gravações até que uma das réplicas secundárias se recupere e reingresse no grupo de disponibilidade. Failover automático. O novo primário permanece indisponível para transações de leitura ou gravação até que o primário anterior e a réplica secundária recuperem e reingressem no grupo de disponibilidade.

1 Inadimplência

Duas réplicas síncronas

Esta configuração permite a proteção de dados. Como as outras configurações de grupo de disponibilidade, ele pode habilitar a escala de leitura. A configuração de duas réplicas síncronas não fornece alta disponibilidade automática. Uma configuração de duas réplicas só é aplicável ao SQL Server 2017 (14.x) RTM e não é mais suportada com versões superiores (CU1 e posteriores) do SQL Server 2017 (14.x).

Diagrama mostrando duas réplicas síncronas.

Um grupo de disponibilidade com duas réplicas síncronas fornece escala de leitura e proteção de dados. A tabela a seguir descreve o comportamento de disponibilidade.

Comportamento de disponibilidade escala de leitura Proteção de dados
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Interrupção primária Failover automático. Pode ter perda de dados. O novo primário é R/W. Failover automático. O novo primário não estará disponível para transações de leitura ou gravação até que o primário anterior se recupere e volte ao grupo de disponibilidade como secundário.
Uma interrupção de réplica secundária O principal é R/W, executado exposto à perda de dados. O primário permanece indisponível para transações de leitura ou gravação até que o secundário com falha recupere e reingresse no grupo de disponibilidade.

1 Inadimplência

Duas réplicas síncronas e uma réplica somente de configuração

Um grupo de disponibilidade com duas (ou mais) réplicas síncronas e uma réplica somente de configuração fornece proteção de dados e também pode fornecer alta disponibilidade. O diagrama a seguir representa essa arquitetura:

Diagrama mostrando um grupo de disponibilidade somente de configuração.

  1. Replicação síncrona de dados do usuário para a réplica secundária. Ele também inclui metadados de configuração do grupo de disponibilidade.
  2. Replicação síncrona de metadados de configuração do grupo de disponibilidade. Ele não inclui dados do usuário.

No diagrama de grupo de disponibilidade, uma réplica primária envia dados de configuração por push para a réplica secundária e para a réplica somente de configuração. A réplica secundária também recebe dados do usuário. A réplica apenas de configuração não recebe dados do usuário. A réplica secundária está no modo de disponibilidade síncrona. A réplica somente de configuração não contém os bancos de dados no grupo de disponibilidade - apenas metadados sobre o grupo de disponibilidade. Os dados de configuração na réplica somente de configuração são confirmados de forma síncrona.

Observação

Um grupo de disponibilidade com apenas réplica de configuração é novo para o SQL Server 2017 (14.x) 1. Todas as instâncias do SQL Server no grupo de disponibilidade devem ser SQL Server 2017 (14.x) 1 ou versões posteriores.

O valor padrão para REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT é 0. A tabela a seguir descreve o comportamento de disponibilidade.

Comportamento de disponibilidade Alta disponibilidade &
proteção de dados		 Proteção de dados
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Interrupção primária Failover automático. O novo primário é R/W. Pode ter perda de dados. Failover automático. O novo primário não estará disponível para transações de leitura ou gravação até que o primário anterior se recupere e volte ao grupo de disponibilidade como secundário.
Interrupção secundária da réplica O principal é R/W, sendo executado exposto à perda de dados (se o primário falhar e não puder ser recuperado). Nenhum failover automático se o primário também falhar. O primário permanece indisponível para transações de leitura ou gravação até que o secundário com falha recupere e reingresse no grupo de disponibilidade. Nenhuma réplica para failover se o primário também falhar.
Interrupção de réplica apenas de configuração O primário é R/W. Nenhum failover automático se o primário também falhar. O primário é R/W. Nenhum failover automático se o primário também falhar.
Interrupção secundária síncrona + apenas de réplica de configuração O primário não está disponível para transações de leitura ou gravação. Sem failover automático. O primário não está disponível para transações de leitura ou gravação. Nenhuma réplica para failover se o primário também falhar.

1 Inadimplência

Observação

A instância do SQL Server que hospeda a réplica somente de configuração também pode hospedar outros bancos de dados. Ele também pode participar como um banco de dados somente de configuração para mais de um grupo de disponibilidade.

Requerimentos

  • Todas as réplicas em um grupo de disponibilidade com uma réplica somente de configuração devem ser do SQL Server 2017 (14.x) 1 ou versões posteriores.
  • Qualquer edição do SQL Server pode hospedar uma réplica somente de configuração, incluindo o SQL Server Express.
  • O grupo de disponibilidade precisa de pelo menos uma réplica secundária - além da réplica primária.
  • Somente réplicas de configuração não contam para o número máximo de réplicas por instância do SQL Server. O SQL Server Standard Edition permite até três réplicas, o SQL Server Enterprise Edition permite até 9.

Considerações

  • Não mais do que uma réplica de configuração apenas por grupo de disponibilidade.
  • Uma réplica apenas de configuração não pode ser uma réplica primária.
  • Não é possível modificar o modo de disponibilidade de uma réplica apenas de configuração. Para mudar de uma réplica somente configuração para uma réplica secundária síncrona ou assíncrona, remova a réplica somente configuração e adicione uma réplica secundária com o modo de disponibilidade necessário.
  • Uma réplica somente de configuração é síncrona com os metadados do grupo de disponibilidade. Não há dados do usuário.
  • Um grupo de disponibilidade com uma réplica primária e uma réplica apenas de configuração, mas nenhuma réplica secundária não é válida.
  • Não é possível criar um grupo de disponibilidade em uma instância do SQL Server Express Edition.

Compreender o agente de recursos do SQL Server para Pacemaker

SQL Server 2017 (14.x) introduzido sequence_number para sys.availability_groups mostrar se uma réplica marcada como SYNCHRONOUS_COMMIT estava atualizada. sequence_number é um BIGINT monotonicamente crescente que representa o quão up-todata a réplica do grupo de disponibilidade local está em relação ao resto das réplicas no grupo de disponibilidade. A execução de failovers, a adição ou remoção de réplicas e outras operações de grupo de disponibilidade atualizam esse número. O número é atualizado no primário e, em seguida, enviado para réplicas secundárias. Assim, uma réplica secundária que é up-to-date tem o mesmo sequence_number que a primária.

Quando o Pacemaker decide promover uma réplica para primária, ele primeiro envia uma notificação a todas as réplicas para extrair o número de sequência e armazená-lo (essa notificação é chamada de notificação de pré-promoção). Em seguida, quando o Pacemaker tenta promover uma réplica para primária, a réplica só se promove se o seu número de sequência for o mais alto de todos os números de sequência de todas as réplicas, caso contrário, rejeita a operação de promoção. Desta forma, apenas a réplica com o maior número de sequência pode ser promovida para primária, garantindo que não haja perda de dados.

A promoção só é garantida desde que pelo menos uma réplica disponível para promoção tenha o mesmo número de sequência que a primária anterior. O comportamento padrão é que o agente de recursos do Pacemaker defina REQUIRED_COPIES_TO_COMMIT automaticamente para que pelo menos uma réplica secundária de confirmação síncrona esteja atualizada e disponível, para ser o destino de um failover automático. Com cada ação de monitoramento, o valor de é calculado (e atualizado, se necessário) como ('número de réplicas de REQUIRED_COPIES_TO_COMMIT confirmação síncronas' / 2). Em seguida, no momento do failover, o agente de recursos requer (total number of replicas - required_copies_to_commit réplicas) para responder à notificação de pré-promoção para poder promover um deles para primário. A réplica com o mais alto sequence_number é promovida a primária.

Por exemplo, vamos considerar o caso de um grupo de disponibilidade com três réplicas síncronas - uma réplica primária e duas réplicas secundárias de confirmação síncrona.

  • REQUIRED_COPIES_TO_COMMIT é 3 / 2 = 1

  • O número necessário de réplicas para responder à ação de pré-promoção é de 3 - 1 = 2. Portanto, duas réplicas precisam estar ativas para que o failover seja acionado. Quando ocorre uma interrupção primária, se uma das réplicas secundárias não responder e apenas uma das réplicas secundárias responder à ação de pré-promoção, o agente de recursos não poderá garantir que a secundária que respondeu tenha a maior sequence_numbere um failover não seja acionado.

Um usuário pode optar por substituir o comportamento padrão e configurar o recurso do grupo de disponibilidade para não definir REQUIRED_COPIES_TO_COMMIT automaticamente, como mostrado anteriormente.

Importante

Quando REQUIRED_COPIES_TO_COMMIT há 0 risco de perda de dados. No caso de uma interrupção do primário, o agente de recursos não acionará automaticamente um failover. O usuário tem que decidir se deseja aguardar a recuperação do primário ou fazer failover manualmente.

Para definir REQUIRED_COPIES_TO_COMMIT como 0, execute:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

O comando equivalente usando crm (no SLES) é:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Para reverter para o valor computado padrão, execute:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Observação

A atualização das propriedades do recurso faz com que todas as réplicas parem e reiniciem. Isso significa que o primário será temporariamente rebaixado para secundário e, em seguida, promovido novamente, o que causará indisponibilidade temporária de gravação. O novo valor para REQUIRED_COPIES_TO_COMMIT só será definido quando as réplicas forem reiniciadas, portanto, não será instantâneo com a execução do comando pcs .

Equilibre alta disponibilidade e proteção de dados

O comportamento padrão acima também se aplica ao caso de duas réplicas síncronas (primária + secundária). O Pacemaker assume REQUIRED_COPIES_TO_COMMIT = 1 como padrão garantir que a réplica secundária esteja sempre atualizada para máxima proteção de dados.

Advertência

Isso vem com maior risco de indisponibilidade da réplica primária devido a interrupções planejadas ou não planejadas no secundário. O usuário pode optar por alterar o comportamento padrão do agente de recursos e substituir o REQUIRED_COPIES_TO_COMMIT para 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Uma vez substituído, o agente de recursos usa a nova configuração e REQUIRED_COPIES_TO_COMMIT para de calculá-la. Os usuários precisam atualizá-lo manualmente de acordo (por exemplo, se aumentarem o número de réplicas).

As tabelas a seguir descrevem o resultado de uma interrupção para réplicas primárias ou secundárias em diferentes configurações de recursos do grupo de disponibilidade:

Grupo de disponibilidade - duas réplicas de sincronização

Configuração Interrupção primária Uma interrupção de réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 O usuário tem que emitir um manual FAILOVER.
Pode ter perda de dados.
Novo primário é R/W		 O principal é R/W, executado exposto à perda de dados.
REQUIRED_COPIES_TO_COMMIT = 1 1 Problemas de cluster automaticamente FAILOVER
Sem perda de dados.
O novo primário rejeita todas as conexões até que o primário anterior se recupere e ingresse no grupo de disponibilidade como secundário.		 O primário rejeita todas as conexões até que o secundário se recupere.

1 Agente de recursos do SQL Server para comportamento padrão do Pacemaker.

Grupo de disponibilidade - três réplicas de sincronização

Configuração Interrupção primária Uma interrupção de réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 O usuário tem que emitir um manual FAILOVER.
Pode ter perda de dados.
Novo primário é R/W		 O primário é R/W
REQUIRED_COPIES_TO_COMMIT = 1 1 O cluster emite automaticamente .FAILOVER
Sem perda de dados.
Novo primário é RW		 O primário é R/W

1 Agente de recursos do SQL Server para comportamento padrão do Pacemaker.

Conteúdo relacionado

  • Last updated on