Continuidade dos negócios e recuperação do banco de dados – SQL Server em Linux

Aplica-se a:SQL Server no Linux

Este artigo fornece uma visão geral das soluções de continuidade dos negócios para alta disponibilidade e recuperação de desastre do SQL Server, no Windows e no Linux.

Todos os que implantam o SQL Server precisam garantir que todas as instâncias críticas do SQL Server e os bancos de dados dentro delas estejam disponíveis quando os usuários comerciais e finais precisarem delas, seja durante o horário comercial regular ou 24 horas por dia. A meta é manter os negócios em funcionamento com o mínimo ou sem qualquer interrupção. Esse conceito também é conhecido como continuidade dos negócios.

O SQL Server 2017 (14.x) e versões posteriores introduziram recursos e aprimoramentos para disponibilidade. A maior adição é o suporte para o SQL Server em distribuições do Linux. Para ver a lista completa dos novos recursos do SQL Server, confira os seguintes artigos:

Este artigo se concentra nos cenários de disponibilidade no SQL Server 2017 (14.x) e versões posteriores, bem como nos recursos de disponibilidade novos e aprimorados. Os cenários incluem os híbridos que podem abranger implantações do SQL Server no Windows Server e no Linux e que podem aumentar o número de cópias legíveis de um banco de dados.

Embora este artigo não aborde as opções de disponibilidade externas ao SQL Server (como virtualização), tudo discutido aqui se aplica às instalações do SQL Server dentro de uma máquina virtual convidada, seja na nuvem pública ou hospedada por um servidor de hipervisor local.

Cenários do SQL Server que usam recursos de disponibilidade

Você pode usar grupos de disponibilidade Always On, instâncias em cluster de failover e envio de logs de várias formas; não apenas focando na disponibilidade. Há quatro maneiras principais de usar os recursos de disponibilidade:

• Alta disponibilidade
• Recuperação de desastre
• Migrações e atualizações
• Expandindo cópias legíveis de um ou mais bancos de dados

As seções a seguir descrevem os recursos relevantes para cada cenário. Um recurso não abordado é a replicação do SQL Server. Embora a replicação do SQL Server não seja oficialmente designada como um recurso de disponibilidade no guarda-chuva Always On, ela geralmente é usada para tornar os dados redundantes em determinados cenários. A replicação de mesclagem não é compatível com o SQL Server em Linux. Para obter mais informações, consulte a replicação do SQL Server no Linux.

Alta disponibilidade

É importante garantir que instâncias ou bancos de dados do SQL Server estejam disponíveis se ocorrer um problema que seja local para um data center ou uma única região na nuvem. Esta seção explica como os recursos de disponibilidade do SQL Server podem ajudar. Todos os recursos descritos estão disponíveis no Windows Server e no Linux.

Grupos de disponibilidade

Os AGs (grupos de disponibilidade) fornecem proteção no nível do banco de dados enviando cada transação de um banco de dados para outra instância ou réplica, que contém uma cópia desse banco de dados em um estado especial. Você pode implantar um AG em edições Standard ou Enterprise. As instâncias que participam de um AG podem ser autônomas ou FCIs (instâncias de cluster de failover, descritas na próxima seção). Como as transações são enviadas para uma réplica conforme elas acontecem, os AGs são recomendados quando há requisitos de objetivos de tempo de recuperação e de ponto de recuperação mais baixos. A movimentação de dados entre as réplicas pode ser síncrona ou assíncrona, com a Enterprise Edition, permitindo que até três réplicas (incluindo a primária) sejam síncronas. Um AG tem uma cópia de leitura/gravação completa do banco de dados na réplica primária, enquanto as réplicas secundárias não podem receber transações diretamente dos usuários finais nem de aplicativos.

Antes do SQL Server 2022 (16.x), os AGs apenas forneciam proteção de nível do banco de dados e não de nível da instância. Qualquer coisa não capturada no log de transações ou configurada no banco de dados deve ser sincronizada manualmente para cada réplica secundária. Alguns exemplos de objetos que devem ser sincronizados manualmente são logons no nível de instância, servidores vinculados e trabalhos do SQL Server Agent.

No SQL Server 2022 (16.x) e versões posteriores, você pode gerenciar objetos de metadados, incluindo usuários, logons, permissões e trabalhos do SQL Server Agent no nível do AG, além do nível da instância. Para obter mais informações, confira O que é um grupo de disponibilidade independente?

Um AG também tem outro componente chamado ouvinte, que permite que aplicativos e usuários finais se conectem sem a necessidade de saber qual instância do SQL Server está hospedando a réplica primária. Cada AG tem seu próprio ouvinte. Embora as implementações do ouvinte sejam ligeiramente diferentes no Windows Server versus Linux, ambas fornecem a mesma funcionalidade e usabilidade. O diagrama a seguir mostra um Grupo de Disponibilidade (AG) baseado no Windows Server que utiliza um Cluster de Failover do Windows Server (WSFC). Um cluster subjacente na camada do sistema operacional é necessário para disponibilidade, seja no Linux ou no Windows Server. O exemplo mostra uma configuração simples com dois servidores ou nós, com um WSFC como o cluster subjacente.

As edições Standard e Enterprise têm valores máximos diferentes para as réplicas. Um AG na edição Standard, conhecido como um grupo de disponibilidade básico, dá suporte a duas réplicas (uma primária e outra secundária) com apenas um banco de dados individual no AG. A Enterprise Edition permite que vários bancos de dados sejam configurados em um só AG e pode ter até nove réplicas no total (uma primária e oito secundárias). A Enterprise Edition também fornece outros benefícios opcionais, como réplicas secundárias para leitura, a capacidade de fazer backups de uma réplica secundária e muito mais.

Quando se trata de disponibilidade, os AGs podem fornecer um failover automático ou manual. O failover automático poderá ocorrer se a movimentação de dados síncronos for configurada e o banco de dados na réplica primária e secundária estiverem em um estado sincronizado. Desde que o ouvinte seja usado e o aplicativo use uma versão compatível do .NET Framework (3.5 com Service Pack 1 ou 4.6.2 e versões posteriores), o failover deverá ser tratado com o mínimo ou nenhum efeito sobre os usuários finais se um ouvinte for utilizado. O failover para tornar a nova réplica primária uma réplica secundária pode ser configurado para ser automático ou manual e geralmente é medido em segundos.

A lista a seguir destaca algumas diferenças com os AGs no Windows Server versus Linux:

Devido à maneira como o cluster subjacente funciona no Linux e no Windows Server, todos os failovers de AG (manual ou automático) são feitos por meio do cluster no Linux. Nas implantações do AG baseadas no Windows Server, os failovers manuais precisam ser feitos por meio do SQL Server. Os failovers automáticos são tratados pelo cluster subjacente no Windows Server e no Linux.

• Para o SQL Server no Linux, você deve configurar um Grupo de Disponibilidade (AG) com no mínimo três réplicas, devido à maneira como o clustering subjacente funciona.

• No Linux, o nome comum usado por cada ouvinte é definido no DNS e não no cluster como se fosse no Windows Server.

O SQL Server 2017 (14.x) introduziu os seguintes recursos e aprimoramentos nos Grupos de Disponibilidade (AGs):

• Tipos de cluster
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Suporte aprimorado do Coordenador de Transação do Distribuidor (DTC) da Microsoft para configurações com base no Windows Server
• Cenários adicionais de escala horizontal de bancos de dados somente leitura (descritos posteriormente neste artigo)

Tipos de clusters do grupo de disponibilidade

O formulário de disponibilidade interna de clustering no Windows Server é habilitado por meio de um recurso chamado Clustering de Failover. Ele permite que você crie um WSFC para ser usado com um AG ou uma FCI. O SQL Server fornece DLLs de recursos compatíveis com clusters que oferecem integração para AGs e FCIs.

O SQL Server em Linux dá suporte a várias tecnologias de clustering. A Microsoft dá suporte aos componentes do SQL Server, enquanto nossos parceiros dão suporte à tecnologia de clustering relevante. Por exemplo, acompanhado do Pacemaker, o SQL Server em Linux dá suporte ao HPE Serviceguard e ao DH2i DxEnterprise como uma solução de cluster.

Um cluster de failover baseado no Windows e uma solução de cluster do Linux são mais semelhantes do que diferentes. Ambos fornecem uma maneira de obter servidores individuais e combiná-los em uma configuração para fornecer disponibilidade e têm conceitos de coisas como recursos, restrições (mesmo se implementadas de maneira diferente), failover e assim por diante.

Por exemplo, a fim de dar suporte ao Pacemaker nas configurações do AG e da FCI, incluindo recursos como o failover automático, a Microsoft fornece ao Pacemaker o pacote mssql-server-ha, que é semelhante, mas não exatamente igual às DLLs de recurso de um WSFC. Uma das diferenças entre um WSFC e o Pacemaker é que não há recursos de nome de rede no Pacemaker. Ele é o componente que ajuda a resumir o nome do ouvinte (ou o nome da FCI) em um WSFC. Use o DNS para resolução de nomes no Linux.

Devido à diferença na stack de cluster, os AGs no SQL Server 2017 (14.x) e versões posteriores precisam lidar com alguns dos metadados que são tratados nativamente por um WSFC. Por exemplo, há três tipos de cluster para um grupo de disponibilidade, que são armazenados nas sys.availability_groups colunas e cluster_type nas cluster_type_desc colunas:

• WSFC
• Externo
• Nenhum

Todos os AGs que exigem alta disponibilidade precisarão usar um cluster subjacente, que, no caso do SQL Server 2017 (14.x) e versões posteriores, significa o WSFC ou um agente de clustering do Linux. Para AGs baseados no Windows Server que usam um WSFC subjacente, o tipo de cluster padrão é WSFC e você não precisa defini-lo. Para AGs baseados em Linux, você deve definir o tipo de cluster como Externo ao criar o AG. A integração a uma solução de cluster externo no Linux é configurada depois que o AG é criado, enquanto em um WSFC, isso é feito no momento da criação.

O tipo de cluster Nenhum pode ser usado com AGs do Windows Server e do Linux. A definição do tipo de cluster como Nenhum significa que o AG não exige um cluster subjacente. Isso significa que o SQL Server 2017 (14.x) é a primeira versão do SQL Server a dar suporte aos AGs sem um cluster, mas a desvantagem é que não há suporte para essa configuração como uma solução de alta disponibilidade.

Se você quiser adicionar apenas cópias extras de leitura de um banco de dados, ou se deseja o que um Grupo de Disponibilidade (AG) fornece em termos de migração e atualizações, mas não quer lidar com a complexidade de um cluster principal ou até mesmo da replicação, considere configurar um Grupo de Disponibilidade com o tipo de cluster definido como Nenhum. Para obter mais informações, consulte as seções Migrações e atualizações e escala de leitura.

A captura de tela a seguir mostra o suporte para os diferentes tipos de tipos de cluster no SSMS (SQL Server Management Studio). Você deve estar executando a versão 17.1 ou posterior. A captura de tela a seguir é da versão 17.2:

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

O SQL Server 2016 (13.x) aumentou o suporte para o número de réplicas síncronas de duas para três na Enterprise Edition. No entanto, se uma réplica secundária estiver sincronizada, mas a outra réplica estiver tendo um problema, não haverá como controlar o comportamento para dizer ao primário para aguardar a réplica mal comportada ou permitir que ela siga em frente. Nesse cenário, a réplica primária ainda pode receber tráfego de gravação mesmo que a réplica secundária não esteja em um estado sincronizado, resultando em perda de dados na réplica secundária.

No SQL Server 2017 (14.x) e versões posteriores, você pode controlar o comportamento do que acontece quando há réplicas síncronas com REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Essa opção funciona da seguinte maneira:

• Há três valores possíveis: 0, 1e 2.
• O valor é o número de réplicas secundárias que devem ser sincronizadas, o que tem implicações para perda de dados, disponibilidade de AG e failover.
• Para WSFCs e um tipo de cluster none, o valor padrão é 0, e você pode defini-lo manualmente como 1 ou 2.
• Para um tipo de cluster externo, o mecanismo de cluster define esse valor por padrão, e você pode substituí-lo manualmente. Para três réplicas síncronas, o valor padrão é 1.

No Linux, você configura o valor para REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, no recurso de AG no cluster. No Windows, você o define por meio do Transact-SQL.

Um valor maior do que 0 garante maior proteção de dados, pois se o número necessário de réplicas secundárias não estiver disponível, o primário não estará disponível até que essa condição seja resolvida. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT também afeta o comportamento de failover, pois o failover automático não pode ocorrer se o número certo de réplicas secundárias não estiver no estado adequado. No Linux, um valor de 0 não permite failover automático. Portanto, ao usar o failover síncrono com failover automático no Linux, você deve definir o valor maior do que 0 para obter failover automático. 0 no Windows Server é o comportamento no SQL Server 2016 (13.x) e versões anteriores.

Suporte aprimorado ao Coordenador de Transações Distribuídas da Microsoft

Antes do SQL Server 2016 (13.x), a única maneira de obter disponibilidade no SQL Server para aplicativos que exigem transações distribuídas, que usam DTC sob as coberturas, era implantar FCIs. Uma transação distribuída pode ser feita de duas maneiras:

• Uma transação que abrange mais de um banco de dados na mesma instância do SQL Server.
• Uma transação que abrange mais de uma instância do SQL Server ou possivelmente envolve uma fonte de dados não SQL Server.

O SQL Server 2016 (13.x) introduziu o suporte parcial do DTC com os AGs que abordaram o último cenário. O SQL Server 2017 (14.x) conclui a história dando suporte a ambos os cenários com o DTC.

No SQL Server 2017 (14.x) e em versões posteriores, você pode adicionar suporte de DTC a um AG depois que ele for criado. No SQL Server 2016 (13.x), você só pode habilitar o suporte a DTC ao criar o AG.

Instâncias de cluster de failover

As FCIs (instâncias de cluster de failover) fornecem disponibilidade para toda a instalação do SQL Server, conhecida como uma instância. Com as FCIs, se o servidor subjacente encontrar um problema, tudo dentro da instância será movido para outro servidor, incluindo bancos de dados, trabalhos do SQL Server Agent, servidores vinculados e muito mais. Todas as FCIs exigem algum armazenamento compartilhado, mesmo que seja definido pela rede. Um nó pode operar e possuir os recursos da FCI a qualquer momento. No diagrama a seguir, o primeiro nó do cluster possui a FCI. Ele também possui os recursos de armazenamento compartilhado associados a ele, conforme indicado pela linha sólida no diagrama para o armazenamento.

Após um failover, a propriedade é alterada, conforme mostrado no diagrama a seguir:

Uma FCI não tem perda de dados, mas o armazenamento compartilhado subjacente é um único ponto de falha, pois há uma cópia dos dados. Para ter cópias redundantes de banco de dados, combine FCIs com outro método de disponibilidade, como um Grupo de Disponibilidade (AG) ou envio de logs. O outro método deve utilizar armazenamento que seja fisicamente independente da FCI. Quando a FCI faz failover para outro nó, ela para em um nó e começa em outro. Esse processo é semelhante a desligar um servidor e ativá-lo.

Uma FCI passa pelo processo normal de recuperação. Ele avança todas as transações que precisam ser avançadas e reverte todas as transações incompletas. Portanto, o banco de dados é consistente de um ponto de dados até o momento da falha ou failover manual, portanto, não há perda de dados. Os bancos de dados só estão disponíveis após a conclusão da recuperação. O tempo de recuperação depende de muitos fatores e geralmente é mais longo do que o failover de um AG. A desvantagem é que, quando você faz failover de um AG, pode haver tarefas extras necessárias para tornar um banco de dados utilizável, como habilitar um trabalho do SQL Server Agent.

Como um AG, as FCIs eliminam o nó do cluster subjacente que o está hospedando. Uma FCI sempre mantém o mesmo nome. Aplicativos e usuários finais nunca se conectam aos nós. Em vez disso, eles usam o nome exclusivo atribuído à FCI. Uma FCI pode participar de um AG como uma das instâncias que hospedam uma réplica primária ou secundária.

A lista a seguir destaca algumas diferenças com FCIs no Windows Server versus Linux:

• No Windows Server, uma FCI faz parte do processo de instalação. Você configura uma FCI no Linux depois de instalar o SQL Server.
• O Linux dá suporte apenas a uma única instalação do SQL Server por host, portanto, todas as FCIs são uma instância padrão. O Windows Server dá suporte a até 25 FCIs por WSFC.
• O nome comum usado pelas FCIs no Linux é definido no DNS e deve ser o mesmo que o recurso criado para a FCI.

Envio de logs

Se os objetivos de ponto de recuperação e tempo de recuperação forem mais flexíveis ou os bancos de dados não forem altamente críticos, o envio de logs será outro recurso de disponibilidade comprovado no SQL Server. Com base nos backups nativos do SQL Server, o processo de envio de logs automaticamente gera os backups de log de transações, copia-os em uma ou mais instâncias conhecidas como uma espera passiva e aplica automaticamente os backups de log de transações a esse modo de espera. O envio de logs usa trabalhos do SQL Server Agent para automatizar o processo de backup, cópia e aplicação dos backups de log de transações.

A maior vantagem de usar o envio de logs é que ele é responsável por erros humanos, pois você pode atrasar a aplicação de logs de transações. Por exemplo, se alguém emitir um UPDATE sem uma cláusula WHERE, o sistema de backup pode não ter a alteração, permitindo que você alterne para ele enquanto repara o sistema principal. Embora o envio de logs seja fácil de configurar, alternar do primário para um modo de espera quente, conhecido como uma alteração de função, é sempre manual. Você inicia uma alteração de função por meio do Transact-SQL e, como um AG, deve sincronizar manualmente todos os objetos não capturados no log de transações. Você precisa configurar o envio de logs por banco de dados, enquanto um único AG pode conter vários bancos de dados.

Ao contrário de um AG ou de uma FCI, o envio de logs não tem abstração para uma alteração de função, com a qual os aplicativos precisam conseguir lidar. Podem ser empregadas técnicas como um alias DNS (CNAME), mas há vantagens e desvantagens, como o tempo necessário que o DNS leva para atualizar após a troca.

Recuperação de desastre

Quando seu local de disponibilidade primária passa por um evento catastrófico, como um terremoto ou uma enchente, a empresa deve estar preparada para que seus sistemas fiquem online em outro lugar. Esta seção aborda como os recursos de disponibilidade do SQL Server podem ajudar na continuidade dos negócios.

Grupos de disponibilidade

Um dos benefícios dos AGs é que você configura a alta disponibilidade e a recuperação de desastre usando um único recurso. Sem a necessidade de garantir que o armazenamento compartilhado também seja altamente disponível, é mais fácil ter réplicas que são locais em um data center para a alta disponibilidade e remotas em outros dados centers para a recuperação de desastre, cada uma com um armazenamento separado. Ter cópias extras do banco de dados é a desvantagem para garantir a redundância. Um exemplo de um AG que abrange vários data centers é mostrado no diagrama a seguir. Uma réplica primária é responsável por manter todas as réplicas secundárias sincronizadas.

Fora de um AG cujo tipo de cluster é None, um AG requer que todas as réplicas sejam parte do mesmo cluster subjacente, seja ele um WSFC ou uma solução de cluster externo. No diagrama anterior, o WSFC é estendido para funcionar em dois data centers diferentes, o que adiciona complexidade independentemente da plataforma (Windows Server ou Linux). Transferir clusters em distância adiciona complexidade.

Introduzido no SQL Server 2016 (13.x), um grupo de disponibilidade distribuído permite que um AG abranja AGs configurados em clusters diferentes. Os AGs distribuídos separam a necessidade de que todos os nós participem do mesmo cluster, o que facilita a configuração de recuperação de desastre. Para obter mais informações sobre os AGs distribuídos, confira Grupos de disponibilidade distribuídos.

Instâncias de cluster de failover

Você pode usar FCIs para recuperação de desastres. Assim como acontece com um AG normal, você deve estender o mecanismo de cluster subjacente a todos os locais, o que adiciona complexidade. Para FCIs, você também precisa considerar o armazenamento compartilhado. Os sites primário e secundário precisam de acesso aos mesmos discos. Para garantir que o armazenamento usado pela FCI exista em ambos os sites, use um método externo, como a funcionalidade fornecida pelo fornecedor de armazenamento na camada de hardware. Como alternativa, use o Storage Replica do Windows Server.

Envio de logs

O envio de logs é um dos métodos mais antigos para fornecer recuperação de desastre para bancos de dados do SQL Server. O envio de logs geralmente é usado com AGs e FCIs para fornecer recuperação de desastre econômica e mais simples, em que outras opções podem ser desafiadoras devido a ambiente, habilidades administrativas ou orçamento. Semelhante ao histórico de alta disponibilidade para envio de logs, muitos ambientes atrasam o carregamento de um log de transações para considerar o erro humano.

Migrações e atualizações

Quando uma organização implanta novas instâncias ou atualiza as antigas, ela não pode tolerar interrupções prolongadas. Esta seção discute como os recursos de disponibilidade do SQL Server podem ser usados para minimizar o tempo de inatividade em uma alteração de arquitetura planejada, comutador de servidor, alteração de plataforma (como Windows Server para Linux ou vice-versa) ou durante a aplicação de patch.

Grupos de disponibilidade

Você pode atualizar uma instância existente que contém um ou mais AGs (grupos de disponibilidade) em vigor para versões posteriores do SQL Server. Embora essa atualização exija algum tempo de inatividade, ela pode ser minimizada com a quantidade certa de planejamento.

Se você quiser migrar para novos servidores sem alterar a configuração (incluindo o sistema operacional ou a versão do SQL Server), adicione esses servidores como nós ao cluster subjacente existente e adicione-os ao AG. Depois que a réplica ou as réplicas estiverem no estado adequado, realize a transferência manualmente para um novo servidor. Em seguida, remova os servidores antigos do AG e desative-os.

Os grupos de disponibilidade distribuídos também são outro método para migrar para uma nova configuração ou atualizar o SQL Server. Como um AG distribuído dá suporte a diferentes AGs subjacentes em diferentes arquiteturas, você pode alterar do SQL Server 2019 (15.x) em execução no Windows Server 2019 para o SQL Server 2025 (17.x) em execução no Windows Server 2025.

Por fim, os AGs com um tipo de cluster none são úteis para migração ou atualização. Você não pode misturar tipos de cluster em uma configuração típica de AG, portanto, todas as réplicas devem ter o tipo None. Um AG distribuído pode ser usado para abranger os AGs configurados com diferentes tipos de clusters. Esse método também tem suporte em todas as plataformas de sistema operacional diferentes.

Todas as variantes de AGs para migrações e atualizações permitem que a sincronização de dados, a parte mais demorada do trabalho, seja distribuída ao longo do tempo. Quando chega a hora de iniciar a migração para a nova configuração, a mudança é uma breve interrupção, em comparação com um longo período de inatividade em que todo o trabalho, incluindo a sincronização de dados, precisa ser concluído.

Os AGs podem proporcionar um tempo de inatividade mínimo durante a aplicação de patches do sistema operacional subjacente ao realizar o failover manual do primário para uma réplica secundária enquanto a atualização está em andamento. Do ponto de vista do sistema operacional, fazer isso é mais comum no Windows Server, pois o serviço do sistema operacional subjacente pode exigir uma reinicialização. Às vezes, o patching do Linux pode demandar uma reinicialização, mas é menos comum.

Outra maneira de minimizar o tempo de inatividade é corrigir instâncias do SQL Server que participam de um grupo de disponibilidade, dependendo de quão complexa é a arquitetura do AG. Corrija uma réplica secundária primeiro. Depois que o número certo de réplicas for corrigido, faça failover manualmente da réplica primária para outro nó para fazer a atualização. Atualize as réplicas secundárias restantes neste momento.

Instâncias de cluster de failover

As FCIs sozinhas não podem ajudar com uma migração ou atualização tradicional. Você precisa configurar um Grupo de Disponibilidade (AG) ou envio de registros para os bancos de dados na FCI e considerar todos os outros objetos. No entanto, a FCI no Windows Server ainda é uma opção popular para quando você precisa aplicar correções nos Windows Servers subjacentes. Quando você inicia um failover manualmente, a breve interrupção substitui ter a instância indisponível durante todo o tempo em que o Windows Server está sendo atualizado.

Você pode atualizar uma FCI em vigor para versões posteriores do SQL Server. Para obter mais informações, consulte Atualizar uma instância de cluster de failover.

Envio de logs

O envio de logs ainda é uma opção popular para migrar e atualizar bancos de dados. Semelhante aos AGs, mas desta vez usando o log de transações como o método de sincronização, a propagação de dados pode ser iniciada bem antes da troca do servidor. No momento da troca, depois que todo o tráfego for interrompido na origem, um log de transações final precisará ser obtido, copiados e aplicado à nova configuração. Nesse momento, o banco de dados pode ser colocado online.

O envio de logs geralmente é mais tolerante a redes mais lentas e, embora o comutador possa ser um pouco mais longo do que um feito usando um AG ou um AG distribuído, ele geralmente é medido em minutos, não horas, dias ou semanas.

Semelhante aos AGs, o envio de logs pode fornecer uma maneira de alternar para outro servidor durante uma janela de manutenção.

Outros métodos de implantação do SQL Server e disponibilidade

Há dois outros métodos de implantação do SQL Server no Linux: contêineres e uso do Azure (ou outro provedor de nuvem pública). A necessidade geral de disponibilidade existe independentemente de como o SQL Server é implantado. Esses dois métodos têm algumas considerações especiais ao tornar o SQL Server altamente disponível.

Opções de HA/DR e contêineres do SQL Server

A implantação de contêiner do SQL Server é uma maneira de simplificar o provisionamento, o dimensionamento e o gerenciamento do ciclo de vida do SQL Server entre ambientes. Um contêiner é uma imagem pronta para execução completa do SQL Server.

Dependendo da plataforma de contêiner, por exemplo, ao usar um orquestrador de contêineres como o Kubernetes, se o contêiner for perdido, ele poderá ser implantado novamente e anexado ao armazenamento compartilhado que foi usado. Embora isso forneça alguma resiliência, há algum tempo de inatividade associado à recuperação de banco de dados e não está realmente altamente disponível como seria se estivesse usando um grupo de disponibilidade ou FCI.

Se você estiver procurando configurar a alta disponibilidade para os contêineres do SQL Server implantados em plataformas de Kubernetes ou não Kubernetes, use o DH2i DxEnterprise como uma das soluções de clustering, com base no qual você poderá configurar um AG no modo de alta disponibilidade. Essa opção fornece o RPO (objetivo de ponto de recuperação) e o RTO (objetivo de tempo de recuperação) esperados de uma solução de alta disponibilidade.

Implantação de VM baseada em Linux

O Linux pode ser implantado com SQL Server em Máquinas Virtuais do Azure Linux. Assim como acontece com as instalações baseadas no local, uma instalação com suporte requer o uso de isolamento de um nó com falha externo ao próprio agente de cluster. A cerca de nó é fornecida por meio de agentes de disponibilidade de isolamento. Algumas distribuições os enviam como parte da plataforma, enquanto outras contam com fornecedores externos de hardware e software. Verifique com sua distribuição do Linux preferida para ver quais formas de isolamento de nó são fornecidas para que uma solução com suporte possa ser implantada na nuvem pública.

Os guias de instalação do SQL Server em Linux estão disponíveis para as seguintes distribuições:

• Início Rápido: instalar o SQL Server e criar um banco de dados no Red Hat
• Início Rápido: instalar o SQL Server e criar um banco de dados no Ubuntu
• Início Rápido: instalar o SQL Server e criar um banco de dados no SUSE Linux Enterprise Server

Escala de leitura

As réplicas secundárias têm a capacidade de serem usadas para consultas somente leitura. Há duas maneiras que podem ser alcançadas com um AG:

• Permitir acesso direto ao secundário
• Configurando o roteamento somente leitura, que requer o uso do 'listener'. O SQL Server 2016 (13.x) introduziu a capacidade de balancear a carga de conexões somente leitura por meio do ouvinte usando um algoritmo de round robin, permitindo que as solicitações somente leitura sejam distribuídas entre todas as réplicas de leitura.

O dimensionamento de cópias legíveis de um banco de dados por meio de AGs foi introduzido pela primeira vez com AGs distribuídos no SQL Server 2016 (13.x). Esse recurso oferece cópias somente leitura do banco de dados não apenas localmente, mas também regionalmente e globalmente, com configuração mínima. Essa configuração reduz o tráfego de rede e a latência fazendo com que as consultas são executadas localmente. Cada réplica primária de um AG pode semear dois outros AGs, mesmo que não seja a cópia de leitura/gravação completa, e cada AG distribuído pode dar suporte a até 27 cópias legíveis dos dados.

No SQL Server 2017 (14.x) e versões posteriores, você pode criar uma solução quase em tempo real, somente leitura, com AGs configurados com um tipo de cluster none. Se o seu objetivo for usar AGs para réplicas secundárias legíveis, e não para disponibilidade, essa abordagem elimina a complexidade de utilizar um WSFC ou uma solução de cluster externo no Linux. Ele fornece os benefícios facilmente compreensíveis de um AG em um método de implantação mais simples.

O único grande ponto de atenção é que, devido à ausência de um cluster subjacente com um tipo de cluster Nenhum, configurar o roteamento somente leitura é um pouco diferente. Da perspectiva do SQL Server, um ouvinte ainda é necessário para encaminhar as solicitações, embora não exista nenhum cluster. Em vez de configurar um ouvinte tradicional, use o endereço IP ou o nome da réplica primária. Em seguida, a réplica primária roteia as solicitações somente leitura.

Tecnicamente, um modo de espera de envio de logs pode ser configurado para uso legível restaurando o banco de dados WITH STANDBY. No entanto, como os logs de transações exigem o uso exclusivo do banco de dados para restauração, isso significa que usuários não podem acessar o banco de dados enquanto isso acontece. Isso tornará o envio de logs uma solução abaixo do ideal, especialmente se os dados quase em tempo real forem necessários.

Ao contrário da replicação transacional em que todos os dados estão ativos, cada réplica secundária em um cenário de escala de leitura é uma cópia exata do primário. A réplica não está em um estado em que índices exclusivos podem ser aplicados. Se algum índice for necessário para relatórios ou se os dados precisarem ser manipulados, você deverá criar esses índices nos bancos de dados na réplica primária. Se você precisar dessa flexibilidade, a replicação será uma solução melhor para dados legíveis.

Interoperabilidade de distribuição do Linux e de multiplataforma

Com o suporte do SQL Server no Windows Server e no Linux, esta seção aborda como eles podem trabalhar juntos para disponibilidade, além de outras finalidades. Ele também aborda a história de soluções que incorporam mais de uma distribuição do Linux.

Grupos de disponibilidade distribuídos

Os AGs distribuídos foram projetados para abranger as configurações do AG, sejam esses dois clusters subjacentes abaixo dos AGs dois WSFCs diferentes, distribuições do Linux ou um esteja em um WSFC e o outro no Linux. Um AG distribuído é o método principal de ter uma solução de plataforma cruzada. Um AG distribuído também é a principal solução para migrações, como a conversão de uma infraestrutura do SQL Server baseada no Windows Server para uma baseada em Linux, se isso for o que a sua empresa deseja fazer. Conforme observado anteriormente, os AGs, especialmente os distribuídos, minimizariam o tempo em que um aplicativo estaria indisponível para uso. Um exemplo de um AG distribuído que abrange um WSFC e o Pacemaker é mostrado no diagrama a seguir:

Se você configurar um AG com um tipo de cluster None, ele poderá abranger o Windows Server e o Linux e várias distribuições do Linux. Como essa configuração não é verdadeira alta disponibilidade, não a use para implantações críticas de missão. Em vez disso, use-o para ampliação de leitura ou cenários de migração e atualização.

Envio de logs

O envio de logs é baseado em backup e restauração, portanto, não há diferenças nos bancos de dados, estruturas de arquivos e outros elementos para SQL Server no Windows Server versus SQL Server no Linux. Você pode configurar o envio de logs entre uma instalação do SQL Server baseada no Windows Server e uma do Linux e entre distribuições do Linux. Todo o resto permanece o mesmo.

Assim como acontece com um AG, o envio de logs não funciona quando o servidor de origem está em uma versão principal mais alta do SQL Server, em relação a um destino que está em uma versão principal mais baixa.

Resumo

Você pode disponibilizar instâncias e bancos de dados do SQL Server 2017 (14.x) e versões posteriores altamente disponíveis usando os mesmos recursos no Windows Server e no Linux. Além dos cenários de disponibilidade padrão de alta disponibilidade local e recuperação de desastre, você pode minimizar o tempo de inatividade associado a atualizações e migrações usando os recursos de disponibilidade no SQL Server. Os AGs também podem fornecer cópias extras de um banco de dados como parte da mesma arquitetura para escalonar cópias disponíveis para leitura. Se você estiver implantando uma nova solução ou considerando fazer uma atualização, o SQL Server tem a disponibilidade e a confiabilidade de que você precisa.

Conteúdo relacionado

• Configurar o grupo de disponibilidade do SQL Server para alta disponibilidade no Linux
• Failover do grupo de disponibilidade Always On no Linux