Grupos de disponibilidade para SQL Server em Linux

Aplica-se a:SQL Server no Linux

Este artigo descreve as características dos AGs (grupos de disponibilidade) em instalações de SQL Server baseadas em Linux. Ele também aborda as diferenças entre AGs baseados em failover clusters do Linux e do Windows Server (WSFC). Consulte O que é um grupo de disponibilidade AlwaysOn? para as noções básicas dos AGs, pois eles funcionam da mesma forma em Windows e Linux, exceto no WSFC.

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

• Coordenador de Transações Distribuídas da Microsoft (DTC) tem suporte no Linux a partir do SQL Server 16 de 2017. No entanto, ainda não há suporte para o DTC em grupos de disponibilidade no Linux. Se seus aplicativos exigirem o uso de transações distribuídas e precisarem de um AG, implante 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 para o cenário de Cluster de Grupo de Trabalho, o Pacemaker nunca exige Active Directory Domain Services (AD DS).
• Como falhar um AG de um nó para outro é diferente entre Linux e Windows.
• Determinadas configurações, como required_synchronized_secondaries_to_commit, só podem ser alteradas por meio do Pacemaker no Linux, enquanto uma instalação baseada em WSFC usa Transact-SQL.

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

Um AG no SQL Server Standard Edition pode ter duas réplicas totais: uma primária e uma secundária que só pode ser usada para fins de disponibilidade. Ele não pode ser usado para nada mais, como consultas legíveis. Um AG no SQL Server Enterprise Edition pode ter até nove réplicas totais: 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 Edition e dois com SQL Server Standard Edition.

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. Réplicas de apenas configuração foram introduzidas no SQL Server 2017 (14.x) Atualização Cumulativa 1 (CU 1), portanto, 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 bloqueio de um nó com falha devem ser implementados corretamente a partir de uma perspectiva do Pacemaker, além de quaisquer requisitos do SQL Server, como uma réplica somente de configuração.

Réplicas secundárias legíveis só têm suporte com SQL Server Enterprise Edition.

Tipo de cluster e modo de failover

Novo para 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 é usado sob o AG. Usar Externo para tipo de cluster requer que o modo de failover também seja definido como Externo (também novo no 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á necessidade de Pacemaker, nem o AG o utiliza. Mesmo em servidores que tenham 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 exibição de gerenciamento dinâmico do SQL Server (DMV) sys.availability_groups, nas colunas cluster_type e cluster_type_desc.

required_synchronized_secondaries_to_commit

Novidade no SQL Server 2017 (14.x) é uma configuração 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 pode acontecer. Nesse caso, uma réplica secundária teria o mesmo número de sequência que a 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 de 1 ou 2, uma réplica secundária deve ser sempre sincronizada para garantir a 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 mudará 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 AGs tanto no Windows quanto no Linux, mas as configurações são feitas 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

Uma réplica somente de configuração foi introduzida para resolver as limitações no tratamento de quorum com o Pacemaker, especialmente ao isolar um nó com falha. Ter apenas uma configuração de dois nós não funciona para um AG. Para uma FCI, os mecanismos de quorum fornecidos pelo Pacemaker podem ser bons porque toda a arbitragem de failover de FCI ocorre na camada de cluster. Para um AG, a arbitragem em Linux ocorre em SQL Server, em que 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 os 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 Edition); 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 tenha, 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 SQL Server Express. Isso minimiza os custos de licenciamento e garante que ele funcione com os AGs no SQL Server Standard Edition. Isso significa que o terceiro servidor necessário só precisa atender à especificação mínima para SQL Server, pois ele não está recebendo tráfego de transação de 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 torna a nova primária e fica disponível para leitura e gravação. Se o valor for 1, o failover automático ocorrerá, mas não aceitará 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 aceita transações, mas se a primária falhar nesse ponto, não haverá proteção para os dados nem failover possível (manual ou automático), pois não há uma réplica secundária disponível.

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

• 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 o qual a primária possa fazer o failover.

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 pelo primário. 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

Assim como nos AGs baseados em Windows, a estrutura de unidade e pasta para os bancos de dados de usuário que participam de um AG deve ser idêntica. 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 é observada na seção Interoperabilidade com réplicas e grupos de disponibilidade baseados em 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, consulte 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á o 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 só está ativo no servidor que hospeda a réplica primária para esse grupo de disponibilidade.

Se o Pacemaker for usado e for criado um recurso de endereço IP associado ao ouvinte, haverá uma breve interrupção quando o endereço IP parar em um servidor e começar no outro, seja o 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. Quando você configura 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 pelas quais isso pode ser configurado para funcionar da mesma forma que em Windows:

• Para um AG com um tipo de cluster externo, o endereço IP associado ao Listener 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 grupos de disponibilidade e réplicas 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 é verdade se o AG é SQL Server standard edition ou SQL Server Enterprise Edition. 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 NONE pode ter suas réplicas atravessando fronteiras de sistemas operacionais, de modo que pode haver réplicas que utilizam sistemas operacionais Linux e Windows no mesmo AG. Um exemplo é mostrado aqui em que a réplica primária é baseada em Windows, enquanto a secundária está em uma das distribuições do Linux.

Uma AG distribuída também pode cruzar os limites do sistema operacional. Os AGs subjacentes estão vinculados às regras de configuração, como, por exemplo, um AG configurado com External sendo somente Linux, mas o AG ao qual ele está vinculado poderia ser configurado usando um WSFC. Considere o seguinte exemplo:

Conteúdo relacionado

• Configurar grupo de disponibilidade do SQL Server para alta disponibilidade no Linux
• Configurar um grupo de disponibilidade do SQL Server para leitura escalável no Linux
• Configurar um cluster Pacemaker para grupos de disponibilidade do SQL Server
• Configurar SQL Server Always On availability group no Windows e Linux (multiplataforma)