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

  • Artigo

Aplica-se a: SQL Server – Linux

Este artigo apresenta as configurações de implantação compatíveis com os grupos de disponibilidade Always On do SQL Server em servidores Linux. Um grupo de disponibilidade dá suporte à alta disponibilidade e à proteção de dados. Detecção automática de falhas, failover automático e reconexão transparente após o failover fornecem alta disponibilidade. As 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 arquivo para fornecer quorum. A testemunha de compartilhamento de arquivo 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 o destino de failover tenha as alterações mais recentes de configuração de dados e grupo de disponibilidade.

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

Por exemplo, um grupo de disponibilidade em um cluster do Linux tem CLUSTER_TYPE = EXTERNAL. Não há um WSFC para arbitrar o 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 os metadados do estado de configuração. Todas as três instâncias do SQL Server juntas fornecem armazenamento de metadados distribuído 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 do Linux, o Pacemaker é o gerenciador de cluster.

O SQL Server 2017 (14.x) CU 1 permite alta disponibilidade para um grupo de disponibilidade com CLUSTER_TYPE = EXTERNAL para duas réplicas síncronas, mais 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) CU 1 ou posterior (incluindo o SQL Server Express edition). A réplica somente de configuração mantém as 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 recurso padrão

O SQL Server 2017 (14.x) apresenta a configuração de recurso de cluster REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Essa configuração garante que o número especificado de réplicas secundárias grave os 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 da 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 detecta a configuração do grupo de disponibilidade e define REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT de acordo.

Se houver suporte na configuração, o parâmetro do agente de recursos REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT será definido com o valor que fornece alta disponibilidade e proteção de dados. Para obter mais informações, confira Noções básicas do agente de recursos 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 de acordo com seus requisitos empresariais 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 as funcionalidades de cada padrão. Esses padrões de design se aplicam a grupos de disponibilidade com CLUSTER_TYPE = EXTERNAL para 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, ela fornece alta disponibilidade e proteção de dados. Ela também pode fornecer escala de leitura.

Diagrama que mostra 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 e
proteção de dados		 Proteção de dados
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Interrupção principal Failover automático. Pode ocorrer perda de dados. A nova primária é R/W. Failover automático. A nova primária é R/W. Failover automático. A nova primária não estará disponível para transações de atualização de usuário enquanto a primária anterior não se recuperar e ingressar no grupo de disponibilidade como secundária.
Interrupção de uma réplica secundária A primária é R/W. A primária é R/W. A primária não estará disponível para transações de atualização de usuário enquanto a secundária com falha não se recuperar e ingressar no grupo de disponibilidade.

1 Padrão

Duas réplicas síncronas

Essa configuração habilita a proteção de dados. Assim como as outras configurações de grupo de disponibilidade, ela 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 compatível com versões superiores (CU1 e posterior) do SQL Server 2017 (14.x).

Diagrama que mostra 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 principal Failover automático. Pode ocorrer perda de dados. A nova primária é R/W. Failover automático. A nova primária não estará disponível para transações de atualização de usuário enquanto a primária anterior não se recuperar e ingressar no grupo de disponibilidade como secundária.
Interrupção de uma réplica secundária A primária é R/W; execução exposta à perda de dados. A primária não estará disponível para transações de atualização de usuário enquanto a secundária não se recuperar.

1 Padrã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 somente de configuração fornece proteção de dados e também pode fornecer alta disponibilidade. O seguinte diagrama representa essa arquitetura:

Diagrama que mostra um grupo de disponibilidade somente de configuração.

  1. Replicação síncrona de dados do usuário para a réplica secundária. Ela 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. Ela não inclui dados do usuário.

No diagrama do grupo de disponibilidade, uma réplica primária envia dados de configuração por push para a réplica secundária e a réplica somente de configuração. A réplica secundária também recebe dados do usuário. A réplica somente 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 os 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 somente de configuração é uma novidade do SQL Server 2017 (14.x) CU 1. Todas as instâncias do SQL Server do grupo de disponibilidade precisam ter o SQL Server 2017 (14.x) CU 1 ou posterior.

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

Comportamento de disponibilidade Alta disponibilidade e
proteção de dados		 Proteção de dados
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Interrupção principal Failover automático. A nova primária é R/W. Pode ocorrer perda de dados. Failover automático. A nova primária não está disponível para transações de atualização de usuário.
Interrupção de uma réplica secundária A primária é R/W; execução exposta à perda de dados (se a primária falhar e não puder ser recuperada). Nenhum failover automático se a primária falhar também. A primária não está disponível para transações de atualização de usuário. Nenhuma réplica para failover se a primária falhar também.
Interrupção de réplica somente de configuração A primária é R/W. Nenhum failover automático se a primária falhar também. A primária é R/W. Nenhum failover automático se a primária falhar também.
Interrupção de réplica somente de configuração + secundária síncrona A primária não está disponível para transações de atualização de usuário. Sem failover automático. A primária não está disponível para transações de atualização de usuário. Nenhuma réplica para failover se a primária falhar também.

1 Padrão

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. Ela também pode participar como um banco de dados somente de configuração para mais de um grupo de disponibilidade.

Requisitos

  • Todas as réplicas de um grupo de disponibilidade com uma réplica somente de configuração precisam ter o SQL Server 2017 (14.x) CU 1 ou posterior.
  • 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.
  • As réplicas somente de configuração não são consideradas no número máximo de réplicas por instância do SQL Server. O SQL Server Standard permite até três réplicas, enquanto a SQL Server Enterprise Edition permite até nove.

Considerações

  • Não mais de uma réplica somente de configuração por grupo de disponibilidade.
  • Uma réplica somente 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 somente de configuração. Para fazer a alteração de uma réplica somente de configuração para uma réplica secundária síncrona ou assíncrona, remova a réplica somente de 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 somente 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.

Conceitos básicos sobre o agente de recursos do SQL Server para Pacemaker

O SQL Server 2017 (14.x) introduziu sequence_number para sys.availability_groups a fim de mostrar se uma réplica marcada como SYNCHRONOUS_COMMIT estava atualizada. sequence_number é um BIGINT de crescimento monotônico que representa o quanto a réplica do grupo de disponibilidade local está atualizada em relação ao restante das réplicas do grupo de disponibilidade. Executar failovers, adicionar ou remover réplicas e outras operações do grupo de disponibilidade atualizam esse número. O número é atualizado na réplica primária e então enviado por push para réplicas secundárias. Portanto, uma réplica secundária que está atualizada terá 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 para 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 tentar promover uma réplica para primária, a réplica apenas se promoverá caso o seu número de sequência seja o mais alto de todos os números de sequência dentre todas as réplicas, caso contrário ela rejeitará a operação. Dessa maneira, somente a réplica com o maior número de sequência pode ser promovida a primária, garantindo que não haverá perda de dados.

Só há garantia de que a promoção funcione se, pelo menos, uma réplica disponível para promoção tem o mesmo número de sequência da primária anterior. O comportamento padrão do agente de recursos do Pacemaker é definir automaticamente REQUIRED_COPIES_TO_COMMIT, de forma que pelo menos uma réplica secundária de confirmação síncrona seja atualizada e esteja disponível como o destino de um failover automático. Com cada ação de monitoramento, o valor de REQUIRED_COPIES_TO_COMMIT é calculado (e atualizado, se necessário) como ('número de réplicas de confirmação síncronas' / 2). Depois, no momento do failover, o agente de recurso exigirá que (réplicas total number of replicas - required_copies_to_commit) respondam à notificação de pré-promoção para ser capaz de promover uma delas para primária. A réplica com o sequence_number mais alto é promovida a primária.

Por exemplo, consideraremos 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 é 3-1 = 2. Assim, duas réplicas precisam estar ativas para o failover ser disparado. Em caso de interrupção primária, se uma das réplicas secundárias não estiver respondendo e somente 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 o sequence_number mais alto e um failover não será disparado.

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

Importante

Quando REQUIRED_COPIES_TO_COMMIT é 0, há risco de perda de dados. Em caso de uma interrupção da primária, o agente de recursos não disparará um failover automaticamente. O usuário precisa decidir se deseja aguardar que a primária se recupere 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 padrão calculado, execute:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Observação

Atualizar as propriedades do recurso faz com que todas as réplicas parar e reiniciem. Isso significa que a primária será temporariamente rebaixada para secundária e promovida novamente, o que causará indisponibilidade temporária de gravação. O novo valor para REQUIRED_COPIES_TO_COMMIT será ser definido apenas depois que as réplicas forem reiniciadas, portanto, não será instantâneo com a execução do comando pcs.

Balancear a alta disponibilidade e a proteção de dados

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

Aviso

Isso é fornecido com um risco maior de indisponibilidade da réplica primária devido a interrupções planejadas ou não na secundária. 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

Quando substituído, o agente de recursos usará a nova configuração para REQUIRED_COPIES_TO_COMMIT e deixará de computá-la. Os usuários terão de atualizá-la manualmente de forma adequada (por exemplo, se o número de réplicas aumentar).

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 principal Interrupção de uma réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 O usuário deve emitir um FAILOVER manual.
Pode ocorrer perda de dados.
A nova primária é R/W		 A primária é R/W; execução exposta à perda de dados.
REQUIRED_COPIES_TO_COMMIT = 1 1 O cluster emite FAILOVER automaticamente
Sem perda de dados.
A nova primária rejeita todas as conexões até que a antiga primária se recupere e ingresse no grupo de disponibilidade como secundária.		 A primária rejeita todas as conexões até a secundária se recuperar.

1 Comportamento padrão do agente de recursos do SQL Server para Pacemaker.

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

Configuração Interrupção principal Interrupção de uma réplica secundária
REQUIRED_COPIES_TO_COMMIT = 0 O usuário deve emitir um FAILOVER manual.
Pode ocorrer perda de dados.
A nova primária é R/W		 A primária é R/W
REQUIRED_COPIES_TO_COMMIT = 1 1 O cluster emite FAILOVER automaticamente.
Sem perda de dados.
A nova primária é RW		 A primária é R/W

1 Comportamento padrão do agente de recursos do SQL Server para Pacemaker.

Conteúdo relacionado