Use grupos de failover automático para habilitar o failover transparente e coordenado de vários bancos de dados

APLICA-SE A: Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

O recurso de grupos de failover automático permite gerenciar a replicação e o failover de um grupo de bancos de dados em um servidor ou de todos os bancos de dados em uma instância gerenciada para outra região. Ele é uma abstração declarativa junto ao recurso de replicação geográfica ativa existente, projetado para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala. Você pode iniciar o failover manualmente ou pode delegá-lo ao serviço do Azure com base em uma política definida pelo usuário. A última opção permite que você recupere automaticamente vários bancos de dados relacionados em uma região secundária após uma falha catastrófica ou outro evento não planejado que resulte em perda total ou parcial de disponibilidade do Banco de Dados SQL ou da Instância Gerenciada de SQL na região primária. Um grupo de failover pode incluir um ou vários bancos de dados, normalmente usados pelo mesmo aplicativo. Além disso, eles podem usar os bancos de dados secundários legíveis para descarregar cargas de trabalho de consulta somente leitura. Como os grupos de failover automático incluem vários bancos de dados, esses bancos de dados devem ser configurados no servidor primário. Os grupos de failover automático dão suporte à replicação de todos os bancos de dados no grupo para apenas um servidor secundário ou uma instância em uma região diferente.

Observação

Atualmente, não há suporte para grupos de failover automático na camada de serviço de Hiperescala. Para o failover geográfico de um banco de dados de Hiperescala, use a replicação geográfica ativa.

Observação

Se você quiser definir vários secundários do Banco de Dados SQL do Azure na mesma região ou em regiões diferentes, use a replicação geográfica ativa.

Ao usar grupos de failover automático com uma política de failover automático, qualquer interrupção que afete um ou vários bancos de dados no grupo resultar em failover automático. Normalmente, esses incidentes não podem ser automitigados pelas operações de alta disponibilidade automáticas internas. Os exemplos de gatilhos de failover incluem um incidente causado por um anel de controle ou anel de locatário do Banco de Dados SQL desativado devido a uma perda de memória de kernel do sistema operacional em vários nós de computação ou um incidente causado por um ou mais anéis de locatário desativados porque o cabo de rede incorreto foi cortado durante a rotina de encerramento do hardware. Para saber mais, confira Alta disponibilidade do Banco de Dados SQL.

Além disso, os grupos de failover automático fornecem pontos de extremidade de ouvinte de leitura/gravação e somente leitura que permanecem inalterados durante failovers. Não importa se você usa a ativação de failover manual ou automática, o failover alterna todos os bancos de dados secundários no grupo para primário. Após o failover de banco de dados ser concluído, o registro DNS é atualizado automaticamente para redirecionar os pontos de extremidade para a nova região. Para os dados específicos de RPO e RTO, confira Visão geral da continuidade de negócios.

Ao usar grupos de failover automático com uma política de failover automático, qualquer interrupção que afete bancos de dados no servidor ou na instância gerenciada resulta em um failover automático. Você pode gerenciar o grupo de failover automático usando:

Após o failover, verifique se os requisitos de autenticação para o banco de dados e o servidor ou a instância estão configurados no novo primário. Para obter detalhes, consulte Segurança do Banco de Dados SQL do Azure após a recuperação de desastre.

Para garantir a continuidade de negócios real, a adição de redundância de banco de dados entre datacenters é apenas parte da solução. 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. Para obter mais informações sobre como criar soluções para a recuperação de desastre, veja Criando soluções de nuvem para a recuperação de desastre usando a replicação geográfica ativa.

Terminologia e recursos

  • FOG (grupo de failover)

    Um grupo de failover é um grupo nomeado de bancos de dados gerenciados por um único servidor ou dentro de uma instância gerenciada que pode fazer failover como uma unidade para outra região caso alguns ou todos os bancos de dados primários não estejam disponíveis devido a uma interrupção na região primária. Quando criado para a Instância Gerenciada de SQL, um grupo de failover contém todos os bancos de dados de usuário na instância e, portanto, é 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.

  • Servidores

    Com os servidores, alguns ou todos os bancos de dados de usuário em um servidor podem ser colocados em um grupo de failover. Além disso, um servidor dá suporte a vários grupos de failover em um único servidor.

  • Primário

    O servidor ou 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 primário.

  • Adicionar bancos de dados individuais ao grupo de failover

    É possível colocar vários bancos de dados individuais no mesmo servidor no mesmo grupo de failover. Se você adicionar um banco de dados individual ao grupo de failover, ele criará automaticamente um banco de dados secundário usando a mesma edição e tamanho da computação no servidor secundário. Você especificou esse servidor ao criar o grupo de failover. Se você adicionar um banco de dados que já possui um banco de dados secundário no servidor secundário, esse vínculo de replicação geográfica é herdado pelo grupo. Quando você adiciona um banco de dados que já tem um banco de dados secundário em um servidor que não faz parte do grupo de failover, um novo banco de dados secundário é criado no servidor secundário.

    Importante

    O servidor secundário não pode ter um banco de dados com o mesmo nome, a menos que seja um banco de dados secundário existente. Nos grupos de failover para a Instância Gerenciada de SQL, todos os bancos de dados de usuário são replicados. Você não pode escolher um subconjunto de bancos de dados de usuário para replicação no grupo de failover.

  • Adicionar bancos de dados no pool elástico para o grupo de failover

    É possível colocar todos ou vários bancos de dados dentro de um pool elástico no mesmo grupo de failover. Se o banco de dados primário estiver em um pool elástico, o banco de dados secundário é criado automaticamente no pool elástico com o mesmo nome (pool secundário). Você deve garantir que o servidor secundário contém um pool elástico com exatamente o mesmo nome e capacidade livre suficiente para hospedar os bancos de dados secundários que serão criados pelo grupo de failover. Se você adicionar um banco de dados no pool que já possui um banco de dados secundário no pool secundário, esse vínculo de replicação geográfica é herdado pelo grupo. Quando você adiciona um banco de dados que já tem um banco de dados secundário em um servidor que não faz parte do grupo de failover, um novo banco de dados secundário é criado no pool secundário.

  • Propagação inicial

    Ao adicionar bancos de dados, pools elásticos ou instâncias gerenciadas a um grupo de failover, há uma fase de propagação inicial antes que a replicação de dados comece. A fase de propagação inicial é a operação mais longa e cara. 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 que leva para a propagação inicial ser concluída depende do tamanho de seus dados, do número de bancos de dados replicados, da carga nos bancos de dados primários e da velocidade do link entre o primário e o secundário. Em circunstâncias normais, a possível velocidade de propagação é de até 500 GB por hora para o Banco de Dados SQL e de até 360 GB por hora para a Instância Gerenciada de SQL. A propagação é executada em todos os bancos de dados em paralelo.

    Para a Instância Gerenciada de SQL, considere a velocidade do link do ExpressRoute entre as duas instâncias ao estimar o tempo da fase de propagação inicial. Caso a velocidade do link entre as duas instâncias seja mais lenta do que o necessário, é provável que o tempo de propagação seja 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 levará cerca de dez horas. Se houver vários bancos de dados para serem replicados, a propagação será executada em paralelo e, quando combinada com uma velocidade de link lenta, a fase de propagação inicial poderá levar muito mais tempo, especialmente se a propagação paralela de dados de todos os bancos de dados exceder a largura de banda de link disponível. Se a largura de banda de rede entre duas instâncias for limitada e você estiver adicionando várias instâncias gerenciadas a um grupo de failover, considere adicionar sequencialmente várias instâncias gerenciadas, uma a uma, ao grupo de failover. Considerando um SKU de gateway de tamanho adequado entre as duas instâncias gerenciadas, e se a largura de banda da rede corporativa permitir, será possível alcançar velocidades de até 360 GB por hora.

  • 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.

    Observação

    Uma ID de zona DNS não é necessária em grupos de failover criados para o Banco de Dados SQL.

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

    Um registro CNAME DNS que aponta para a URL 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 forma transparente ao banco de dados primário quando o primário é alterado após o failover. Quando o grupo de failover é criado em um servidor, o registro CNAME DNS para a URL do ouvinte é formado como <fog-name>.database.windows.net. 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

    Foi formado um registro CNAME de DNS que aponta ao ouvinte somente leitura que aponta à URL do secundário. Ele é criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho SQL somente leitura se conecte de forma transparente ao secundário usando as regras de balanceamento de carga especificadas. Quando o grupo de failover é criado em um servidor, o registro DNS CNAME para a URL do ouvinte é formado como <fog-name>.secondary.database.windows.net. 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.

  • Política de failover automático

    Por padrão, um grupo de failover é configurado com uma política de failover automático. O sistema dispara um failover após a falha ser detectada e o período de cortesia expirar. O sistema deve verificar se a interrupção não pode ser mitigada pela infraestrutura de alta disponibilidade interna devido à escala do impacto. Se você quiser controlar o fluxo de trabalho de failover pelo aplicativo ou manualmente, poderá desativar o failover automático.

    Observação

    Como a verificação da escala da interrupção e da rapidez com que ela pode ser mitigada envolve ações humanas, o período de cortesia não pode ser definido abaixo de uma hora. Essa limitação se aplica a todos os bancos de dados no grupo de failover, independentemente de seu estado de sincronização de dados.

  • Política de failover somente leitura

    Por padrão, o failover do ouvinte somente leitura é desabilitado. Isso 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 será 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 automático estiver habilitada e um failover automático 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.

  • Failover planejado

    O failover planejado 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 planejado é usado nos seguintes cenários:

    • Executar a recuperação de desastre em produção quando a perda de dados não é aceitável
    • Relocar os bancos de dados para uma região diferente
    • Retorne os bancos de dados para a região primária após a atenuação da interrupção (failback)
  • Failover não planejado

    O failover não planejado ou 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 perda de dados. Um failover não planejado é 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 planejado pode ser executado para realizar o failback, retornando as réplicas para suas funções primárias e secundárias originais.

  • Failover manual

    Você pode iniciar o failover manualmente a qualquer momento, independentemente da configuração de failover automático. Durante uma interrupção que afete o primário, se a política de failover automático não estiver configurada, um failover manual será necessário para promover o secundário para a função primária. Você pode iniciar um failover forçado (não planejado) ou amigável (planejado). Um failover amigável só é possível quando o primário antigo está acessível e pode ser usado para realocar o primário para a região secundária sem perda de dados. Quando o failover estiver concluído, os registros DNS serão atualizados automaticamente para garantir a conectividade com o novo primário.

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

    Como os bancos de dados secundários são sincronizados usando replicação assíncrona, um failover automático pode resultar em perda de dados. Você pode personalizar a política de failover automático para refletir a tolerância do seu aplicativo à perda de dados. Ao configurar GracePeriodWithDataLossHours, você pode controlar quanto tempo o sistema espera antes de iniciar um failover forçado, o que pode resultar em perda de dados.

  • Vários grupos de failover

    Você pode configurar vários grupos de failover para o mesmo par de servidores a fim de controlar o escopo de failovers. Cada grupo sofre failover de forma independente. Se seu aplicativo multilocatário usa pools elásticos, você pode usar esse recurso para misturar os bancos de dados primários e secundários em cada pool. Dessa forma, você pode reduzir o impacto de uma interrupção a somente metade dos locatários.

    Observação

    A Instância Gerenciada de SQL não dá suporte ao uso de vários grupos de failover.

Permissões

As permissões para um grupo de failover são gerenciadas por meio do RBAC (controle de acesso baseado em função) do Azure. A função de Colaborador do SQL Server tem todas as permissões necessárias para gerenciar grupos de failover.

Criar grupo de failover

Para criar um grupo de failover, você precisa de acesso de gravação do RBAC do Azure aos servidores primários e secundários e a todos os bancos de dados no grupo de failover. Para uma Instância Gerenciada de SQL, você precisa de acesso de gravação do RBAC do Azure às Instâncias Gerenciadas de SQL primária e secundária, mas as permissões em bancos de dados individuais não são relevantes, pois os bancos de dados da Instância Gerenciada de SQL individuais não podem ser adicionados a um grupo de failover nem removidos dele.

Atualizar um grupo de failover

Para atualizar um grupo de failover, você precisa de acesso de gravação do RBAC do Azure a esse grupo e a todos os bancos de dados no servidor primário atual ou na instância gerenciada.

Fazer failover de um grupo de failover

Para fazer failover de um grupo de failover, você precisa de acesso de gravação do RBAC do Azure a esse grupo no novo servidor primário ou na instância gerenciada.

Práticas recomendadas para o Banco de Dados SQL

O grupo de failover automático precisa ser configurado no servidor primário e o conectará ao servidor secundário em outra região do Azure. Os grupos podem incluir alguns ou todos os bancos de dados nesses servidores. O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando vários bancos de dados e um grupo de failover automático.

O diagrama mostra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando vários bancos de dados e um grupo de failover automático.

Observação

Confira Adicionar Banco de Dados SQL a um grupo de failover para obter um tutorial passo a passo detalhado de como adicionar um banco de dados do Banco de Dados SQL a um grupo de failover.

Ao projetar um serviço pensando em continuidade de negócios, siga estas diretrizes gerais:

Usar um ou vários grupos de failover para gerenciar failover de vários bancos de dados

Um ou mais grupos de failover podem ser criados entre dois servidores em diferentes regiões (servidores primário e secundário). Cada grupo pode conter um ou vários bancos de dados que são recuperados como uma unidade no caso de alguns ou todos os bancos de dados primários ficarem indisponíveis devido a uma interrupção na região primária. O grupo de failover cria um banco de dados geograficamente secundário com o mesmo objetivo de serviço do primário. Se você adicionar uma relação de replicação geográfica existente ao grupo de failover, certifique-se de que o geograficamente secundário esteja configurado com o mesmo nível de serviço e tamanho da computação do primário.

Usar o ouvinte de leitura/gravação para carga de trabalho OLTP

Ao executar operações de OLTP, use <fog-name>.database.windows.net como a URL do servidor e as conexões são direcionadas automaticamente para o primário. Essa URL não é alterada após o failover. Observe que o failover envolve a atualização do registro DNS, para que conexões de cliente sejam redirecionadas ao novo primário somente após a atualização do cliente do cache DNS.

Usar o ouvinte somente leitura para a carga de trabalho somente leitura

Se houver uma carga de trabalho somente leitura logicamente isolada que seja tolerante a determinadas desatualizações de dados, você poderá usar o banco de dados secundário no aplicativo. Para sessões somente leitura, use <fog-name>.secondary.database.windows.net como a URL do servidor e a conexão é direcionada automaticamente para o secundário. Também recomendamos que você indique a intenção de leitura na cadeia de conexão usando ApplicationIntent=ReadOnly.

Observação

Nas camadas de serviço Premium, Comercialmente Crítico e Hiperescala, o Banco de Dados 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. Quando você tiver configurado 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>.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.database.windows.net.

Preparar para degradação do desempenho

Um aplicativo típico do Azure usa vários serviços do Azure e consiste em vários componentes. O failover automatizado 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 de DR, a latência entre os componentes dependentes poderá aumentar. Para evitar o impacto da latência mais alta no desempenho do aplicativo, garanta a redundância de todos os componentes do aplicativo na região de DR e siga estas diretrizes de segurança de rede.

Preparar para perda de dados

Se uma interrupção for detectada, o Azure aguardará o período que você especificou em GracePeriodWithDataLossHours. O valor padrão é de 1 hora. Se você não puder perder dados, defina GracePeriodWithDataLossHours com um número grande o suficiente, como 24 horas. Use o failover manual do grupo para fazer failback do secundário para primário.

Importante

Os pools elásticos com 800 ou menos DTUs e mais de 250 bancos de dados usando a replicação geográfica podem encontrar problemas, incluindo failovers planejados mais longos e diminuição do desempenho. A ocorrência desses problemas é mais provável para cargas de trabalho com uso intensivo de gravação, quando os pontos de extremidade de replicação geográfica são separados por uma grande extensão geográfica ou quando vários pontos de extremidade secundários são usados para cada banco de dados. Os sintomas desses problemas são indicados quando o retardo da replicação geográfica aumenta ao longo do tempo. Esse retardo pode ser monitorado usando sys.dm_geo_replication_link_status. Se esses problemas ocorrerem, considere mitigações como aumentar o número de DTUs do pool ou reduzir o número de bancos de dados replicados geograficamente no mesmo pool.

Alterar a região secundária do grupo de failover

Para ilustrar a sequência de alteração, vamos pressupor que o servidor A é o servidor primário, o servidor B é o servidor secundário existente e o servidor C é o novo secundário na terceira região. Para fazer a transição, siga estas etapas:

  1. Crie secundários adicionais de cada banco de dados no servidor A para o servidor C usando a replicação geográfica ativa. Cada banco de dados no servidor A terá dois secundários, um no servidor B e outro no servidor C. Isso garantirá que os bancos de dados primários permaneçam protegidos durante a transição.
  2. Exclua o grupo de failover. Neste ponto, os logons falharão. Isso ocorre porque os aliases do SQL para os ouvintes do grupo de failover foram excluídos e o gateway não reconhecerá o nome do grupo de failover.
  3. Crie novamente o grupo de failover com o mesmo nome entre os servidores A e C. Neste ponto, os logons não falharão mais.
  4. Adicione todos os bancos de dados primários do servidor A ao novo grupo de failover.
  5. Remova o servidor B. Todos os bancos de dados no B serão excluídos automaticamente.

Alterar a região primária do grupo de failover

Para ilustrar a sequência de alteração, vamos pressupor que o servidor A é o servidor primário, o servidor B é o servidor secundário existente e o servidor C é o novo primário na terceira região. Para fazer a transição, siga estas etapas:

  1. Execute um failover planejado a fim de alternar o servidor primário para B. O servidor A se tornará o novo servidor secundário. O failover pode resultar em vários minutos de tempo de inatividade. O tempo real dependerá do tamanho do grupo de failover.
  2. Crie secundários adicionais de cada banco de dados no servidor B para o servidor C usando a replicação geográfica ativa. Cada banco de dados no servidor B terá dois secundários, um no servidor A e outro no servidor C. Isso garantirá que os bancos de dados primários permaneçam protegidos durante a transição.
  3. Exclua o grupo de failover. Neste ponto, os logons falharão. Isso ocorre porque os aliases do SQL para os ouvintes do grupo de failover foram excluídos e o gateway não reconhecerá o nome do grupo de failover.
  4. Crie novamente o grupo de failover com o mesmo nome entre os servidores B e C. Neste ponto, os logons não falharão mais.
  5. Adicione todos os bancos de dados primários do B ao novo grupo de failover.
  6. Execute um failover planejado do grupo de failover para alternar de B para C. Agora, o servidor C se tornará o primário e o B será o secundário. Todos os bancos de dados secundários no servidor A serão vinculados automaticamente aos primários em C. Como na etapa 1, o failover pode resultar em vários minutos de inatividade.
  7. Descarte o servidor A. Todos os bancos de dados em A serão excluídos automaticamente.

Importante

Quando o grupo de failover é excluído, os registros DNS dos pontos de extremidade do ouvinte também são excluídos. Neste ponto, há uma probabilidade diferente de zero de outra pessoa criar um grupo de failover ou alias de servidor com o mesmo nome, o que impedirá você de usá-lo novamente. Para minimizar o risco, não use nomes genéricos em grupos de failover.

Melhores práticas para a Instância Gerenciada de SQL

O grupo de failover automático 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 de 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 automático.

diagrama de failover automático

Observação

Confira Adicionar instância gerenciada a um grupo de failover a fim de obter um tutorial passo a passo detalhado de como adicionar uma Instância Gerenciada de SQL para usar o grupo de failover.

Se o aplicativo usar a Instância Gerenciada de SQL como a camada de dados, siga estas diretrizes gerais ao criar buscando continuidade dos negócios:

Criar a instância secundária

Para garantir conectividade ininterrupta à Instância Gerenciada de SQL primária após o failover, ambas as instâncias primária e secundária precisam estar na mesma zona DNS. Isso garantirá 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 o parâmetro opcional durante a criação. Se você estiver usando o PowerShell ou a API REST, o nome do parâmetro opcional será DNS Zone Partner e o nome do campo opcional correspondente no portal do Azure será a Instância Gerenciada Primária.

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 Criar uma instância gerenciada secundária.

Usar regiões emparelhadas geograficamente

Implante ambas as instâncias gerenciadas em regiões emparelhadas por motivos de desempenho. As instâncias gerenciadas que residem em regiões emparelhadas geograficamente têm um desempenho muito melhor em comparação com regiões não emparelhadas.

Permitir o tráfego de replicação entre duas instâncias

Já que cada instância é isolada em sua própria rede virtual, o tráfego em duas vias entre essas redes virtuais deve ser permitido. Confira Gateway de VPN do Azure

Criação de um grupo de failover entre instâncias gerenciadas em assinaturas diferentes

Você pode criar um grupo de failover entre Instâncias Gerenciadas de SQL em duas assinaturas diferentes, desde que as assinaturas estejam associadas ao mesmo locatário do Azure Active Directory. Ao usar a API do PowerShell, você pode fazer isso especificando o parâmetro PartnerSubscriptionId para a Instância Gerenciada de SQL secundária. Ao usar a API REST, cada ID de instância incluída no parâmetro properties.managedInstancePairs pode ter sua própria subscriptionID.

Importante

O portal do Azure não dá suporte à criação de grupos de failover em assinaturas diferentes. Além disso, em grupos de failover existentes em diferentes assinaturas e/ou grupos de recursos, o failover não pode ser iniciado manualmente por meio do portal pela Instância Gerenciada de SQL primária. Em vez disso, inicie-o na instância secundária geográfica.

Gerenciamento de failover para a instância secundária

O grupo de failover gerenciará o failover de todos os bancos de dados na Instância Gerenciada de SQL. Quando um grupo é criado, cada banco de dados na instância será replicado geograficamente de modo automático para a Instância Gerenciada de SQL secundária. Não é possível usar grupos de failover para iniciar um failover parcial de um subconjunto dos bancos de dados.

Importante

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

Usar o ouvinte de leitura/gravação para carga de trabalho OLTP

Ao executar operações de OLTP, use <fog-name>.zone_id.database.windows.net como a URL do servidor e as conexões são direcionadas automaticamente para o primário. Essa URL não é alterada após o failover. O failover envolve a atualização do registro DNS, para que 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.

Usar o ouvinte somente leitura para se conectar à instância secundária

Se houver uma carga de trabalho somente leitura logicamente isolada que seja tolerante a determinadas desatualizações de dados, você poderá usar o banco de dados secundário no aplicativo. Para se conectar diretamente ao secundário com replicação geográfica, use <fog-name>.secondary.<zone_id>.database.windows.net como a URL do servidor.

Observação

Na camada Comercialmente Crítica, 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. Quando você tiver configurado 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.

Preparar para degradação do desempenho

Um aplicativo típico do Azure usa vários serviços do Azure e consiste em vários componentes. O failover automatizado 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. Para evitar o impacto da maior latência no desempenho do aplicativo, 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. No momento da configuração, siga as diretrizes de segurança de rede para garantir a conectividade com o banco de dados na região secundária.

Preparar para perda de dados

Quando uma falha for detectada, um failover de leitura-gravação será acionado se não houver perda de dados, até onde nós sabemos. Caso contrário, o failover será adiado para o período especificado usando GracePeriodWithDataLossHours. Se você especificou GracePeriodWithDataLossHours, esteja preparado para perda de dados. Em geral, durante interrupções, o Azure favorece a disponibilidade. Se você não puder perder dados, defina GracePeriodWithDataLossHours com um número grande o suficiente, como 24 horas, ou desabilite o failover automático.

A atualização do DNS do ouvinte de leitura-gravação ocorrerá imediatamente após o início do failover. Esta 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 do primário 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 é iniciado usando a API REST, use o mecanismo de sondagem padrão do Azure Resource Manager para monitorar quanto à conclusão.

Importante

Use o failover manual de grupo para mover os primários de volta para a localização original. Quando a interrupção que causou o failover for atenuada, você poderá mover seus bancos de dados primários para a localização original. Para fazer isso, você deve iniciar o failover manual do grupo.

Alterar a região secundária do grupo de failover

Vamos supor que a instância A é a primária, a instância B é a secundária existente e a instância C é a nova instância secundária na terceira região. Para fazer a transição, siga estas etapas:

  1. Crie a instância C com o mesmo tamanho de A na mesma zona DNS.
  2. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, os logons falharão porque os aliases do SQL para os ouvintes do grupo de failover foram excluídos e o gateway não reconhecerá o nome do grupo de failover. Os bancos de dados secundários serão desconectados dos primários e se tornarão bancos de dados de leitura/gravação.
  3. Crie um grupo de failover com o mesmo nome entre a instância A e C. Siga as instruções no tutorial do grupo de failover com a Instância Gerenciada de SQL. Essa é uma operação de tamanho de dados e será concluída quando todos os bancos de dados da instância A forem propagados e sincronizados.
  4. Exclua a instância B se não for necessária para evitar encargos indevidos.

Observação

Após a etapa 2 e até que a etapa 3 seja concluída, os bancos de dados na instância A permanecerão desprotegidos contra uma falha catastrófica da instância A.

Alterar a região primária do grupo de failover

Vamos supor que a instância A é a primária, a instância B é a secundária existente e a instância C é a nova instância primária na terceira região. Para fazer a transição, siga estas etapas:

  1. Crie a instância C com o mesmo tamanho de B na mesma zona DNS.
  2. Conecte-se à instância B e faça o failover manualmente para alternar a instância primária para B. A instância A se tornará a nova instância secundária de forma automática.
  3. Exclua o grupo de failover entre as instâncias A e B. Neste ponto, os logons falharão porque os aliases do SQL para os ouvintes do grupo de failover foram excluídos e o gateway não reconhecerá o nome do grupo de failover. Os bancos de dados secundários serão desconectados dos primários e se tornarão bancos de dados de leitura/gravação.
  4. Crie um grupo de failover com o mesmo nome entre a instância A e C. Siga as instruções no tutorial do grupo de failover com instância gerenciada. Essa é uma operação de tamanho de dados e será concluída quando todos os bancos de dados da instância A forem propagados e sincronizados.
  5. Exclua a instância A se não for necessária para evitar encargos indevidos.

Cuidado

Após a etapa 3 e até que a etapa 4 seja concluída, os bancos de dados na instância A permanecerão desprotegidos contra uma falha catastrófica da instância A.

Importante

Quando o grupo de failover é excluído, os registros DNS dos pontos de extremidade do ouvinte também são excluídos. Neste ponto, há uma probabilidade diferente de zero de outra pessoa criar um grupo de failover ou alias de servidor com o mesmo nome, o que impedirá você de usá-lo novamente. Para minimizar o risco, não use nomes genéricos em grupos de failover.

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>;

Sincronizar as propriedades da instância e as políticas de retenção entre a instância primária e secundária

As instâncias no 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.

Grupos de failover e a segurança de rede

Em alguns aplicativos, as regras de segurança exigem que o acesso da rede à camada de dados seja restrito a componentes específicos, como uma VM, um serviço Web etc. Esse requisito apresenta alguns desafios para o design de continuidade dos negócios e o uso dos grupos de failover. Considere as opções a seguir ao implementar tal acesso restrito.

Como usar grupos de failover e regras da rede virtual

Se você está usando pontos de extremidade e regras de serviço de Rede Virtual para restringir o acesso ao seu banco de dados no Banco de Dados SQL ou na Instância Gerenciada de SQL, lembre-se de que cada ponto de extremidade de serviço de rede virtual se aplica a apenas uma região do Azure. O ponto de extremidade não permite que outras regiões aceitem a comunicação da sub-rede. Portanto, apenas os aplicativos implantados na mesma região do cliente podem se conectar ao banco de dados primário. Uma vez que o failover resulta no redirecionamento de sessões de cliente do Banco de Dados SQL para um servidor em uma região diferente (secundária), essas sessões falharão se forem originadas em um cliente fora dessa região. Por esse motivo, a política de failover automático não poderá ser habilitada se os servidores participantes ou instâncias estiverem incluídos nas regras de Rede Virtual. Para dar suporte a failover manual, siga estas etapas:

  1. Provisione as cópias redundantes dos componentes front-end do seu aplicativo (serviço Web, máquinas virtuais etc.) na região secundária
  2. Configurar as regras da rede virtual individualmente para os servidores primário e secundário
  3. Habilitar o failover front-end usando uma configuração do Gerenciador de tráfego
  4. Iniciar o failover manual quando a interrupção for detectada. Essa opção é otimizada para os aplicativos que precisam de latência consistente entre o front-end e a camada de dados e oferece suporte à recuperação quando o front-end, a camada de dados ou ambos são afetados pela interrupção.

Observação

Se você estiver usando o ouvinte somente leitura para balanceamento de uma carga de trabalho somente leitura, essa carga de trabalho deverá ser executada em uma VM ou outro recurso na região secundária para que possa se conectar ao banco de dados secundário.

Usar grupos de failover e regras de firewall

Se o seu plano de continuidade dos negócios exigir failover usando grupos com failover automático, você poderá restringir o acesso ao seu banco de dados no Banco de Dados SQL usando as regras de firewall tradicionais. Para dar suporte a failover automático, siga estas etapas:

  1. Criar um IP público
  2. Crie um balanceador de carga público e atribua o IP público a ele.
  3. Crie uma rede virtual e as máquinas virtuais para os componentes de front-end
  4. Crie um grupo de segurança de rede e configure conexões de entrada.
  5. Verifique se as conexões de saída estão abertas para o Banco de Dados SQL do Azure usando a marca de serviço "Sql".
  6. Crie uma regra de firewall de Banco de Dados SQL para permitir o tráfego de entrada do endereço IP público criado na etapa 1.

Para obter mais informações de como configurar o acesso de saída e qual IP usar nas regras de firewall, confira Conexões de saída do balanceador de carga.

A configuração acima garantirá que o failover automático não bloqueie conexões dos componentes front-end e pressupõe que o aplicativo pode tolerar a latência mais longa entre o front-end e a camada de dados.

Importante

Para garantir a continuidade dos negócios para interrupções regionais, garanta redundância geográfica para bancos de dados e componentes de front-end.

Habilitar a replicação geográfica entre instâncias gerenciadas e suas VNets

Quando você configura um grupo de failover entre as Instâncias Gerenciadas de SQL primária e secundária em duas regiões diferentes, cada instância é isolada usando uma rede virtual independente. Para permitir o tráfego de replicação entre essas VNets, verifique se estes pré-requisitos foram atendidos:

  • As duas instâncias da Instância Gerenciada de SQL precisam estar em regiões diferentes do Azure.

  • As duas instâncias da Instância Gerenciada de SQL precisam ser da mesma camada de serviço e ter o mesmo tamanho de armazenamento.

  • Sua instância secundária da Instância Gerenciada de SQL deve estar vazia (nenhum banco de dados de usuário).

  • As redes virtuais usadas pelas instâncias da Instância Gerenciada de SQL precisam ser conectadas por meio de um Gateway de VPN ou do ExpressRoute. Quando duas redes virtuais se conectam por meio de uma rede local, verifique se não há nenhuma regra de firewall bloqueando as portas 5022 e 11000-11999. O emparelhamento de VNet global é compatível com a limitação descrita na observação abaixo.

    Importante

    Em 22/09/2020, o suporte para emparelhamento de rede virtual global para clusters virtuais recém-criados foi anunciado. Isso significa que o emparelhamento de rede virtual global é compatível com as instâncias gerenciadas do SQL criadas nas sub-redes vazias após a data do comunicado, bem como para todas as instâncias gerenciadas subsequentes criadas nessas sub-redes. Em todas as outras instâncias gerenciadas do SQL, o suporte ao emparelhamento é limitado às redes na mesma região devido às restrições do emparelhamento de rede virtual global. Consulte também a seção relevante do artigo com Perguntas frequentes sobre Redes Virtuais do Azure para mais detalhes. Para usar o emparelhamento de rede virtual global para instâncias gerenciadas do SQL em clusters virtuais criados antes da data do anúncio, considere configurar janelas de manutenção não padrão nas instâncias, pois assim as instâncias serão movidas para novos clusters virtuais que dão suporte para o emparelhamento de rede virtual global.

  • As duas VNets da Instância Gerenciada de SQL não podem ter endereços IP sobrepostos.

  • Você precisa configurar seus NSGs (Grupos de Segurança de Rede) de modo que as portas 5022 e o intervalo 11000~12000 sejam conexões abertas de entrada e saída para a sub-rede da outra instância gerenciada. Isso é para permitir o tráfego de replicação entre as instâncias.

    Importante

    Regras de segurança de NSG mal configuradas resultam em operações de cópia de banco de dados paralisadas.

  • A Instância Gerenciada de SQL secundária está configurada com a ID de zona DNS correta. A zona DNS é uma propriedade de uma Instância Gerenciada de SQL e do cluster virtual subjacente, e sua ID é incluída no endereço do nome do host. A ID da zona é gerada como uma cadeia de caracteres aleatória quando a primeira Instância Gerenciada de SQL é criada em cada VNet, e a mesma ID é atribuída a todas as outras instâncias na mesma sub-rede. Uma vez atribuída, a zona DNS não pode ser modificada. As Instâncias Gerenciadas de SQL incluídas no mesmo grupo de failover devem compartilhar a zona DNS. Você consegue isso passando a ID da zona da instância primária como o valor do parâmetro DnsZonePartner ao criar a instância secundária.

    Observação

    Para obter um tutorial detalhado sobre como configurar grupos de failover com a Instância Gerenciada de SQL, confira Adicionar uma Instância Gerenciada de SQL a um grupo de failover.

Atualizar ou fazer downgrade de um banco de dados primário

É possível atualizar ou fazer downgrade de um banco de dados primário para um tamanho da computação diferente sem desconectar nenhum banco de dados secundário. Ao atualizar, recomendamos que você atualize primeiro todos os bancos de dados secundários e depois atualize o primário. Ao fazer downgrade, inverta a ordem: faça primeiro o downgrade do banco de dados primário e depois o de todos os bancos de dados secundários. Quando você atualiza ou faz downgrade do banco de dados para uma camada de serviço diferente essa recomendação é imposta.

Essa sequência é recomendada especificamente para evitar o problema em que o secundário em uma SKU inferior fica sobrecarregado e deve ser propagado novamente durante um processo de atualização ou de downgrade. Você também pode evitar o problema tornando o primário somente leitura, em detrimento de afetar todas as cargas de trabalho de leitura/gravação em relação ao primário.

Observação

Caso você tenha criado um banco de dados secundário como parte da configuração do grupo de failover, não é recomendável fazer o downgrade do banco de dados secundário. Isso é para garantir que sua camada de dados tenha capacidade suficiente para processar sua carga de trabalho normal após o failover ser ativado.

Evitando a perda de dados críticos

Devido à alta latência das redes de longa distância, a cópia contínua usa um mecanismo de replicação assíncrona. A replicação assíncrona tornará a perda de alguns dados inevitável se ocorrer uma falha. No entanto, alguns aplicativos podem exigir nenhuma perda de dados. Para proteger essas atualizações críticas, um desenvolvedor de aplicativo pode chamar o procedimento de sistema sp_wait_for_database_copy_sync imediatamente após a confirmação da transação. A chamada de sp_wait_for_database_copy_sync bloqueia o thread de chamada até que a última transação confirmada seja transmitida para o banco de dados secundário. Contudo, a chamada não aguarda as transações transmitidas serem reproduzidas e confirmadas no banco de dados secundário. sp_wait_for_database_copy_sync está no escopo de um link de cópia contínua específico. Qualquer usuário com os direitos de conexão para o banco de dados primário pode chamar este procedimento.

Observação

sp_wait_for_database_copy_sync impede a perda de dados depois de um failover, 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 do log de transações no momento da chamada.

Grupos de failover e restauração pontual

Para obter informações sobre como usar a restauração pontual com grupos de failover, confira a PITR (recuperação pontual).

Limitações de grupos de failover

Esteja ciente das seguintes limitações:

  • Os grupos de failover não podem ser criados entre dois servidores ou duas instâncias na mesma região do Azure.
  • Os grupos de failover não podem ser renomeados. Será necessário excluir o grupo e recriá-lo com um nome diferente.
  • Não há suporte para renomeação de banco de dados em instâncias no grupo de failover. Você precisará excluir temporariamente o grupo de failover para poder renomear um banco de dados.
  • Os bancos de dados de sistema não são replicados para a instância secundária em um grupo de failover. Portanto, os cenários que dependem de objetos dos bancos de dados do sistema exigem que os objetos sejam criados manualmente nas instâncias secundárias e também sejam mantidos manualmente em sincronia após as alterações feitas na instância primária. A única exceção é a SMK (chave mestra de serviço) de Instância Gerenciada de SQL, que é replicada automaticamente na instância secundária durante a criação do grupo de failover. Quaisquer alterações subsequentes do SMK na instância primária, no entanto, não serão replicadas na instância secundária.
  • Se uma instância participar de um grupo de failover automático, a alteração do tipo de conexão da instância não entrará em vigor no caso das conexões estabelecidas por meio do ponto de extremidade do ouvinte do grupo de failover. Você precisará excluir e recriar temporariamente o grupo de failover automático para que a alteração do tipo de conexão entre em vigor.

Gerenciando os grupos de failover programaticamente

Conforme discutido anteriormente, os grupos de failover automático e a replicação geográfica ativa podem ser gerenciados programaticamente usando o Azure PowerShell e a API REST. As tabelas a seguir descrevem o conjunto de comandos disponíveis. A replicação geográfica ativa inclui um conjunto de APIs do Azure Resource Manager para gerenciamento, incluindo a API REST do Banco de Dados SQL do Azure e cmdlets do Azure PowerShell. Essas APIs exigem o uso de grupos de recursos e dão suporte ao RBAC do Azure (controle de acesso baseado em função do Azure). Para obter mais informações sobre como implementar funções de acesso, confira RBAC (controle de acesso baseado em função) do Azure.

Gerenciar failover do Banco de Dados SQL

Cmdlet Descrição
New-AzSqlDatabaseFailoverGroup Esse comando cria um grupo de failover e registra-o nos servidores primário e secundário
Remove-AzSqlDatabaseFailoverGroup Remove o grupo de failover do servidor
Get-AzSqlDatabaseFailoverGroup Recupera a configuração de um grupo de failover
Set-AzSqlDatabaseFailoverGroup Modifica a configuração de um grupo de failover
Switch-AzSqlDatabaseFailoverGroup Dispara o failover de um grupo de failover para o servidor secundário
Add-AzSqlDatabaseToFailoverGroup Adiciona um ou mais bancos de dados a um grupo de failover

Gerenciar failover de Instância Gerenciada de SQL

Cmdlet Descrição
New-AzSqlDatabaseInstanceFailoverGroup Esse comando cria e registra um grupo de failover nas instâncias primária e secundária
Set-AzSqlDatabaseInstanceFailoverGroup Modifica a configuração de um grupo de failover
Get-AzSqlDatabaseInstanceFailoverGroup Recupera a configuração de um grupo de failover
Switch-AzSqlDatabaseInstanceFailoverGroup Dispara o failover de um grupo de failover para a instância secundária
Remove-AzSqlDatabaseInstanceFailoverGroup Remove um grupo de failover

Próximas etapas