Partilhar via

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

Aplica-se a: SQL Server no Linux

Este artigo apresenta configurações de implementação suportadas para grupos de disponibilidade SQL Server Always On 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.

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

O WSFC sincroniza metadados de configuração para a arbitragem de failover entre as réplicas do grupo de disponibilidade e a testemunha de partilha de ficheiros. Quando um grupo de disponibilidade não está num WSFC, as instâncias SQL Server armazenam metadados de configuração na base de dados master.

Por exemplo, um grupo de disponibilidade em um cluster Linux tem CLUSTER_TYPE = EXTERNAL. Não há WSFC para gerir a alternância de funções (failover). Neste caso, os metadados de configuração são geridos e mantidos pelas instâncias do SQL Server. Como não existe um servidor de testemunha neste cluster, é necessária uma terceira instância do SQL Server para armazenar os metadados do estado de configuração. As três instâncias do SQL Server em conjunto fornecem armazenamento distribuído de metadados para o cluster.

O gestor do cluster pode consultar as instâncias do SQL Server no grupo de disponibilidade e gerir o processo de failover para manter 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 é ativada com duas réplicas síncronas mais uma réplica de configuração apenas. A réplica de configuração apenas pode ser alojada em qualquer edição do SQL Server 2017 (14.x) CU 1 ou versões posteriores (incluindo a edição SQL Server Express). A réplica apenas de configuração 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 do 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 instala o agente de recursos SQL Server - mssql-server-ha - e cria um recurso de cluster para o grupo de disponibilidade, o gestor de cluster deteta a configuração do grupo de disponibilidade e define REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT em conformidade.

Se for suportado pela configuração, o parâmetro do agente de recurso REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT é definido com o valor que assegura alta disponibilidade e proteção de dados. Para mais informações, consulte Compreender o agente de recurso do SQL Server para o Pacemaker.

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 aplicam-se a grupos de disponibilidade para soluções de alta disponibilidade com CLUSTER_TYPE = EXTERNAL.

  • Três réplicas síncronas
  • Duas réplicas síncronas
  • Duas réplicas síncronas e uma réplica dedicada à 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 de um grupo de disponibilidade com uma réplica primária que sincroniza dados com duas réplicas secundárias.

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 escalabilidade 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 e escrita até que o antigo primário se recupere e reingresse no grupo de disponibilidade como secundário.
Uma avaria de réplica secundária O primário é R/W. O secundário está disponível para leitura. 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 A réplica primária está disponível apenas para leituras e não para gravações até que uma das réplicas secundárias se restabeleça e volte a juntar-se 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 de réplica primária e de 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 Predefinição

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 já não é suportada em versões superiores (CU1 e superiores) do SQL Server 2017 (14.x).

Diagrama de um grupo de disponibilidade com uma réplica primária a sincronizar dados para uma réplica secundária.

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 escalabilidade 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 falha de réplica secundária O principal está em modo de leitura/escrita e está operacionalmente 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 Predefinição

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 de configuração apenas fornece proteção de dados e pode ainda fornecer alta disponibilidade. O diagrama a seguir representa essa arquitetura:

Diagrama de um grupo de disponibilidade com uma réplica primária que sincroniza dados e metadados com réplicas secundárias e apenas 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 para a réplica secundária e para a réplica apenas 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 apenas de configuração não contém os bancos de dados do grupo de disponibilidade; contém 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 réplica apenas de configuração é uma novidade para o SQL Server 2017 (14.x) CU 1. Todas as instâncias do SQL Server no grupo de disponibilidade devem ser do SQL Server 2017 (14.x) CU 1 ou versões subsequentes.

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 antigo se recupere e reingresse no grupo de disponibilidade como secundário.
Interrupção secundária da réplica O primário é de leitura/escrita, e está sujeito a perda de dados (caso o primário falhe e não possa ser recuperado). Não haverá alternância automática se o sistema principal 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. Sem réplica para comutação se o primário falhar também.
Interrupção apenas da réplica de configuração O primário é R/W. Nenhum mecanismo de transição automática se o primário também falhar. O primário é R/W. Não haverá failover automático se o servidor principal também falhar.
Interrupção de réplica secundária síncrona + apenas 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. Não há réplica para o failover caso o primário também falhe.

1 Padrão

Observação

A instância do SQL Server que hospeda apenas a réplica de configuração também pode alojar outras bases de dados. Ele também pode funcionar como um banco de dados de configuração única para mais de um grupo de disponibilidade.

Requerimentos

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

Considerações

  • Não mais do que uma réplica apenas de configuração 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 de configuração apenas para uma réplica secundária síncrona ou assíncrona, remova a réplica de configuração apenas 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 sem uma réplica secundária, não é válido.
  • Não se pode criar um grupo de disponibilidade numa instância do SQL Server Express Edition.

Compreender o agente de recursos do SQL Server para o Pacemaker

SQL Server 2017 (14.x) introduziu sequence_number ao sys.availability_groups para mostrar se uma réplica marcada como SYNCHRONOUS_COMMIT está atualizada. sequence_number é um bigint monotonamente crescente que representa o quão atualizada está a réplica do grupo de disponibilidade local em relação às restantes réplicas no grupo de disponibilidade.

Este número atualiza-se quando realiza failovers, adiciona ou remove réplicas e outras operações de grupos de disponibilidade.

A réplica primária atualiza o número e depois envia-o para réplicas secundárias. Uma réplica secundária que está atualizada tem o mesmo sequence_number que a primária.

Quando o Pacemaker decide promover uma réplica para primária, envia primeiro uma notificação a todas as réplicas para extraírem o número de sequência e armazená-lo. Esta notificação chama-se notificação pré-promoção. De seguida, quando o Pacemaker tenta promover uma réplica a primária, a réplica só se auto-promove se o seu número sequencial for o mais alto entre todos os números sequenciais de todas as réplicas. Caso contrário, rejeita a operação de promoção. Ao utilizar este processo, apenas a réplica com o número de sequência mais alto pode ser promovida a primária, garantindo que não haja perda de dados.

A promoção funciona desde que pelo menos uma réplica disponível para promoção tenha um número de sequência idêntico ao da primária anterior. O comportamento padrão é que o agente de recurso do Pacemaker defina REQUIRED_COPIES_TO_COMMIT automaticamente para que pelo menos uma réplica secundária de commit síncrona esteja atualizada e pronta para um failover automático como alvo. Com cada ação de monitorização, o valor de REQUIRED_COPIES_TO_COMMIT é calculado (e atualizado, se necessário) como ('número de réplicas de confirmações 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 principal.

Por exemplo, considere 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 commit síncronas.

  • 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 pode garantir que a secundária que respondeu tenha o maior sequence_number, e, por isso, um failover não é acionado.

Pode sobrescrever o comportamento padrão e configurar o recurso do grupo de disponibilidade para não ser definido REQUIRED_COPIES_TO_COMMIT automaticamente.

Importante

Quando REQUIRED_COPIES_TO_COMMIT é 0, corre o risco de perda de dados. Se ocorrer uma falha no primário, o agente de recursos não aciona automaticamente um failover. Deves escolher entre esperar que o primário recupere ou realizar o 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 SUSE Linux Enterprise Server) é:

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. Esta alteração rebaixa temporariamente o primário para secundário, depois promove-o novamente, o que causa indisponibilidade temporária de escrita. O novo valor para REQUIRED_COPIES_TO_COMMIT só é definido após o reinício das réplicas, por isso não é instantâneo ao executar o comando pcs .

Equilibre alta disponibilidade e proteção de dados

O comportamento padrão descrito anteriormente aplica-se também ao caso de duas réplicas síncronas (primária e secundária). O marcapasso define REQUIRED_COPIES_TO_COMMIT como 1 para garantir que a réplica secundária está sempre atualizada para a máxima proteção de dados.

Advertência

Esta configuração traz um risco maior de indisponibilidade da réplica primária devido a interrupções planeadas ou não planeadas na secundária. Pode optar por alterar o comportamento predefinido do agente de recursos e substituir o valor de REQUIRED_COPIES_TO_COMMIT por 0.

sudo pcs resource update <ag1> required_copies_to_commit=0

Quando sobrescreves este valor, o agente de recursos usa a nova definição para REQUIRED_COPIES_TO_COMMIT e para de o calcular. Deve atualizá-lo manualmente se necessário (por exemplo, se aumentar 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 síncronas

Configuração Interrupção primária Uma falha de réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 Deve emitir manualmente um FAILOVER.

Pode causar perda de dados.

O novo primário é R/W.		 O principal está em modo de leitura/escrita e está operacionalmente 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 sincronizadas

Configuração Interrupção primária Uma falha de réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 Deve emitir manualmente um FAILOVER.

Pode causar perda de dados.

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

O novo primário é R/W.		 O primário é R/W.

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

Conteúdo relacionado

  • Last updated on