Grupos de disponibilidade para o SQL Server em Linux

Aplica-se a: SQL Server – Linux

Este artigo descreve as características dos AGs (grupos de disponibilidade) nas instalações do SQL Server baseadas no Linux. Ele também aborda as diferenças entre os AGs baseados no WSFC (cluster de failover do Windows Server) e no Linux. Consulte Visão geral do grupo de disponibilidade Always On para obter as noções básicas dos AGs, pois eles funcionam da mesma forma no Windows e no Linux, exceto no WSFC.

Do ponto de vista de alto nível, os grupos de disponibilidade do SQL Server no Linux são os mesmos das implementações baseadas no WSFC. Isso significa que todas as limitações e os recursos são os mesmos, com algumas exceções. As principais diferenças incluem:

• O Coordenador de Transações Distribuídas (DTC) da Microsoft é compatível com o Linux a partir do SQL Server 2017 CU 16. No entanto, ainda não há suporte para o DTC em grupos de disponibilidade no Linux. Se os aplicativos exigirem o uso de transações distribuídas e precisarem de um AG, implante o SQL Server no Windows.
• As implantações baseadas em Linux que exigem alta disponibilidade usam o Pacemaker para clustering em vez de um WSFC.
• Ao contrário da maioria das configurações para AGs no Windows, exceto pelo cenário de Cluster de Grupo de Trabalho, o Pacemaker nunca exige o AD DS (Active Directory Domain Services).
• Como fazer failover de um AG de um nó para outro é diferente entre o Linux e o Windows.
• Algumas configurações, como required_synchronized_secondaries_to_commit, só podem ser alteradas por meio do Pacemaker no Linux, enquanto uma instalação baseada no WSFC usa o Transact-SQL.

Número de réplicas e nós de cluster

Um AG no SQL Server Standard pode ter duas réplicas no total: uma primária e uma secundária que só podem ser usadas para fins de disponibilidade. Ele não pode ser usado para nada mais, como consultas legíveis. Um AG no SQL Server Enterprise pode ter até nove réplicas no total: uma primária e até oito secundárias, das quais até três (incluindo a primária) podem ser síncronas. Se você estiver usando um cluster subjacente, poderá haver, no máximo, 16 nós quando o Corosync estiver envolvido. Um grupo de disponibilidade pode abranger, no máximo, nove dos 16 nós com SQL Server Enterprise e dois com SQL Server Standard.

Uma configuração de duas réplicas que exige a capacidade de fazer failover automaticamente para outra réplica exige o uso de uma réplica somente de configuração, conforme descrito em Quorum e réplica somente de configuração. As réplicas somente de configuração foram introduzidas no SQL Server 2017 (14.x) CU1 (atualização cumulativa 1), de modo que essa deve ser a versão mínima implantada para essa configuração.

Se o Pacemaker for usado, ele deverá ser configurado corretamente para que permaneça em funcionamento. Isso significa que o quorum e o isolamento de um nó com falha precisam ser implementados corretamente de uma perspectiva do Pacemaker, além dos requisitos do SQL Server, como uma réplica somente de configuração.

Somente há suporte para réplicas secundárias legíveis no SQL Server Enterprise.

Tipo de cluster e modo de failover

Uma novidade do SQL Server 2017 (14.x) é a introdução de um tipo de cluster para AGs. Para Linux, há dois valores válidos: Externo e Nenhum. Um tipo de cluster Externo significa que o Pacemaker será usado sob o AG. O uso de Externo para o tipo de cluster exige que o modo de failover seja definido como Externo também (outra novidade do SQL Server 2017 (14.x)). Há suporte para failover automático, mas, ao contrário de um WSFC, o modo de failover é definido como Externo, não automático, quando o Pacemaker é usado. Ao contrário de um WSFC, a parte do Pacemaker do AG é criada depois que o AG é configurado.

Um tipo de cluster Nenhum significa que não há nenhum requisito para o Pacemaker nem o AG o usará. Mesmo nos servidores que têm o Pacemaker configurado, se um AG estiver configurado com um tipo de cluster Nenhum, o Pacemaker não verá nem gerenciará esse AG. Um tipo de cluster Nenhum só dá suporte ao failover manual de uma réplica primária para uma secundária. Um AG criado com o tipo Nenhum é destinado principalmente a atualizações e expansão de leitura. Embora ele possa funcionar em cenários como recuperação de desastre ou disponibilidade local quando nenhum failover automático é necessário, isso não é recomendado. A história do ouvinte também é mais complexa sem o Pacemaker.

O tipo de cluster é armazenado na DMV (exibição de gerenciamento dinâmico) sys.availability_groups do SQL Server, nas colunas cluster_type e cluster_type_desc.

required_synchronized_secondaries_to_commit

Uma novidade do SQL Server 2017 (14.x) é uma configuração que é usada por AGs chamada required_synchronized_secondaries_to_commit. Isso informa ao AG o número de réplicas secundárias que precisam estar em sincronia com a primária. Isso habilita tarefas como failover automático (somente quando integrado ao Pacemaker com um tipo de cluster Externo) e controla o comportamento de tarefas como a disponibilidade da primária se o número correto de réplicas secundárias está online ou offline. Para entender mais sobre como isso funciona, confira Alta disponibilidade e proteção de dados para configurações do grupo de disponibilidade. O valor required_synchronized_secondaries_to_commit é definido por padrão e mantido pelo Pacemaker/SQL Server. Você pode substituir esse valor manualmente.

A combinação de required_synchronized_secondaries_to_commit e o novo número de sequência (que é armazenado em sys.availability_groups) informa o Pacemaker e SQL Server que, por exemplo, o failover automático poderá ocorrer. Nesse caso, uma réplica secundária terá o mesmo número de sequência da primária, o que significa que ela está atualizada com todas as informações de configuração mais recentes.

Há três valores que podem ser definidos para required_synchronized_secondaries_to_commit: 0, 1 ou 2. Eles controlam o comportamento do que acontece quando uma réplica fica não disponível. Os números correspondem ao número de réplicas secundárias que precisam ser sincronizadas com a primária. O comportamento é o seguinte no Linux:

required_synchronized_secondaries_to_commit controla não apenas o comportamento de failovers com réplicas síncronas, mas a perda de dados. Com um valor igual a 1 ou 2, uma réplica secundária sempre precisa ser sincronizada, para que sempre haja redundância de dados. Isso significa que não há perda de dados.

Para alterar o valor de required_synchronized_secondaries_to_commit, use a seguinte sintaxe:

RHEL (Red Hat Enterprise Linux) e Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

Neste exemplo, <AGResourceName> é o nome do recurso configurado para o AG e <value> é 0, 1 ou 2. Para defini-lo novamente com o padrão do Pacemaker que gerencia o parâmetro, execute a mesma instrução sem valor.

O failover automático de um AG é possível quando as seguintes condições são atendidas:

• As réplicas primária e a secundária são definidas como movimentação de dados síncrona.
• O secundário tem um estado igual a sincronizado (não sincronizando), o que significa que os dois estão no mesmo ponto de dados.
• O tipo de cluster é definido como Externo. O failover automático não é possível com um tipo de cluster Nenhum.
• O sequence_number da réplica secundária a se tornar a primária tem o número de sequência mais alto – em outras palavras, o sequence_number da réplica secundária corresponde àquele da réplica primária original.

Se essas condições forem atendidas e o servidor que hospeda a réplica primária falhar, o AG alterará a propriedade para uma réplica síncrona. O comportamento das réplicas síncronas (das quais pode haver três totais: uma primária e duas réplicas secundárias) pode continuar sendo controlado por required_synchronized_secondaries_to_commit. Isso funciona com os AGs no Windows e no Linux, mas é configurado de maneira diferente. No Linux, o valor é configurado automaticamente pelo cluster no próprio recurso do AG.

Quorum e réplica somente de configuração

Outra novidade do SQL Server 2017 (14.x) no CU 1 em diante é uma réplica somente de configuração. Como o Pacemaker é diferente de um WSFC, especialmente quando se trata de quorum e da exigência de isolamento de um nó com falha, ter apenas uma configuração de dois nós não funcionará para um AG. Para uma FCI, os mecanismos de quorum fornecidos pelo Pacemaker podem ser satisfatórios, porque toda a arbitragem de failover da FCI ocorre na camada de cluster. Para um AG, a arbitragem no Linux ocorre em SQL Server, no qual todos os metadados são armazenados. É nesse momento que a réplica somente de configuração entra em cena.

Sem qualquer outro item, um terceiro nó e, pelo menos, uma réplica sincronizada serão necessários. A réplica somente de configuração armazena a configuração do AG no banco de dados master, igual às outras réplicas na configuração do AG. A réplica somente de configuração não tem os bancos de dados de usuário que participam do AG. Os dados de configuração são enviados de forma síncrona da primária. Esses dados de configuração são usados durante failovers, sejam eles automáticos ou manuais.

Para que um AG mantenha o quorum e permita failovers automáticos com um tipo de cluster Externo, ele precisa:

• Ter três réplicas síncronas (somente SQL Server Enterprise); ou
• Ter duas réplicas (primária e secundária) e uma réplica somente de configuração.

Os failovers manuais poderão ocorrer se os tipos de cluster Externo ou Nenhum estiverem sendo usados para configurações do AG. Embora uma réplica somente de configuração possa ser definida com um AG que tem um tipo de cluster Nenhum, isso não é recomendável, pois complica a implantação. Para essas configurações, modifique required_synchronized_secondaries_to_commit manualmente para que ele tenha um valor igual a, pelo menos, 1, de modo que haja, no mínimo, uma réplica sincronizada.

Uma réplica somente de configuração pode ser hospedada em qualquer edição do SQL Server, incluindo o SQL Server Express. Isso minimizará os custos de licenciamento e garantirá que ele funcione com AGs no SQL Server Standard edition. Isso significa que o terceiro servidor necessário só precisa atender à especificação mínima do SQL Server, pois ele não recebe o tráfego de transação do usuário para o AG.

Quando uma réplica somente de configuração é usada, ela tem o seguinte comportamento:

• Por padrão, required_synchronized_secondaries_to_commit é definido como 0. Isso pode ser modificado manualmente para 1, se desejado.

• Se a primária falhar e required_synchronized_secondaries_to_commit for 0, a réplica secundária se tornará a nova primária e ficará disponível para leitura e gravação. Se o valor for 1, ocorrerá um failover automático, mas não serão aceitas novas transações até que a outra réplica esteja online.

• Se uma réplica secundária falhar e required_synchronized_secondaries_to_commit for 0, a réplica primária ainda aceitará transações, mas se a primária falhar nesse ponto, não haverá proteção para os dados nem um failover possível (manual ou automático), pois uma réplica secundária não está disponível.

• Se as réplica somente de configuração falhar, o AG funcionará normalmente, mas nenhum failover automático será possível.

• Se a réplica secundária síncrona e a réplica somente de configuração falharem, a primária não poderá aceitar transações e não haverá nenhum lugar para ela fazer failover.

No CU 1, há um bug conhecido no registro em log, no arquivo corosync.log gerado por meio de mssql-server-ha. Se uma réplica secundária não puder se tornar a primária devido ao número de réplicas necessárias disponíveis, a mensagem atual indicará Expected to receive 1 sequence numbers but only received 2. Not enough replicas are online to safely promote the local replica. Os números devem ser invertidos e a mensagem deverá ser Expected to receive 2 sequence numbers but only received 1. Not enough replicas are online to safely promote the local replica.

Vários grupos de disponibilidade

Mais de um AG pode ser criado por conjunto de servidores ou cluster do Pacemaker. A única limitação são os recursos do sistema. A propriedade do AG é mostrada pela primária. Diferentes AGs podem pertencer a diferentes nós. Eles não precisam estar em execução no mesmo nó.

Localização da unidade e da pasta para bancos de dados

Como ocorre em AGs baseados no Windows, a estrutura de pastas e unidade para os bancos de dados de usuário que participam de um AG devem ser idênticas. Por exemplo, se os bancos de dados de usuário estiverem em /var/opt/mssql/userdata no Servidor A, essa mesma pasta deverá existir no Servidor B. A única exceção a isso é indicada na seção Interoperabilidade com réplicas e grupos de disponibilidade baseados no Windows.

O ouvinte no Linux

O ouvinte é uma funcionalidade opcional para um AG. Ele fornece um ponto único de entrada para todas as conexões (leitura/gravação para a réplica primária e/ou somente leitura para réplicas secundárias), de modo que os aplicativos e os usuários finais não precisem saber qual servidor está hospedando os dados. Em um WSFC, essa é a combinação de um recurso de nome de rede e um recurso de IP, que, em seguida, é registrado no AD DS (se necessário) e no DNS. Em combinação com o próprio recurso do AG, ele fornece essa abstração. Para obter mais informações sobre um ouvinte, confira Conectar-se a um ouvinte do grupo de disponibilidade Always On.

O ouvinte no Linux é configurado de forma diferente, mas sua funcionalidade é a mesma. Não há nenhum conceito de um recurso de nome de rede no Pacemaker, nem um objeto é criado no AD DS; há apenas um recurso de endereço IP criado no Pacemaker que pode ser executado em qualquer um dos nós. Uma entrada associada ao recurso de IP para o ouvinte no DNS com um "nome amigável" precisa ser criada. O recurso de IP para o ouvinte estará ativo somente no servidor que hospeda a réplica primária para esse grupo de disponibilidade.

Se o Pacemaker for usado e um recurso de endereço IP for criado e associado ao ouvinte, haverá uma breve interrupção, pois o endereço IP é interrompido em um servidor e começa no outro, seja ele um failover automático ou manual. Embora isso forneça abstração por meio da combinação de um só nome e endereço IP, ele não mascara a interrupção. Um aplicativo precisa conseguir lidar com a desconexão tendo algum tipo de funcionalidade para detectar isso e se reconectar.

No entanto, a combinação do nome DNS e do endereço IP ainda não é suficiente para fornecer toda a funcionalidade oferecida por um ouvinte em um WSFC, como o roteamento somente leitura para réplicas secundárias. Ao configurar um AG, um ouvinte ainda precisa ser configurado no SQL Server. Isso pode ser visto no assistente e na sintaxe Transact-SQL. Há duas maneiras de configurar isso para que funcione como no Windows:

• Para um AG com um tipo de cluster Externo, o endereço IP associado ao ouvinte criado no SQL Server deve ser o endereço IP do recurso criado no Pacemaker.
• Para um AG criado com um tipo de cluster Nenhum, use o endereço IP associado à réplica primária.

A instância associada ao endereço IP fornecido torna-se o coordenador de tarefas como solicitações de roteamento somente leitura dos aplicativos.

Interoperabilidade com réplicas e grupos de disponibilidade baseados no Windows

Um AG que tenha um tipo de cluster Externo ou um que seja um WSFC não pode ter réplicas entre plataformas. Isso será verdadeiro se o AG for SQL Server Standard ou SQL Server Enterprise. Isso significa que, em uma configuração tradicional do AG com um cluster subjacente, uma réplica não pode estar em um WSFC e a outra no Linux com o Pacemaker.

Um AG com um tipo de cluster NENHUM pode ter suas réplicas entre limites do sistema operacional e, portanto, pode haver réplicas baseadas no Linux e no Windows no mesmo AG. Um exemplo é mostrado aqui, em que a réplica primária é baseada no Windows, enquanto o secundário está em uma das distribuições do Linux.

Uma AG distribuída também pode cruzar os limites do sistema operacional. Os AGs subjacentes são limitados pelas regras de como eles são configurados, como um configurado com Externo sendo somente Linux, mas o AG no qual ele ingressou pode ser configurado usando um WSFC. Considere o seguinte exemplo:

Conteúdo relacionado

• Configurar o grupo de disponibilidade Always On do SQL Server para alta disponibilidade no Linux
• Configurar um grupo de disponibilidade do SQL Server para escala de leitura no Linux
• Adicionar um recurso de cluster de grupo de disponibilidade no Linux
• Configurar o Grupo de Disponibilidade Always On do SQL Server no Windows e no Linux (multiplataforma)