Continuidade de negócios e recuperação de banco de dados - SQL Server no Linux

Aplica-se a:SQL Server em Linux

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

Todos os que implementam SQL Server precisam de garantir que todas as instâncias críticas de SQL Server e as bases de dados nelas estão disponíveis quando o negócio e os utilizadores finais precisam, seja durante o horário comercial normal ou 24 horas por dia. O objetivo é manter o negócio funcionando com o mínimo ou nenhuma interrupção. Esse conceito também é conhecido como continuidade de negócios.

O SQL Server 2017 (14.x) e versões posteriores introduziram funcionalidades e melhorias para a disponibilidade. A maior novidade é o suporte para SQL Server em distribuições Linux. Para obter uma lista completa dos novos recursos do SQL Server, consulte os seguintes artigos:

Este artigo foca-se nos cenários de disponibilidade no SQL Server 2017 (14.x) e versões posteriores, bem como nas novas e melhoradas funcionalidades de disponibilidade. Os cenários incluem híbridos que podem abranger implantações SQL Server tanto no Windows Server como no Linux, e outros que podem aumentar o número de cópias legíveis de uma base de dados.

Embora este artigo não aborde opções de disponibilidade externas ao SQL Server (como virtualização), tudo o que aqui é discutido aplica-se a instalações SQL Server dentro de uma máquina virtual convidada, seja na cloud pública ou alojada por um servidor hipervisor local.

Cenários SQL Server que utilizam funcionalidades de disponibilidade

Podes usar grupos de disponibilidade Always On, instâncias de clusters de failover e registar o envio de diferentes formas, e não só pela disponibilidade. Existem quatro formas principais de utilizar as funcionalidades de disponibilidade:

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

As secções seguintes descrevem as características relevantes para cada cenário. Uma funcionalidade não abordada é a replicação do SQL Server. Embora a replicação do SQL Server não seja oficialmente designada como uma funcionalidade de disponibilidade sob o guarda-chuva do Always On, é frequentemente usada para tornar os dados redundantes em certos cenários. A replicação de mesclagem não é suportada para o SQL Server no Linux. Para obter mais informações, consulte Replicação do SQL Server no Linux.

Alta disponibilidade

É importante garantir que as instâncias ou bases de dados do SQL Server estão disponíveis caso ocorra um problema local a um centro de dados ou a uma única região na cloud. Esta secção explica como as funcionalidades 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 grupos de disponibilidade (AGs) fornecem proteção ao nível da base de dados enviando cada transação de uma base de dados para outra instância, ou réplica, que contém uma cópia dessa base de dados num estado especial. Pode implementar um AG em edições Standard ou Enterprise. As instâncias que participam de um AG podem ser instâncias autónomas ou instâncias de cluster de failover (FCIs, descritas na próxima seção). Como as transações são enviadas para uma réplica à medida que ocorrem, recomenda-se o uso de Grupos de Disponibilidade (AGs) quando há necessidade de objetivos de menor ponto de recuperação e tempo de recuperação. A movimentação de dados entre réplicas pode ser síncrona ou assíncrona, com a edição Enterprise permitindo até três réplicas (incluindo a principal) como síncronas. Um AG tem uma cópia de leitura/gravação completa do banco de dados que está na réplica primária, enquanto todas as réplicas secundárias não podem receber transações diretamente de usuários finais ou aplicativos.

Antes do SQL Server 2022 (16.x), os AGs só forneciam proteção no nível do banco de dados, e não no nível da instância. Tudo o que não estiver registado no registo de transações ou configurado na base de dados deve ser sincronizado manualmente para cada réplica secundária. Alguns exemplos de objetos que devem ser sincronizados manualmente são logons no nível da instância, servidores vinculados e trabalhos do SQL Server Agent.

No SQL Server 2022 (16.x) e versões posteriores, pode gerir objetos de metadados incluindo utilizadores, logins, permissões e trabalhos do SQL Server Agent ao nível da AG, além do nível da instância. Para obter mais informações, consulte O que é um grupo de disponibilidade contido?

Um AG também tem outro componente chamado ouvinte, que permite que aplicativos e usuários finais se conectem sem precisar saber qual instância do SQL Server está hospedando a réplica primária. Cada AG tem o seu próprio ouvinte. Embora as implementações do ouvinte sejam ligeiramente diferentes no Windows Server em comparação com o Linux, ambas oferecem a mesma funcionalidade e usabilidade. O diagrama seguinte mostra um AG baseado em 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 cluster subjacente.

As edições Standard e Enterprise têm máximos diferentes quando se trata de réplicas. Um AG na edição Standard, conhecido como um grupo de disponibilidade básica, suporta duas réplicas (uma primária e uma secundária) com apenas um único banco de dados no AG. A edição Enterprise não só permite que vários bancos de dados sejam configurados em um único AG, mas também pode ter até nove réplicas totais (uma primária e oito secundárias). A edição Enterprise também oferece outros benefícios opcionais, como réplicas secundárias legíveis, a capacidade de fazer backups de uma réplica secundária e muito mais.

Quando se trata de disponibilidade, as AGs podem fornecer failover automático ou manual. O failover automático pode ocorrer se a movimentação de dados síncrona estiver configurada e o banco de dados na réplica primária e secundária estiver em um estado sincronizado. Desde que o ouvinte seja utilizado e a aplicação utilize uma versão suportada do .NET Framework (3.5 com Service Pack 1, ou 4.6.2 e versões posteriores), o failover deve ser tratado com efeito mínimo ou nulo nos utilizadores finais se for utilizado um ouvinte. A mudança para uma réplica secundária para torná-la a nova réplica primária pode ser configurada para ser automática ou manual e geralmente é medida em segundos.

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

Devido à forma como o cluster subjacente funciona no Linux e Windows Server, todos os failovers AG (manuais ou automáticos) são feitos através do cluster no Linux. Em implantações AG baseadas no Windows Server, os failovers manuais devem ser feitos via SQL Server. Os failovers automáticos são manipulados pelo cluster subjacente no Windows Server e no Linux.

• Para SQL Server no Linux, deves configurar um AG com pelo menos três réplicas, devido à forma como funciona o clustering subjacente.

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

O SQL Server 2017 (14.x) introduziu as seguintes funcionalidades e melhorias aos AGs:

• Tipos de cluster
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Suporte avançado do Microsoft Distributor Transaction Coordinator (DTC) para configurações baseadas no Windows Server
• Cenários de expansão adicionais para bancos de dados somente leitura (descritos mais adiante neste artigo)

Tipos de clusters de grupos de disponibilidade

A funcionalidade de disponibilidade integrada do clustering no Windows Server é habilitada por meio de um recurso chamado clusterização de failover. Ele permite que você construa um WSFC para ser usado com um AG ou FCI. O SQL Server disponibiliza DLLs de recursos compatíveis com clusters que fornecem integração para AGs e FCIs.

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

Um cluster de failover baseado no Windows e uma solução de cluster Linux são mais semelhantes do que diferentes. Ambos fornecem uma maneira de pegar 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 forma diferente), failover e assim por diante.

Por exemplo, para oferecer suporte ao Pacemaker em configurações AG e FCI, incluindo funcionalidades como o failover automático, a Microsoft fornece o pacote mssql-server-ha, que é semelhante, mas não exatamente igual aos DLLs de recurso num WSFC, para o Pacemaker. Uma das diferenças entre um WSFC e um Pacemaker é que não há nenhum recurso de nome de rede no Pacemaker, que é o componente que ajuda a abstrair o nome do ouvinte (ou o nome do FCI) em um WSFC. Usa DNS para resolução de nomes no Linux.

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

• WSFC
• Externa
• Nenhum

Todos os AGs que exigem alta disponibilidade devem usar um cluster subjacente, que no caso do SQL Server 2017 (14.x) e versões posteriores significa WSFC ou um agente de cluster Linux. Para AGs baseados em Windows Server que usam um WSFC subjacente, o tipo de cluster padrão é WSFC e não precisas de o definir. Para Grupos de Disponibilidade (AGs) baseados em Linux, deve definir o tipo de cluster como Externo ao criar o AG. A integração com uma solução de cluster externo no Linux é configurada após a criação do AG, enquanto em um WSFC, é feita no momento da criação.

Um tipo de cluster de Nenhum pode ser usado com Windows Server e Linux AGs. Definir o tipo de cluster como Nenhum significa que o AG não requer um cluster subjacente. Isso significa que o SQL Server 2017 (14.x) é a primeira versão do SQL Server a oferecer suporte a AGs sem um cluster, mas a contrapartida é que essa configuração não tem suporte como uma solução de alta disponibilidade.

Se apenas desejar adicionar cópias extra de uma base de dados em modo de só leitura, ou se pretende as funcionalidades que um AG fornece para migração e atualizações, mas não quer lidar com a complexidade de um cluster subjacente ou mesmo a replicação, considere configurar um AG com um tipo de cluster None. 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 SQL Server Management Studio (SSMS). Você deve estar executando a versão 17.1 ou posterior. A captura de ecrã seguinte é da versão 17.2:

SECUNDÁRIOS_SINCRONIZADOS_REQUERIDOS_PARA_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 edição Enterprise. No entanto, se uma réplica secundária estiver sincronizada mas a outra réplica tiver um problema, não há forma de controlar o comportamento para dizer ao primário para esperar pela réplica que não se comporta bem, ou para permitir que ela avance. Neste cenário, a réplica primária pode ainda receber tráfego de escrita mesmo que a réplica secundária não esteja num 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_COMMITo . Esta opção funciona da seguinte forma:

• Existem três valores possíveis: 0, 1, e 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 do Grupo de Disponibilidade (AG) e failover.
• Para WSFCs e um tipo de cluster de Nenhum, o valor padrão é 0, e pode defini-lo manualmente para 1 ou 2.
• Para um tipo de cluster Externo, o mecanismo do cluster define este valor por defeito, e pode sobrescrevê-lo manualmente. Para três réplicas síncronas, o valor padrão é 1.

No Linux, você deve configurar o valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT no recurso AG no cluster. No Windows, configura-se através do Transact-SQL.

Um valor superior a 0 garante uma maior proteção de dados, porque se o número necessário de réplicas secundárias não estiver disponível, a primária não estará disponível até que essa condição seja resolvida. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Também afeta o comportamento do failover, pois o failover automático não pode ocorrer se o número correto de réplicas secundárias não estiver no estado correto. No Linux, um valor de 0 não permite o failover automático, por isso, ao usar o failover síncrono com automático no Linux, deve definir o valor acima de 0 para conseguir o failover automático. 0 no Windows Server é o comportamento observado no SQL Server 2016 (13.x) e versões anteriores.

Suporte aprimorado ao Microsoft Distributed Transaction Coordinator

Antes do SQL Server 2016 (13.x), a única forma de obter disponibilidade no SQL Server para aplicações que requerem transações distribuídas, que usam DTC por baixo, era implementar FCIs. Uma transação distribuída pode ser feita de duas maneiras:

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

O SQL Server 2016 (13.x) introduziu suporte parcial para DTC com AGs (Grupos de Disponibilidade) que cobriam este último cenário. O SQL Server 2017 (14.x) completa a história dando suporte a ambos os cenários com DTC.

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

Instâncias de cluster com tolerância a falhas

As instâncias de cluster de failover (FCIs) fornecem disponibilidade para toda a instalação do SQL Server, conhecida como instância. Com as FCIs, se o servidor subjacente encontrar um problema, tudo dentro da instância é transferido para outro servidor, incluindo bases de dados, trabalhos SQL Server Agent, servidores ligados e mais. Todas as FCIs exigem algum armazenamento partilhado, mesmo que seja definido pela rede. Um nó pode executar e possuir os recursos da FCI a qualquer momento. No diagrama seguinte, o primeiro nó do cluster detém a FCI. Também detém os recursos de armazenamento partilhados associados, que a linha contínua para o armazenamento indica.

Após um failover, o proprietário muda, conforme mostrado no diagrama seguinte:

Uma FCI não tem perda de dados, mas o armazenamento partilhado subjacente é um único ponto de falha, pois existe uma cópia dos dados. Para ter cópias redundantes de bases de dados, combine as FCIs com outro método de disponibilidade, como um AG ou transporte de registos. O outro método deve usar armazenamento fisicamente separado do FCI. Quando a FCI faz failover para outro nó, para num nó e começa noutro. Este processo é semelhante a desligar e ligar um servidor.

Um FCI segue o processo normal de recuperação. Aplica quaisquer transações que precisem de ser avançadas e reverte quaisquer transações incompletas. Assim, a base de dados é consistente desde um ponto de dados até ao momento da falha ou do failover manual, pelo que não há perda de dados. As bases 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 falhar num 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 abstraem qual nó do cluster subjacente que o hospeda. Uma FCI mantém sempre o mesmo nome. As aplicações e os utilizadores finais nunca se ligam aos nós. Em vez disso, utilizam o nome único atribuído à FCI. Uma FCI pode participar num 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. Configura-se uma FCI no Linux depois de instalar o SQL Server.
• O Linux só suporta uma única instalação de SQL Server por host, portanto, todas as FCIs são instâncias padrão. O Windows Server suporta 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 (RPO) e de tempo de recuperação (RTO) forem mais flexíveis ou se as bases de dados não forem altamente críticas para a missão, o Log Shipping é outra funcionalidade comprovada de disponibilidade no SQL Server. Com base nos backups nativos do SQL Server, o processo de envio de logs gera automaticamente backups de log de transações, copia-os para uma ou mais instâncias conhecidas como standby quente e aplica automaticamente os backups de log de transações a esse standby. O transporte de logs utiliza trabalhos do SQL Server Agent para automatizar o processo de fazer backup, copiar e aplicar os backups de logs de transações.

A maior vantagem de usar o envio de registos é que tem em conta o erro humano, porque pode atrasar a aplicação dos registos de transações. Por exemplo, se alguém emitir um UPDATE sem uma cláusula WHERE, o standby pode não ter a alteração, por isso é possível alternar para ele enquanto se repara o sistema principal. Embora o envio de logs seja fácil de configurar, a mudança do primário para um sistema em espera ativa, conhecido como mudança de funções, é sempre manual. Inicias uma alteração de função via Transact-SQL e, tal como num AG, tens de sincronizar manualmente todos os objetos não capturados no registo de transações. É necessário configurar o envio de registos por base de dados, enquanto um único AG pode conter várias bases de dados.

Ao contrário de um AG ou FCI, o transporte de logs não possui um mecanismo de abstração para a alteração de função, que os aplicativos devem conseguir gerir. Técnicas como um alias DNS (CNAME) podem ser empregadas, mas há prós e contras, como o tempo que leva para o DNS ser atualizado após a mudança.

Recuperação após desastre

Quando seu local de disponibilidade principal sofre um evento catastrófico, como um terremoto ou inundação, a empresa deve estar preparada para ter seus sistemas on-line em outro lugar. Esta secção aborda como as funcionalidades de disponibilidade do SQL Server podem ajudar na continuidade do negócio.

Grupos de disponibilidade

Uma das vantagens dos AGs é que configura tanto a alta disponibilidade como a recuperação de desastres usando uma única funcionalidade. Sem a necessidade de garantir que o armazenamento compartilhado também esteja altamente disponível, é muito mais fácil ter réplicas locais em um data center para alta disponibilidade e remotas em outros data centers para recuperação de desastres, cada uma com armazenamento separado. Ter cópias extras do banco de dados é a contrapartida para garantir 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 que possui um tipo de cluster como Nenhum, é exigido que, em um AG, todas as réplicas estejam integradas ao mesmo cluster subjacente, independentemente de ser uma solução WSFC ou um cluster externo. No diagrama anterior, o WSFC está esticado para funcionar em dois centros de dados diferentes, o que acrescenta complexidade independentemente da plataforma (Windows Server ou Linux). Esticar clusters através da 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 desacoplam o requisito de que todos os nós participem do mesmo cluster, facilitando a configuração da recuperação de desastres e tornando-a bem mais fácil. Para obter mais informações sobre AGs distribuídos, consulte Grupos de disponibilidade distribuídos.

Instâncias de cluster com tolerância a falhas

Pode usar FCIs para recuperação de desastres. Tal como num AG normal, é necessário estender o mecanismo subjacente do cluster a todas as localizações, o que acrescenta complexidade. Para FCIs, também é preciso considerar o armazenamento partilhado. Os locais primário e secundário precisam de acesso aos mesmos discos. Para garantir que o armazenamento utilizado pela FCI existe em ambos os locais, utilize-se um método externo, como funcionalidades fornecidas pelo fornecedor de armazenamento na camada de hardware. Alternativamente, use o Storage Replica no Windows Server.

Envio de logs

O envio de registos é um dos métodos mais antigos para fornecer recuperação de desastres para bases de dados SQL Server. O envio de logs é frequentemente usado com AGs e FCIs para fornecer recuperação de desastres mais simples e econômica, onde outras opções podem ser desafiadoras devido ao ambiente, habilidades administrativas ou orçamento. Semelhante à estratégia de alta disponibilidade para o envio de registos, muitos ambientes atrasam o carregamento de um registo de transações para se precaver contra erros humanos.

Migrações e upgrades

Quando uma organização implementa novas instâncias ou atualiza as antigas, não tolera falhas longas. 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, mudança de servidor, alteração de plataforma (como Windows Server para Linux ou vice-versa) ou durante a aplicação de patches.

Grupos de disponibilidade

Pode atualizar uma instância existente que contenha um ou mais grupos de disponibilidade (AGs) existentes, para versões posteriores do SQL Server. Embora esta atualização exija algum tempo de inatividade, pode ser minimizada com o planeamento adequado.

Se quiseres migrar para novos servidores sem alterar a configuração (incluindo o sistema operativo ou a versão do SQL Server), adiciona esses servidores como nós ao cluster subjacente existente e depois adiciona-os ao AG. Quando a réplica ou réplicas estiverem no estado correto, faça a mudança manual para um novo servidor. Depois, remova os servidores antigos do AG e desative-os.

AGs 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 suporta diferentes AGs subjacentes em diferentes arquiteturas, pode mudar do SQL Server 2019 (15.x) a correr no Windows Server 2019 para o SQL Server 2025 (17.x) a correr no Windows Server 2025.

Finalmente, AGs com um tipo de cluster None são úteis para migração ou atualização. Não podes misturar tipos de cluster numa configuração típica de AG, por isso todas as réplicas têm de ser do tipo Nenhum. Um AG distribuído pode ser usado para abranger AGs configurados com tipos diferentes de cluster. Este método também é suportado nas diferentes plataformas de SO.

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 altura de iniciar a mudança para a nova configuração, o corte é uma breve interrupção, em comparação com um longo período de indisponibilidade em que todo o trabalho, incluindo a sincronização de dados, precisa de ser concluído.

Os Grupos de Disponibilidade podem garantir um tempo de inatividade mínimo durante a atualização do sistema operativo subjacente, realizando uma mudança manual do primário para uma réplica secundária enquanto a aplicação do patch está em curso. Do ponto de vista do sistema operativo, fazer isto é mais comum no Windows Server, porque a manutenção do sistema operativo subjacente pode exigir um reinício. Aplicar patches ao Linux por vezes requer um reinício, mas é menos comum.

Outra forma de minimizar o tempo de inatividade é corrigir instâncias do SQL Server que participam num grupo de disponibilidade, dependendo da complexidade da arquitetura AG. Primeiro corriges uma réplica secundária. Quando o número correto de réplicas for corrigido, faça a transição manual da réplica primária para outro nó para fazer a atualização. Atualize quaisquer réplicas secundárias restantes neste momento.

Instâncias de cluster com tolerância a falhas

As FCIs sozinhas não conseguem ajudar numa migração ou atualização tradicional. Tens de configurar um AG ou registar o envio para as bases de dados na FCI e contabilizar todos os outros objetos. No entanto, as FCIs no Windows Server continuam a ser uma opção popular quando é necessário corrigir os Windows Servers subjacentes. Quando inicia um failover manual, a breve interrupção substitui o facto de a instância estar indisponível durante todo o tempo em que o Windows Server está a ser corrigido.

Podes atualizar uma FCI no local para versões posteriores do SQL Server. Para mais informação, 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 método de sincronização, a propagação de dados pode ser iniciada bem antes do switch do servidor. No momento da mudança, uma vez que todo o tráfego é interrompido na origem, um log final de transações precisaria ser feito, copiado e aplicado à nova configuração. Nessa altura, a base de dados pode ser colocada online.

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

Tal como nos AGs, a transferência de logs pode fornecer uma forma de alternar para outro servidor durante uma janela de manutenção.

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

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

Contêineres do SQL Server e opções de HA/DR

A implementação de contentores do SQL Server é uma forma de simplificar o provisionamento, escalabilidade e gestão do ciclo de vida do SQL Server em vários ambientes. Um contentor é uma imagem completa pronta a executar do SQL Server.

Dependendo da sua plataforma de contentores, por exemplo, ao usar um orquestrador de contentores como o Kubernetes, se o contentor for perdido, pode ser novamente implantado e ligado ao armazenamento partilhado que foi utilizado. Embora isso forneça alguma resiliência, há algum tempo de inatividade associado à recuperação do banco de dados e não está realmente altamente disponível como seria se usasse um grupo de disponibilidade ou FCI.

Se você estiver procurando configurar a alta disponibilidade para contêineres do SQL Server implantados em plataformas Kubernetes ou não-Kubernetes, poderá usar o DH2i DxEnterprise como uma das soluções de clustering, além da qual você pode configurar um AG no modo de alta disponibilidade. Essa opção fornece o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) esperados de uma solução de alta disponibilidade.

Implementação de VM baseada em Linux

O Linux pode ser implementado com SQL Server em Máquinas Virtuais Linux Azure. Tal como nas instalações baseadas no local, uma instalação suportada requer o uso de vedação de um nó avariado que é externo ao próprio agente do cluster. A vedação do nó é fornecida através de agentes de disponibilidade de vedação. Algumas distribuições enviam-nas como parte da plataforma, enquanto outras dependem de fornecedores externos de hardware e software. Verifique com sua distribuição Linux preferida quais formas de vedação de nó são fornecidas para que uma solução suportada possa ser implantada na nuvem pública.

Os guias para instalar o SQL Server no Linux estão disponíveis para as seguintes distribuições:

• Guia de início rápido: instale o SQL Server e crie um banco de dados no Red Hat
• Guia de início rápido: instale o SQL Server e crie um banco de dados no Ubuntu
• Guia de início rápido: instale o SQL Server e crie um banco de dados no SUSE Linux Enterprise Server

Escala de leitura

As réplicas secundárias têm a capacidade de ser usadas para consultas somente leitura. Existem duas formas que podem ser alcançadas através de um AG:

• Permitir acesso direto ao secundário
• Configurar o roteamento só de leitura, que requer o uso do listener. O SQL Server 2016 (13.x) introduziu a capacidade de equilibrar a carga de conexões somente leitura por meio do listener usando um algoritmo round robin, permitindo que solicitações somente leitura sejam espalhadas por todas as réplicas que podem ser lidas.

A escalabilidade de cópias legíveis de uma base de dados através de AGs foi introduzida pela primeira vez com AGs distribuídos no SQL Server 2016 (13.x). Esta funcionalidade oferece cópias apenas de leitura da base de dados não só localmente, mas também regionalmente e globalmente, com configuração mínima. Esta configuração reduz o tráfego de rede e a latência ao fazer com que as consultas sejam 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/escrita, e cada AG distribuído pode suportar até 27 cópias de leitura dos dados.

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

A única grande ressalva é que, na ausência de um cluster subjacente com um tipo de cluster "Nenhum", configurar o encaminhamento só de leitura é um pouco diferente. Do ponto de vista do SQL Server, um listener ainda é necessário para encaminhar as solicitações, mesmo que não haja cluster. Em vez de configurar um ouvinte tradicional, use o endereço IP ou o nome da réplica principal. A réplica principal então encaminha os pedidos de apenas leitura.

Um modo de espera quente de envio de logs pode ser tecnicamente 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 os usuários não podem acessar o banco de dados enquanto isso acontece. Isso torna o envio de logs uma solução menos do que ideal - especialmente se forem necessários dados quase em tempo real.

Ao contrário da replicação transacional, onde todos os dados estão ativos, cada réplica secundária num cenário de escala de leitura é uma cópia exata da primária. A réplica não está num estado onde se possam aplicar índices únicos. Se forem necessários índices para relatórios ou se os dados precisarem de ser manipulados, deve criar esses índices nas bases de dados na réplica primária. Se você precisar dessa flexibilidade, a replicação é uma solução melhor para dados legíveis.

Interoperabilidade entre plataformas e distribuição Linux

Com suporte a SQL Server tanto no Windows Server como no Linux, esta secção explica como podem funcionar em conjunto para disponibilidade, além de outros propósitos. Também cobre a história de soluções que incorporam mais do que uma distribuição Linux.

Grupos de disponibilidade distribuídos

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

Se configurares um AG com um tipo de cluster de Nenhum, pode abranger Windows Server e Linux, e múltiplas distribuições Linux. Como esta configuração não é verdadeira alta disponibilidade, não a uses para implantações críticas à missão. Como alternativa, utilize-o para escalabilidade de leitura ou cenários de migração e atualização.

Envio de logs

O envio de registos baseia-se em backup e restauro, por isso não há diferenças nas bases de dados, estruturas de ficheiros e outros elementos para SQL Server no Windows Server versus SQL Server no Linux. Pode configurar a transferência de logs entre uma instalação do SQL Server num ambiente Windows Server e num ambiente Linux, e entre distribuições de Linux. Tudo o resto permanece igual.

Assim como com um AG, o transporte de logs não funciona quando o servidor de origem está numa versão maior do SQL Server, contra um alvo que está numa versão menor.

Resumo

Pode tornar as instâncias e bases de dados do SQL Server 2017 (14.x) e versões posteriores altamente disponíveis usando as mesmas funcionalidades tanto no Windows Server como no Linux. Para além dos cenários padrão de disponibilidade local e recuperação de desastres, pode minimizar o tempo de inatividade associado a atualizações e migrações utilizando as funcionalidades de disponibilidade do SQL Server. Os AGs também podem fornecer cópias adicionais de uma base de dados como parte da mesma arquitetura para escalar cópias acessíveis para leitura. Quer você esteja implantando uma nova solução ou considerando uma atualização, o SQL Server tem a disponibilidade e a confiabilidade necessárias.

Conteúdo relacionado

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