Melhores práticas de visão geral dos grupos de failover (Instância Gerenciada de SQL do Azure)

  • Artigo

Aplica-se a:Instância Gerenciada de SQL do Azure

O recurso de grupos de failover permite gerenciar a replicação e o failover de todos os bancos de dados de usuário em uma instância gerenciada para outra região do Azure. Este artigo fornece uma visão geral do recurso de grupo de failover com melhores práticas e recomendações para usá-lo com a Instância Gerenciada de SQL do Azure.

Para começar a usar o recurso, consulte Configurar um grupo de failover para a Instância Gerenciada de SQL do Azure.

Visão geral

O recurso de grupos de failover permite gerenciar a replicação e o failover de uma instância gerenciada para uma instância gerenciada em outra região do Azure. Os grupos de failover foram projetados para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala.

Para obter mais informações, confira Alta disponibilidade da Instância Gerenciada de SQL do Azure. Para os RPO e RTO do failover geográfico, confira Visão geral da continuidade dos negócios.

Redirecionamento de ponto de extremidade

Além disso, os grupos de failover fornecem pontos de extremidade de ouvinte de leitura/gravação e somente leitura que permanecem inalterados durante failovers geográficos. Você não precisa alterar a cadeia de conexão para seu aplicativo após um failover geográfico, pois as conexões são automaticamente roteadas para o primário atual. Um failover geográfico alterna todos os bancos de dados secundários no grupo para a função primária. Após a conclusão do failover geográfico, o registro DNS é atualizado automaticamente para redirecionar os pontos de extremidade para a nova região.

Descarregar cargas de trabalho somente leitura

Para reduzir o tráfego para seus bancos de dados primários, você também pode usar os bancos de dados secundários em um grupo de failover para descarregar cargas de trabalho somente leitura. Use o ouvinte somente leitura para direcionar o tráfego somente leitura para um banco de dados secundário legível.

Recuperando um aplicativo

Adicionar a redundância do banco de dados regional é apenas parte da solução para obter uma continuidade de negócios completa. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica exige a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. O software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS são exemplos desses componentes. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (objetivo de tempo de recuperação) de seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e os recursos que eles fornecem. Em seguida, você deve tomar as medidas necessárias para garantir que seu serviço funcione durante o failover dos serviços dos quais ele depende.

Política de failover

Os grupos de failover oferecem suporte a duas políticas de failover:

  • Gerenciado pelo cliente (recomendado): os clientes podem executar um failover de um grupo quando percebem uma interrupção inesperada que afeta um ou mais bancos de dados no grupo de failover. Ao usar ferramentas de linha de comando, como o PowerShell, a CLI do Azure ou a API Rest, o valor da política de failover para gerenciado pelo cliente é manual.
  • Gerenciado pela Microsoft: no caso de uma interrupção generalizada que afete uma região primária, a Microsoft inicia o failover de todos os grupos de failover afetados que têm sua política de failover configurada para ser gerenciada pela Microsoft. O failover gerenciado pela Microsoft não será iniciado para grupos de failover individuais ou um subconjunto de grupos de failover em uma região. Ao usar ferramentas de linha de comando, como o PowerShell, a CLI do Azure ou a API Rest, o valor da política de failover para gerenciado pela Microsoft é automatic.

Cada política de failover tem um conjunto exclusivo de casos de uso e expectativas correspondentes sobre o escopo de failover e a perda de dados, conforme resume a tabela a seguir:

Política de failover Escopo de failover Caso de uso Possível perda de dados
Gerenciado pelo cliente
(Recomendado)		 Grupo(s) de failover Um ou mais bancos de dados em um grupo de failover é afetado por uma interrupção e fica indisponível. Você pode optar por fazer failover. Yes
Gerenciado pela Microsoft Todos os grupos de failover na região Uma interrupção generalizada em um datacenter, zona de disponibilidade ou região causa indisponibilidade de bancos de dados e a equipe de serviço SQL do Microsoft Azure decide disparar um failover forçado.
Use essa opção somente quando quiser delegar a responsabilidade de recuperação de desastres à Microsoft e o aplicativo for tolerante ao RTO (tempo de inatividade) de pelo menos uma hora ou mais.		 Yes

Gerenciado pelo cliente

Em raras ocasiões, a disponibilidade interna ou a alta disponibilidade não são suficientes para mitigar uma interrupção, e seus bancos de dados em um grupo de failover podem ficar indisponíveis por um período que não é aceitável para o Contrato de Nível de Serviço (SLA) dos aplicativos que usam os bancos de dados. Os bancos de dados podem estar indisponíveis devido a um problema localizado que afeta apenas alguns bancos de dados ou podem estar no nível do datacenter, da zona de disponibilidade ou da região. Em qualquer um desses casos, para restaurar a continuidade dos negócios, você pode iniciar um failover forçado.

Definir sua política de failover para gerenciada pelo cliente é altamente recomendado, pois mantém você no controle de quando iniciar um failover e restaurar a continuidade dos negócios. Você pode iniciar um failover quando notar uma interrupção inesperada afetando um ou mais bancos de dados no grupo de failover.

Gerenciado pela Microsoft

Com uma política de failover gerenciada pela Microsoft, a responsabilidade pela recuperação de desastres é delegada ao serviço SQL do Azure. Para que o serviço SQL do Azure inicie um failover forçado, as seguintes condições devem ser atendidas:

  • Interrupção do datacenter, da zona de disponibilidade ou do nível da região causada por um evento de desastre natural, alterações de configuração, bugs de software ou falhas de componentes de hardware e muitos bancos de dados na região são afetados.
  • O período de carência expirou. Como a verificação da escala da interrupção e sua mitigação envolvem ações humanas, o período de carência não pode ser definido abaixo de uma hora.

Quando essas condições são atendidas, o serviço SQL do Azure inicia failovers forçados para todos os grupos de failover na região que têm a política de failover definida como gerenciada pela Microsoft.

Defina a política de failover como Gerenciada pela Microsoft somente quando:

  • Você deseja delegar a responsabilidade de recuperação de desastres ao serviço SQL do Azure.
  • O aplicativo é tolerante ao seu banco de dados ficar indisponível por pelo menos uma hora ou mais.
  • É aceitável acionar failovers forçados algum tempo após o término do período de carência, pois o tempo real para o failover forçado pode variar significativamente.
  • É aceitável que todos os bancos de dados dentro do grupo de failover façam failover, independentemente de sua configuração de redundância de zona ou status de disponibilidade. Embora os bancos de dados configurados para redundância de zona sejam resilientes a falhas zonais e possam não ser afetados por uma interrupção, eles ainda serão submetidos a failover se fizerem parte de um grupo de failover com uma política de failover gerenciado pela Microsoft.
  • É aceitável ter failovers forçados de bancos de dados no grupo de failover sem levar em consideração a dependência do aplicativo de outros serviços ou componentes do Azure usados pelo aplicativo, o que pode causar degradação do desempenho ou indisponibilidade do aplicativo.
  • É aceitável incorrer em uma quantidade desconhecida de perda de dados, pois o tempo exato do failover forçado não pode ser controlado e ignora o status de sincronização dos bancos de dados secundários.
  • Todos os bancos de dados primários e secundários no grupo de failover e todas as relações de replicação geográfica têm o mesmo nível de serviço, nível de computação (provisionado ou sem servidor) e tamanho da computação (DTUs ou vCores). Se o objetivo de nível de serviço (SLO) de todos os bancos de dados não corresponder, a política de failover será consequentemente atualizada do serviço Gerenciado pela Microsoft para Gerenciado pelo Cliente pelo serviço SQL do Azure.

Quando um failover é acionado pela Microsoft, uma entrada para o nome da operação Grupo de failover do SQL do Azure é adicionada ao log de atividades do Azure Monitor. A entrada inclui o nome do grupo de failover em Recurso e Evento iniciado por exibe um único hífen (-) para indicar que o failover foi iniciado pela Microsoft. Essas informações também podem ser encontradas na página Log de atividades do novo servidor primário ou instância no portal do Azure.

Terminologia e recursos

  • FOG (grupo de failover)

    Um grupo de failover permite que todos os bancos de dados de usuário em uma instância gerenciada realizem failover como uma unidade para outra região do Azure, caso a instância gerenciada primária fique indisponível devido a uma interrupção da região primária. Como os grupos de failover a Instância Gerenciada de SQL, contém todos os bancos de dados de usuário na instância, é possível configurar apenas um grupo de failover em uma instância.

    Importante

    O nome do grupo de failover deve ser globalmente exclusivo no domínio .database.windows.net.

  • Primário

    A instância gerenciada que hospeda os bancos de dados primários no grupo de failover.

  • Secundário

    O servidor ou a instância gerenciada que hospeda os bancos de dados secundários no grupo de failover. O secundário não pode estar na mesma região do Azure do primário.

    Importante

    • Se um banco de dados contiver objetos OLTP in-memory, a instância primária e secundária de réplica de área geográfica deverão ter camadas de serviço correspondentes, pois os objetos OLTP in-memory residem na memória. Uma camada de serviço inferior na instância de réplica de área geográfica pode resultar em problemas de memória insuficiente. Se isso ocorrer, a réplica secundária pode falhar ao recuperar o banco de dados, deixando o banco de dados secundário não disponível junto com objetos OLTP in-memory na área geográfica secundária. Isso, por sua vez, também pode fazer com que os failovers não sejam bem-sucedidos. Para evitar isso, verifique se a camada de serviço da instância secundária de área geográfica corresponde à do banco de dados primário. As atualizações da camada de serviço podem ser operações de tamanho de dados e demorar um pouco para serem concluídas.

  • Failover (sem perda de dados)

    O failover executa uma sincronização de dados completa entre o banco de dados primário e o secundário antes de o secundário mudar para a função de primário. Isso assegura que não ocorra nenhuma perda de dados. O failover só é possível quando o primário está acessível. O failover é usado nos seguintes cenários:

    • Executar simulações de recuperação de desastre (DR) em produção quando a perda de dados não é aceitável
    • Relocar a carga de trabalho para uma região diferente
    • Retornar a carga de trabalho para a região primária após a mitigação da interrupção (failback)

  • Failover forçado (potencial perda de dados)

    O failover forçado alterna imediatamente o secundário para a função primária sem esperar que as alterações recentes se propaguem do primário. Essa operação pode resultar em potencial perda de dados. Um failover forçaco é usado como um método de recuperação durante as interrupções quando o primário não está acessível. Quando a interrupção for atenuada, o primário antigo será reconectado automaticamente e se tornará um novo secundário. Um failover pode ser executado para realizar o failback, retornando as réplicas para suas funções primárias e secundárias originais.

  • Período de carência com perda de dados

    Como os dados são replicados para o secundário usando replicação assíncrona, o failover forçado de grupos com políticas de failover gerenciado pela Microsoft pode resultar em perda de dados. Você pode personalizar a política de failover para refletir a tolerância do seu aplicativo à perda de dados. Ao configurar GracePeriodWithDataLossHours, você pode controlar quanto tempo o serviço de SQL do Azure espera antes de iniciar um failover forçado, o que pode resultar em perda de dados.

  • Zona DNS

    Uma ID exclusiva que é gerada automaticamente quando um nova Instância Gerenciada de SQL é criada. Um certificado SAN (vários domínios) para essa instância é provisionado para autenticar as conexões de cliente com qualquer instância na mesma zona DNS. As duas instâncias gerenciadas no mesmo grupo de failover devem compartilhar a zona DNS.

  • Ouvinte de leitura/gravação do grupo de failover

    Um registro CNAME DNS que aponta para a primária atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho de leitura/gravação se reconecte de modo transparente ao primário quando o primário é alterado após o failover. Quando o grupo de failover é criado em uma Instância Gerenciada de SQL, o registro CNAME DNS para a URL do ouvinte é formado como <fog-name>.<zone_id>.database.windows.net.

  • Ouvinte de somente leitura do grupo de failover

    Um registro CNAME DNS que aponta para a secundário atual. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho SQL somente leitura se conecte de modo transparente ao secundário quando o secundário é alterado após o failover. Quando o grupo de failover é criado em uma Instância Gerenciada de SQL, o registro CNAME DNS para a URL do ouvinte é formado como <fog-name>.secondary.<zone_id>.database.windows.net. Por padrão, o failover do ouvinte somente leitura é desabilitado, pois garante que o desempenho do primário não seja afetado quando o secundário estiver offline. No entanto, isso também significa que as sessões somente leitura não poderão conectar-se até que o secundário seja recuperado. Se não for possível tolerar o tempo de inatividade em sessões somente leitura e se der para usar o primário para tráfego somente leitura e de leitura/gravação às custas da possível degradação do desempenho do primário, você poderá habilitar o failover para o ouvinte somente leitura configurando a propriedade AllowReadOnlyFailoverToPrimary. Nesse caso, o tráfego somente leitura é redirecionado automaticamente para o primário se o secundário não estiver disponível.

    Observação

    A propriedade AllowReadOnlyFailoverToPrimary só terá efeito se a política de failover gerenciado pela Microsoft estiver habilitada e um failover forçado for disparado. Nesse caso, se a propriedade for definida como True, o novo primário servirá para as sessões de leitura/gravação e somente leitura.

Arquitetura do grupo de failover

O grupo de failover precisa ser configurado na instância primária e a conectará à instância secundária em uma região do Azure diferente. Todos os bancos de dados na instância serão replicados para a instância secundária. Os bancos de dados do sistema, como master e msdb, não serão replicados.

O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando uma instância gerenciada e um grupo de failover:

diagrama de um grupo de failover para uma Instância Gerenciada de SQL do Azure.

Se o aplicativo usar a Instância Gerenciada de SQL como a camada de dados, siga estas diretrizes gerais e as melhores práticas descritas neste artigo ao projetar para continuidade de negócios.

Criar a instância geográfica secundária

Para garantir conectividade ininterrupta à Instância Gerenciada de SQL primária após o failover, as instâncias primária e secundária precisam estar na mesma zona DNS. Isso garante que o mesmo certificado de vários domínios (SAN) possa ser usado para autenticar as conexões do cliente com uma das duas instâncias no grupo de failover. Quando seu aplicativo estiver pronto para implantação em produção, crie uma Instância Gerenciada de SQL secundária em uma região diferente e verifique se ela compartilha a zona DNS com a Instância Gerenciada de SQL primária. Você pode fazer isso especificando um parâmetro opcional durante a criação. Se você estiver usando o PowerShell ou a API REST, o nome do parâmetro opcional será DNSZonePartner. O nome do campo opcional correspondente no portal do Azure é Primary Instância Gerenciada.

Importante

A primeira instância gerenciada criada na sub-rede determina a zona DNS para todas as instâncias subsequentes na mesma sub-rede. Isso significa que duas instâncias da mesma sub-rede não podem pertencer a zonas DNS diferentes.

Para obter mais informações sobre como criar a Instância Gerenciada de SQL secundária na mesma zona DNS que a instância primária, confira Configurar um grupo de failover para a Instância Gerenciada de SQL do Azure.

Usar regiões emparelhadas

Implante ambas as instâncias gerenciadas em regiões emparelhadas por motivos de desempenho. Grupos de failover de Instância Gerenciada de SQL em regiões emparelhadas têm melhor desempenho em comparação com regiões não emparelhadas.

A Instância Gerenciada de SQL do Azure segue uma prática de implantação segura em que as regiões emparelhadas do Azure geralmente não são implantadas ao mesmo tempo. No entanto, não é possível prever qual região será atualizada primeiro, portanto, a ordem de implantação não é garantida. Às vezes, sua instância primária é atualizada primeiro e, às vezes, a instância secundária é atualizada primeiro.

Em situações em que a Instância Gerenciada de SQL do Azure faz parte de um grupo de failover e as instâncias do grupo não estão em regiões emparelhadas do Azure, selecione diferentes agendamentos de janela de manutenção para seus bancos de dados primário e secundário. Por exemplo, selecione a janela de manutenção Dia da semana para o banco de dados geográfico secundário e a janela de manutenção Fim de semana para o banco de dados geográfico primário.

Habilitar e otimizar o fluxo de tráfego de replicação geográfica entre as instâncias

A conectividade entre as sub-redes de rede virtual que hospedam a instância primária e secundária deve ser estabelecida e mantida para o fluxo de tráfego de replicação geográfica ininterrupta. Há várias maneiras de fornecer conectividade entre as instâncias que você pode escolher com base em sua topologia de rede e políticas:

O emparelhamento de rede virtual (emparelhamento VNET) global é a maneira recomendada para estabelecer conectividade entre duas instâncias em um grupo de failover. Ele fornece uma conexão privada de baixa latência e alta largura de banda entre as redes virtuais emparelhadas usando a infraestrutura de backbone da Microsoft. Não são necessários a Internet pública, os gateways ou a criptografia adicional na comunicação entre as redes virtuais emparelhadas.

Propagação inicial

Ao estabelecer um grupo de failover entre instâncias gerenciadas, há uma fase inicial de propagação antes do início da replicação de dados. A fase de propagação inicial é a parte da operação mais longa e custosa. Após a conclusão da propagação inicial, os dados são sincronizados e somente as alterações de dados subsequentes são replicadas. O tempo necessário para que a propagação inicial seja concluída depende do tamanho dos dados, do número de bancos de dados replicados, da intensidade da carga de trabalho nos bancos de dados primários e da velocidade do vínculo entre as redes virtuais que hospedam as instâncias primária e secundária que dependem principalmente da maneira como a conectividade é estabelecida. Em circunstâncias normais e quando a conectividade é estabelecida usando o emparelhamento de rede virtual global recomendado, a velocidade de propagação é de até 360 GB por hora para a Instância Gerenciada de SQL. A propagação é executada para um lote de bancos de dados de usuário em paralelo, não necessariamente para todos os bancos de dados ao mesmo tempo. Vários lotes poderão ser necessários se houver muitos bancos de dados hospedados na instância.

Caso a velocidade do link entre as duas instâncias seja mais lenta do que o necessário, provavelmente o tempo de propagação será significativamente afetado. Você pode usar a velocidade de propagação declarada, o número de bancos de dados, o tamanho total dos dados e a velocidade do link para estimar quanto tempo a fase de propagação inicial levará antes de iniciar a replicação de dados. Por exemplo, para um único banco de dados de 100 GB, a fase de propagação inicial levará cerca de 1,2 hora se o link for capaz de enviar por push 84 GB por hora e se não houver nenhum outro banco de dados em propagação. Se o link só puder transferir 10 GB por hora, a propagação de um banco de dados de 100 GB pode levar cerca de 10 horas. Se houver vários bancos de dados para serem replicados, o posicionamento será executado em paralelo e, quando combinado com uma velocidade de link lenta, a fase de posicionamento inicial poderá levar muito mais tempo, especialmente se o posicionamento paralelo de dados de todos os bancos de dados exceder a largura de banda de link disponível.

Importante

No caso de um link de velocidade extremamente baixa ou ocupado, fazendo com que a fase inicial de propagação leve dias, a criação de um grupo de failover pode atingir o tempo limite. O processo de criação será cancelado automaticamente após seis dias.

Gerenciar o failover geográfico para uma instância secundária geográfica

O grupo de failover gerencia o failover geográfico de todos os bancos de dados na instância gerenciada primária. Quando um grupo é criado, cada banco de dados na instância será replicado geograficamente de modo automático para a instância secundária geográfica. Não é possível usar grupos de failover para iniciar um failover parcial de um subconjunto de bancos de dados.

Importante

Se um banco de dados for removido da instância gerenciada primária, ele automaticamente também será removido da instância gerenciada secundária geográfica.

Usar o ouvinte de leitura/gravação (MI primário)

Para cargas de trabalho de leitura/gravação, use <fog-name>.zone_id.database.windows.net como o nome do servidor. As conexões são direcionadas automaticamente para o primário. Esse nome não é alterado após o failover. O failover geográfico envolve a atualização do registro DNS, para que novas conexões de cliente sejam redirecionadas ao novo primário somente após a atualização do cliente do cache DNS. Como a instância secundária compartilha a zona DNS com a primária, o aplicativo cliente poderá reconectar-se a ela usando o mesmo certificado de SAN do lado do cliente. As conexões de cliente existentes precisam ser encerradas e, em seguida, recriadas para serem roteadas para o novo primário. O ouvinte de leitura/gravação e o ouvinte somente leitura não podem ser alcançados por meio do ponto de extremidade público para a instância gerenciada.

Usar o ouvinte somente leitura (MI secundário)

Se você tiver cargas de trabalho somente leitura logicamente isoladas que são tolerantes à latência de dados, é possível executa-las na área geográfica secundária. Para se conectar diretamente à área secundária geográfico, use <fog-name>.secondary.<zone_id>.database.windows.net como o nome do servidor.

Na camada Comercialmente Crítico, a Instância Gerenciada de SQL dá suporte ao uso de réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura usando o parâmetro ApplicationIntent=ReadOnly na cadeia de conexão. Ao configurar um secundário replicado geograficamente, você pode usar essa funcionalidade para se conectar a uma réplica somente leitura na localização do primário ou na localização com replicação geográfica:

  • Para se conectar a uma réplica somente leitura na localização do primário, use ApplicationIntent=ReadOnly e <fog-name>.<zone_id>.database.windows.net.
  • Para se conectar a uma réplica somente leitura na localização do secundário, use ApplicationIntent=ReadOnly e <fog-name>.secondary.<zone_id>.database.windows.net.

O ouvinte de leitura/gravação e o ouvinte somente leitura não podem ser alcançados por meio do ponto de extremidade público para a instância gerenciada.

Possível degradação do desempenho após o failover

Um aplicativo típico do Azure usa vários serviços do Azure e consiste em vários componentes. O failover geográfico do grupo de failover é acionado com base no estado dos componentes do SQL do Azure sozinhos. Outros serviços do Azure na região primária podem não ser afetados pela interrupção, e seus componentes ainda podem estar disponíveis nessa região. Depois que os bancos de dados primários mudarem para a região secundária, a latência entre os componentes dependentes poderá aumentar. Garanta a redundância de todos os componentes do aplicativo na região secundária e faça o failover de componentes de aplicativo junto com o banco de dados para que o desempenho do aplicativo não seja afetado pela latência maior entre regiões.

Potencial perda de dados após o failover forçado

Se ocorrer uma interrupção na região primária, as transações recentes podem não ter sido replicadas para a secundária geográfica e pode haver perda de dados se um failover forçado for executado.

Atualização de DNS

A atualização do DNS do ouvinte de leitura-gravação ocorrerá imediatamente após o início do failover. Essa operação não resultará em perda de dados. No entanto, o processo de mudar as funções de bancos de dados pode levar até 5 minutos em condições normais. Até que ele seja concluído, alguns bancos de dados na nova instância primária ainda serão somente leitura. Se um failover for iniciado usando o PowerShell, a operação para alternar a função de réplica primária será síncrona. Se ele for iniciado usando o portal do Azure, a interface do usuário indicará o status de conclusão. Se ele for iniciado usando a API REST, use o mecanismo de sondagem padrão do Azure Resource Manager para monitorar quanto à conclusão.

Importante

Quando a interrupção que causou o failover geográfico for atenuada use o failover manual planejado para mover o primário de volta para o local original.

Economize nos custos com uma réplica de DR sem licença

Você pode economizar nos custos de licença do SQL Server configurando sua instância gerenciada secundária para ser usada apenas para DR (recuperação de desastre). Para configurar isso, consulte Configurar uma réplica em espera sem licença para a Instância Gerenciada de SQL do Azure.

Desde que a instância secundária não seja usada para cargas de trabalho de leitura, a Microsoft fornece um número gratuito de vCores para corresponder à instância primária. Você ainda é cobrado pela computação e pelo armazenamento usados pela instância secundária. Os grupos de failover dão suporte a apenas uma réplica: a réplica precisa ser uma réplica para leitura ou designada como uma réplica somente de DR.

Habilitar cenários dependentes de objetos dos bancos de dados do sistema

Os bancos de dados de sistema não são replicados para a instância secundária em um grupo de failover. Para habilitar cenários que dependam de objetos dos bancos de dados do sistema, crie os mesmos objetos na instância secundária e os mantenha sincronizados com a instância primária.

Por exemplo, se você planeja usar os mesmos logons na instância secundária, crie-os com o SID idêntico.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Para saber mais, confira Replicação de logons e trabalhos de agente.

Sincronizar as propriedades da instância e as instâncias de políticas de retenção

As instâncias em um grupo de failover permanecem com recursos do Azure separados, e nenhuma alteração feita à configuração da instância primária será replicada automaticamente para a instância secundária. Execute todas as alterações relevantes na instância primária e na secundária. Por exemplo, se você alterar a redundância de armazenamento de backup ou a política de retenção de backup de longo prazo na instância primária, não deixe de fazer a mesma alteração na instância secundária.

Escalar instâncias

É possível escalar ou reduzir verticalmente as instâncias primária e secundária para um tamanho da computação diferente na mesma camada de serviço ou em uma camada de serviço diferente. Ao escalar verticalmente dentro da mesma camada de serviço, recomendamos que você primeiro escale verticalmente o secundário geográfico e, em seguida, escale verticalmente o primário. Ao reduzir verticalmente dentro da mesma camada de serviço, inverta a ordem: primeiro reduza verticalmente o primário e, em seguida, reduza verticalmente o secundário. Essa recomendação é aplicada quando a instância é dimensionada para uma camada de serviço diferente. A sequência de operações é imposta ao colocar em escala a camada de serviço e os vCores, bem como o armazenamento.

A sequência é recomendada especificamente para evitar o problema de o banco de dados em área geográfica secundária com uma SKU inferior ter sobrecarga e precisar ser propagado novamente durante um processo de atualização ou de downgrade.

Observação

Há um problema conhecido que pode afetar a acessibilidade da instância que está sendo dimensionada usando o ouvinte de grupo de failover associado.

Evitar a perda de dados críticos

Devido à alta latência das redes de longa distância, a replicação geográfica usa um mecanismo de replicação assíncrona. Com a replicação assíncrona, é impossível evitar a perda de dados em caso de falha no primário. Para proteger as transações críticas contra a perda de dados, um desenvolvedor de aplicativos pode chamar o procedimento armazenado sp_wait_for_database_copy_sync imediatamente após a confirmação da transação. Chamar sp_wait_for_database_copy_sync bloqueia o thread de chamada até que a última transação confirmada seja transmitida e persistida no log de transações do banco de dados secundário. Contudo, a chamada não aguarda a reprodução (confirmação) das transações transmitidas no secundário. sp_wait_for_database_copy_sync tem escopo para um link de replicação geográfica específico. Qualquer usuário com os direitos de conexão para o banco de dados primário pode chamar este procedimento.

Para evitar a perda de dados durante o failover geográfico planejado iniciado pelo usuário, a replicação muda automática e temporariamente para a replicação síncrona e, em seguida, executa um failover. A replicação retorna ao modo assíncrono após a conclusão do failover geográfico.

Observação

A sp_wait_for_database_copy_sync impede a perda de dados após o failover geográfico para transações específicas, mas não garante a sincronização completa para acesso de leitura. A demora causada por uma chamada de procedimento sp_wait_for_database_copy_sync pode ser significativa e depende do tamanho, no momento da chamada, do log de transações ainda não transmitido no primário.

Status do grupo de failover

O grupo de failover relata o status que descreve o estado atual da replicação de dados:

  • Propagação – a propagação inicial está ocorrendo após a criação do grupo de failover, até que todos os bancos de dados do usuário sejam inicializados na instância secundária. O processo de failover não pode ser iniciado enquanto o grupo de failover estiver no status Propagação, pois os bancos de dados de usuário ainda não foram copiados para a instância secundária.
  • Sincronização – O status normal do grupo de failover. Isso significa que as alterações de dados na instância primária estão sendo replicadas de forma assíncrona para a instância secundária. Esse status não garante que os dados estejam totalmente sincronizados a cada momento. Pode haver alterações de dados do primário ainda a serem replicadas para o secundário devido à natureza assíncrona do processo de replicação entre instâncias no grupo de failover. Os failovers automáticos e manuais podem ser iniciados enquanto o grupo de failover está no status de Sincronização.
  • Failover em andamento – Esse status indica que o processo de failover iniciado automaticamente ou manualmente está em andamento. Nenhuma alteração no grupo de failover ou failovers adicionais pode ser iniciada enquanto o grupo de failover estiver nesse status.

Failback

Quando os grupos de failover estiverem configurados com a política de failover gerenciada pela Microsoft, o failover para o servidor secundário geográfico será iniciado durante um cenário de desastre de acordo com o período de carência definido. O failback para o primário antigo precisará ser iniciado manualmente.

Grupos de failover com replicação transacional

Há suporte para o uso da replicação transacional com instâncias que estão em um grupo de failover. No entanto, se você configurar a replicação antes de adicionar sua instância gerenciada do SQL a um grupo de failover, a replicação será pausada quando você começar a criar seu grupo de failover, e o monitor de replicação mostrará uma status de Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. A replicação é retomada depois que o grupo de failover é criado com êxito.

Se uma Instância Gerenciada de SQL de publicador ou distribuidor estiver em um grupo de failover, o administrador da Instância Gerenciada de SQL deverá limpar todas as publicações no antigo primário e reconfigurá-las no novo primário após a ocorrência de um failover. Revise o guia de replicação transacional para obter a etapa de atividades necessárias nesse cenário.

Permissões, limitações e pré-requisitos

Revise o guia Configurar grupo de failover para obter uma lista de permissões, limitações e pré-requisitos antes de continuar a configurar o grupo de failover.

Gerenciar programaticamente grupos de failover

Os grupos de failover também podem ser gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure e a API REST. Para saber mais, confira Configurar o grupo de failover.

Análises de recuperação de desastre

A maneira recomendada de executar uma análise de DR é usando a recuperação panejada manual, de acordo com o seguinte tutorial: Failover de teste.

Não é recomendado executar uma análise usando o failover forçado, visto que essa operação não fornece proteção contra a perda de dados. No entanto, é possível obter failover forçado sem perda de dados garantindo que as seguintes condições sejam atendidas antes de iniciar o failover forçado:

  • A carga de trabalho é interrompida na instância gerenciada principal.
  • Todas as transações de execução prolongada foram concluídas.
  • Todas as conexões de cliente com a instância gerenciada primária foram desconectadas.
  • O status do grupo de failover é “Sincronizando”.

Verifique se as duas instâncias gerenciadas alternaram de função e se o status do grupo de failover mudou de “Failover em andamento” para “Sincronizando” antes de, como opção, estabelecer conexões com a nova instância gerenciada primária e iniciar a carga de trabalho de leitura/gravação.

Para executar um failback sem perdas de dados para as funções de instância gerenciada originais, é altamente recomendável usar a recuperação panejada manual em vez do failover forçado. Como prosseguir com o failback forçado:

  • Siga as mesmas etapas do failover sem perdas de dados.
  • Um tempo de execução de failback mais longo é esperado se o failback forçado for executado logo após a conclusão do failover forçado inicial, pois ele precisa aguardar a conclusão das operações de backup automático pendentes na instância gerenciada primária anterior.

Conteúdo relacionado