Partilhar via

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

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores

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.

Uma tarefa comum que todos que implantam o SQL Server precisam levar em conta é garantir que todas as instâncias críticas do SQL Server e os bancos de dados dentro delas estejam disponíveis quando a empresa e os usuários finais precisarem delas, seja de 9 a 5 ou o tempo todo. 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) introduziu muitos recursos novos ou aprimoramentos nos existentes, alguns dos quais são para disponibilidade. A maior adição ao SQL Server 2017 (14.x) foi 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 se concentra em cobrir os cenários de disponibilidade no SQL Server 2017 (14.x) e versões posteriores, bem como os recursos de disponibilidade novos e aprimorados. Os cenários incluem híbridos que poderão abranger implantações do SQL Server no Windows Server e no Linux e aqueles que podem aumentar o número de cópias legíveis de um banco de dados.

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

Cenários do SQL Server usando os recursos de disponibilidade

Os grupos de disponibilidade Always On, as instâncias de cluster de failover Always On e o envio de logs podem ser utilizados de diversas formas e não apenas unicamente para fins de disponibilidade. Há quatro maneiras principais de usar os recursos 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 seções a seguir discutem os recursos relevantes que podem ser usados para esse cenário específico. O único recurso não abordado é a replicação do SQL Server. Embora não seja oficialmente designada como um recurso de disponibilidade sob o guarda-chuva Always On, a replicação do SQL Server é frequentemente usada para tornar os dados redundantes em determinados 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.

Importante

Os recursos de disponibilidade do SQL Server não substituem o requisito de ter uma estratégia de backup e restauração robusta e bem testada, o bloco de construção mais fundamental de qualquer solução de disponibilidade.

Alta disponibilidade

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

Grupos de disponibilidade

Introduzidos no SQL Server 2012 (11.x), os grupos de disponibilidade (AGs) fornecem proteção no nível de 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. Um AG pode ser implantado nas edições Standard ou Enterprise. As instâncias que participam de um AG podem ser instâncias de cluster autônomas ou de failover (FCIs, descritas na próxima seção). Como as transações são enviadas para uma réplica à medida que acontecem, os AGs são recomendados quando há requisitos para menores objetivos de ponto de recuperação e objetivos de 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.

Observação

Always On é um termo abrangente usado para descrever os recursos de disponibilidade no SQL Server e abrange AGs e FCIs. Always On não é o nome do recurso AG.

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. Qualquer coisa que não seja capturada no log de transações ou configurada no banco de dados precisará ser sincronizada 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, você pode gerenciar objetos de metadados, incluindo usuários, logons, permissões e trabalhos do SQL Server Agent no nível 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 teria o seu próprio ouvinte. Embora as implementações do ouvinte sejam ligeiramente diferentes no Windows Server versus Linux, a funcionalidade que ele fornece e como ele é usado é a mesma. O diagrama a seguir mostra um AG baseado no Windows Server que está usando um WSFC (Cluster de Failover do Windows Server). Um cluster subjacente na camada do sistema operacional é necessário para disponibilidade, seja no Linux ou no Windows Server. O exemplo apresenta uma configuração simples com dois servidores, ou nós, tendo um WSFC como cluster subjacente.

Diagrama de um grupo de disponibilidade simples.

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.

Observação

O espelhamento de banco de dados, que foi preterido no SQL Server 2012 (11.x), não está disponível na versão Linux do SQL Server, nem será adicionado. Os clientes que ainda utilizam o espelhamento de banco de dados devem planear a migração para Grupos de Disponibilidade (AGs), que substituem o espelhamento de banco de dados.

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. Contanto que o ouvinte seja usado e o aplicativo use uma versão posterior do .NET Framework (3.5 com uma atualização ou 4.0 e superior), o failover deve ser tratado com o mínimo ou nenhum efeito sobre os usuários finais se um ouvinte for utilizado. 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 a diferenças na forma como o cluster subjacente funciona no Linux e no Windows Server, todos os failovers (manuais ou automáticos) dos AGs 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 o SQL Server no Linux, a configuração recomendada para AGs é um mínimo de três réplicas. Isso se deve à maneira como o clustering subjacente funciona.
  • 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) apresenta os seguintes recursos e aprimoramentos para 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. A integração para AGs e FCIs é fornecida por DLLs de recursos com reconhecimento de cluster fornecidas pelo SQL Server.

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. O DNS fornece essa resolução de nome no Linux.

Devido à diferença na pilha de clusters, algumas alterações precisaram ser feitas para AGs porque o SQL Server precisa manipular alguns dos metadados que são manipulados nativamente por um WSFC. Uma dessas mudanças significativas é a introdução de um tipo de cluster para um grupo de disponibilidade. Isso é armazenado nas sys.availability_groupscluster_type colunas e cluster_type_desc . Existem três tipos de cluster:

  • 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 no Windows Server que usam um WSFC subjacente, o tipo de cluster padrão é WSFC e não precisa ser definido. Para AGs baseados em Linux, ao criar o AG, o tipo de cluster deve ser definido como Externo. 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.

Importante

No SQL Server 2017 (14.x) e versões posteriores, não é possível alterar um tipo de cluster para um AG depois que ele é criado. Isso significa que um AG não pode ser mudado de Nenhum para Externo ou WSFC, ou vice-versa.

Para aqueles que estão apenas à procura de adicionar cópias adicionais somente leitura de um banco de dados, ou para quem aprecia o que um AG fornece para migração/atualizações mas não quer estar vinculado à complexidade adicional de um cluster subjacente ou mesmo à replicação, um AG sem tipo de cluster é uma solução perfeita. 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 seguinte captura de tela a seguir é da versão 17.2:

Captura de ecrã das opções do SSMS AG.

SECUNDÁRIOS_SINCRONIZADOS_REQUERIDOS_PARA_CONFIRMAR

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 estava sincronizada, mas a outra estava tendo um problema, não havia como controlar o comportamento para dizer ao primário para aguardar a réplica com comportamento incorreto ou permitir que ela seguisse em frente. Isso significa que a réplica primária em algum momento continuaria a receber tráfego de gravação mesmo que a réplica secundária não estivesse em um estado sincronizado, o que significa que há 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 de AG e failover
  • Para WSFCs e um tipo de cluster de None, o valor padrão é 0, e pode ser definido manualmente como 1 ou 2
  • Para um tipo de cluster Externo, por padrão, o mecanismo de cluster definirá esse valor, podendo ser substituído manualmente. Para três réplicas síncronas, o valor padrão será 1.

No Linux, o valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT é configurado no recurso AG no cluster. No Windows, ele é definido via Transact-SQL.

Um valor superior a 0 assegura maior proteção de dados, porque, se o número necessário de réplicas secundárias não estiver disponível, o primário não ficará disponível até que isso seja resolvido. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Também afeta o comportamento de failover, uma vez que o failover automático não poderia ocorrer se o número certo de réplicas secundárias não estivesse no estado adequado. No Linux, um valor de 0 não permitirá failover automático, então no Linux, ao usar síncrono com failover automático, o valor deve ser definido mais alto do que 0 para obter failover automático. 0 no Windows Server é a configuração padrão no SQL Server 2016 (13.x) e nas versões anteriores.

Suporte aprimorado ao Microsoft Distributed Transaction Coordinator

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 capas, 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 que não seja do SQL Server

O SQL Server 2016 (13.x) introduziu suporte parcial para o DTC com Grupos de Disponibilidade (AGs) que abrangiam o cenário final. 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, o suporte a DTC também pode ser adicionado a um AG após sua criação. No SQL Server 2016 (13.x), habilitar o suporte para DTC para um AG só poderia ser feito quando o AG foi criado.

Instâncias de cluster com tolerância a falhas

As instalações clusterizadas são um recurso do SQL Server desde a versão 6.5. As FCIs são um método comprovado de fornecer disponibilidade para toda a instalação do SQL Server, denominada instância. Isso significa que tudo dentro da instância, incluindo bancos de dados, trabalhos do SQL Server Agent, servidores vinculados e assim por diante, será movido para outro servidor caso o servidor subjacente encontre um problema. Todas as FCIs exigem algum tipo de armazenamento compartilhado, mesmo que seja fornecido via rede. Os recursos da FCI podem estar em execução e ser da propriedade de apenas um nó num dado momento. No diagrama a seguir, o primeiro nó do cluster possui a FCI, o que também significa que ele possui os recursos de armazenamento compartilhados associados a ele indicados pela linha sólida para o armazenamento.

Diagrama de uma instância de cluster de failover.

Após um failover, a propriedade muda como é visto no diagrama a seguir:

Diagrama de uma instância de cluster de failover, pós-failover.

Não há perda de dados com uma FCI, mas o armazenamento compartilhado subjacente é um único ponto de falha, já que há uma cópia dos dados. As FCIs geralmente são combinadas com outro método de disponibilidade, como um AG ou envio de logs, para ter cópias redundantes de bancos de dados. O método adicional implantado deve usar armazenamento fisicamente separado da FCI. Quando a FCI faz failover para outro nó, ela para em um nó e começa em outro, não muito diferente de desligar um servidor e ligá-lo. Uma FCI passa pelo processo normal de recuperação, o que significa que todas as transações que precisam ser roladas para frente serão, e todas as transações que estiverem incompletas serão revertidas. Portanto, o banco de dados é consistente desde um ponto de dados até o momento da falha ou failover manual, portanto, sem perda de dados. Os bancos de dados só estão disponíveis após a conclusão da recuperação, portanto, o tempo de recuperação dependerá de muitos fatores e, geralmente, será maior 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 abstraem qual nó do cluster subjacente está hospedando-o. Uma FCI mantém sempre o mesmo nome. Aplicativos e usuários finais nunca se conectam aos nós; o nome exclusivo atribuído à FCI é usado. 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. Uma FCI no Linux é configurada após a instalação do SQL Server.
  • O Linux suporta apenas uma única instalação do SQL Server por host, portanto, todas as FCIs serão uma instância 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 e tempo de recuperação forem mais flexíveis, ou se os bancos de dados não forem considerados altamente críticos para a missão, o log shipping é outro recurso de disponibilidade comprovada 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 espera ativa 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.

Diagrama de envio de logs.

Indiscutivelmente, a maior vantagem de utilizar o envio de logs de alguma forma é que ele lida com erros humanos. A aplicação de logs de transações pode ser atrasada. Portanto, se alguém emitir algo como uma UPDATE cláusula sem WHERE cláusula, o modo de espera pode não ter a alteração, então você pode mudar para isso enquanto conserta o sistema primário. Embora o envio de logs seja fácil de configurar, a mudança de um servidor primário para um servidor de espera quente, conhecida como mudança de função, é sempre manual. Uma alteração de função é iniciada via Transact-SQL e, como um AG, todos os objetos não capturados no log de transações devem ser sincronizados manualmente. O envio de logs também precisa ser configurado por banco de dados, enquanto um único AG pode conter vários bancos de dados.

Ao contrário de um AG ou FCI, o log shipping não tem uma abstração para mudança de função, que os aplicativos devem ser capazes de lidar. 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 seção abordará como os recursos de disponibilidade do SQL Server podem ajudar na continuidade de negócios.

Grupos de disponibilidade

Um dos benefícios dos AGs é que tanto a alta disponibilidade quanto a recuperação de desastres podem ser configuradas usando um único recurso. 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.

Diagrama de um grupo de disponibilidade abrangendo centros de dados.

Fora de um AG com um tipo de cluster 'nenhum', um AG requer que todas as réplicas façam parte do mesmo cluster de base, seja um WSFC, ou uma solução de cluster externo. Isso significa que, no diagrama acima, o WSFC é estendido para funcionar em dois data centers diferentes, o que adiciona complexidade. independentemente da plataforma (Windows Server ou Linux). Distribuir clusters à distância adiciona complexidade.

Introduzido no SQL Server 2016 (13.x), um grupo de disponibilidade distribuído permite que um AG se estenda por AGs configurados em clusters diferentes. Os Grupos de Disponibilidade (AGs) distribuídos eliminam a necessidade de todos os nós participarem do mesmo cluster, o que facilita significativamente a configuração da recuperação de desastres. Para obter mais informações sobre AGs distribuídos, consulte Grupos de disponibilidade distribuídos.

Diagrama de um grupo de disponibilidade distribuída.

Instâncias de cluster com tolerância a falhas

As FCIs podem ser usadas para recuperação de desastres. Tal como acontece com um AG normal, o mecanismo de cluster subjacente também deve ser estendido a todos os locais, o que aumenta a complexidade. Há uma consideração adicional para FCIs: o armazenamento compartilhado. Os mesmos discos precisam estar disponíveis nos sites primário e secundário. Um método externo, como a funcionalidade fornecida pelo fornecedor de armazenamento na camada de hardware ou usando a Réplica de armazenamento no Windows Server, é necessário para garantir que os discos usados pela FCI existam em outro lugar.

Diagrama de uma FCI abrangendo data centers.

Envio de logs

O envio de logs é um dos métodos mais antigos de fornecer recuperação de desastres para bancos de dados do 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 à história de alta disponibilidade para envio de logs, muitos ambientes atrasarão o carregamento de um log de transações para levar em conta o erro humano.

Migrações e upgrades

Ao implantar novas instâncias ou atualizar as antigas, uma empresa não pode tolerar longas interrupções. 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.

Observação

Outros métodos, como usar backups e restaurá-los em outro lugar, também podem ser usados para migrações e atualizações. Eles não são discutidos neste artigo.

Grupos de disponibilidade

Uma instância existente contendo um ou mais AGs pode ser atualizada para versões posteriores do SQL Server. Embora isso exija alguma quantidade de tempo de inatividade, com a quantidade certa de planejamento, ele pode ser minimizado.

Se o objetivo for migrar para novos servidores e não alterar a configuração (incluindo o sistema operacional ou a versão do SQL Server), esses servidores poderão ser adicionados como nós ao cluster subjacente existente e adicionados ao AG. Quando a réplica ou réplicas estiverem no estado correto, poderá ser realizada uma alteração automática manual para um novo servidor e, em seguida, as antigas poderão ser removidas do Grupo de Disponibilidade (AG) e, finalmente, descomissionadas.

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 oferece suporte a AGs subjacentes diferentes em arquiteturas diferentes, por exemplo, você pode mudar do SQL Server 2016 (13.x) em execução no Windows Server 2012 R2 para o SQL Server 2017 (14.x) em execução no Windows Server 2016.

Diagrama de um grupo de disponibilidade distribuída misturando WSFC e Pacemaker.

Finalmente, AGs com um tipo de agrupamento de Nenhum também podem ser usados para migração ou atualização. Não é possível misturar e combinar tipos de cluster em uma configuração AG típica, portanto, todas as réplicas precisariam ser um tipo de Nenhum. Um AG distribuído pode ser usado para abranger AGs configurados com diferentes tipos 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 parte mais demorada do trabalho seja feita ao longo do tempo - sincronização de dados. Quando chega a hora de iniciar a mudança para a nova configuração, a substituição é uma breve interrupção versus um longo período de inatividade em que todo o trabalho, incluindo a sincronização de dados, precisaria ser concluído.

Os AGs podem fornecer um tempo de inatividade mínimo durante a aplicação de patches do sistema operacional subjacente, fazendo o failover manual do primário para uma réplica secundária enquanto o patch está sendo concluído. Do ponto de vista do sistema operacional, fazer isso seria mais comum no Windows Server, já que muitas vezes, mas nem sempre, a manutenção do sistema operacional subjacente pode exigir uma reinicialização. A aplicação de patches no Linux às vezes precisa de uma reinicialização, mas pode ser pouco frequente.

A aplicação de patches em instâncias do SQL Server que participam de um grupo de disponibilidade também pode minimizar o tempo de inatividade, dependendo da complexidade da arquitetura AG. Para corrigir servidores que participam de um AG, uma réplica secundária é corrigida primeiro. Depois que o número correto de réplicas é corrigido, a réplica primária é manualmente transferida para outro nó para fazer a atualização. Todas as réplicas secundárias restantes nesse ponto também podem ser atualizadas.

Instâncias de cluster com tolerância a falhas

As FCIs por si só não podem ajudar com uma migração ou atualização tradicional; um AG ou envio de logs teria que ser configurado para os bancos de dados na FCI e todos os outros objetos contabilizados. No entanto, as FCIs no Windows Server ainda são uma opção popular para quando os servidores Windows subjacentes precisam ser corrigidos. Um failover manual pode ser iniciado, o que significa uma breve interrupção em vez de ter a instância indisponível durante todo o tempo em que o Windows Server estiver sendo corrigido. Uma FCI pode ser atualizada para versões posteriores do SQL Server. Para obter 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 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 fonte, um log de transações final deverá ser efetuado, 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.

Semelhante aos Grupos de Disponibilidade (AGs), o envio de logs pode permitir a mudança para outro servidor em caso de patches.

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, conforme apresentada ao longo deste documento, existe independentemente de como o SQL Server é implantado. Esses dois métodos têm algumas considerações especiais quando se trata de tornar o SQL Server altamente disponível.

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

A implantação de contêiner do SQL Server é uma nova maneira de implantar o SQL Server no Linux. Um contêiner é uma imagem completa do SQL Server que está pronta para ser executada.

Dependendo da plataforma de contêiner usada, 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 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.

Implantação de IaaS baseada em Linux

As máquinas virtuais Linux IaaS podem ser implantadas com o SQL Server instalado usando o Azure. Tal como acontece com as instalações baseadas no local, uma instalação suportada requer o uso de vedação de um nó com falha que é externo ao próprio agente de 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:

Escala de leitura

As réplicas secundárias têm a capacidade de ser usadas para consultas somente leitura. Existem duas formas de obter isso com um AG: permitindo o acesso direto ao secundário e configurando o roteamento apenas para 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 round robin, permitindo que solicitações somente leitura sejam espalhadas por todas as réplicas legíveis.

Observação

As réplicas secundárias legíveis só estão disponíveis na edição Enterprise e cada instância que hospeda uma réplica legível precisaria de uma licença do SQL Server.

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). Isso permitiria que as empresas tivessem cópias somente leitura do banco de dados não apenas localmente, mas regional e globalmente com uma quantidade mínima de configuração e reduziria o tráfego de rede e a latência ao ter consultas 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, de modo que cada AG distribuído pode suportar até 27 cópias dos dados que são legíveis.

Diagrama mostrando um grupo de disponibilidade distribuída relacionado à escala de leitura.

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 objetivo for usar AGs para réplicas secundárias legíveis e não disponibilidade, isso elimina a complexidade de usar um WSFC ou uma solução de cluster externo no Linux e oferece os benefícios legíveis de um AG em um método de implantação mais simples.

A única ressalva importante é que, devido à ausência de um cluster subjacente com um tipo de cluster definido como Nenhum, configurar o roteamento somente 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, o endereço IP ou o nome da réplica primária é usado. A réplica primária é então usada para rotear as solicitações somente 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.

Algo que deve ser notado para todos os cenários de escala de leitura com AGs é que, ao contrário da utilização de replicação transacional, onde todos os dados são ao vivo, cada réplica secundária não se encontra em um estado no qual índices únicos possam ser aplicados; a réplica é exatamente uma cópia da primária. Se algum índice for necessário para relatórios ou se os dados precisarem ser manipulados, eles deverão ser criados nos bancos de dados da 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 o SQL Server agora suportado no Windows Server e Linux, esta seção aborda os cenários de como eles podem trabalhar juntos para disponibilidade, além de outras finalidades, e a história para soluções que incorporarão mais de uma distribuição Linux.

Observação

Não há cenários em que uma FCI ou AG baseada em WSFC trabalhará diretamente com uma FCI ou AG baseada em Linux. Um WSFC não pode ser estendido por um nó Pacemaker e vice-versa.

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 será o principal método de 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 mencionado acima, os AGs, especialmente os AGs distribuídos, reduziriam ao mínimo o tempo em que uma aplicação estaria indisponível para uso. Um exemplo de um AG distribuído que abrange um WSFC e Pacemaker é mostrado no diagrama a seguir:

Diagrama mostrando um grupo de disponibilidade distribuída que abrange um WSFC e Pacemaker.

Se um AG estiver configurado com um tipo de cluster de None, ele poderá abranger Windows Server e Linux, bem como várias distribuições Linux. Como esta não é uma verdadeira configuração de alta disponibilidade, não o deve usar para implantações críticas, mas sim para aumentar a capacidade de leitura ou para cenários de migração/atualização.

Envio de logs

Como o envio de logs é baseado em backup e restauração, e não há diferenças nos bancos de dados, estruturas de arquivos, etc., para o SQL Server no Windows Server versus o SQL Server no Linux. Isso significa que o envio de logs pode ser configurado entre uma instalação do SQL Server baseada no Windows Server e uma instalação do Linux, bem como entre distribuições do Linux. Tudo o resto permanece igual. A única ressalva é que o envio de logs, assim como um AG, não pode funcionar quando a origem está em uma versão principal superior do SQL Server em relação a um destino que está em uma versão inferior do SQL Server.

Resumo

Instâncias e bancos de dados do SQL Server 2017 (14.x) e versões posteriores podem ser 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 desastres, o tempo de inatividade associado a atualizações e migrações pode ser minimizado com os recursos de disponibilidade no SQL Server. Os AGs também podem fornecer cópias adicionais de um banco de dados como parte da mesma arquitetura para dimensionar cópias legíveis. 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

  • Last updated on