Visão geral dos grupos de failover na Instância Gerenciada do Azure SQL e práticas recomendadas

Aplica-se a:Instância Gerida do SQL do Azure

Este artigo fornece uma visão geral do recurso de grupo de failover com práticas recomendadas e recomendações para usar com a Instância Gerenciada 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ários em uma instância gerenciada pelo SQL para outra região do Azure.

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

Visão geral

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

Para mais informações, consulte Alta disponibilidade para a Instância Gerida do Azure SQL. Para o RPO e RTO de failover geográfico, consulte a visão geral de continuidade de negócios.

Redirecionamento de ponto final

Os grupos de failover fornecem pontos de extremidade de escuta somente leitura e leitura que permanecem inalterados durante failovers geográficos. Não é necessário alterar a cadeia de conexão do seu aplicativo após um failover geográfico, porque as conexões são automaticamente roteadas para a primária atual. Um failover geográfico alterna todos os bancos de dados secundários do grupo para a função principal. Após a conclusão do failover geográfico, o registo DNS é atualizado automaticamente para redirecionar os endpoints para a nova região.

Descarregar tarefas de apenas leitura

Para reduzir o tráfego para os seus bancos de dados primários, pode também usar os bancos de dados secundários em um grupo de failover para aliviar cargas de trabalho de leitura. Utilize o listener de leitura apenas para direcionar o tráfego de leitura apenas para uma base de dados secundária legível.

Recuperando um aplicativo

Para alcançar a continuidade total dos negócios, adicionar redundância de banco de dados regional é apenas parte da solução. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica requer a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. Exemplos desses componentes incluem o software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (Recovery Time Objetive, objetivo de tempo de recuperação) do seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e capacidades que eles fornecem. Deve-se tomar as medidas adequadas para garantir que o serviço funcione durante o failover dos serviços dos quais depende.

Política de alternância em caso de falha

Os grupos de failover suportam duas políticas de failover:

• Gerido pelo cliente (recomendado) - Os clientes podem executar um failover de um grupo quando perceberem uma interrupção inesperada a afetar 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 gerido 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 sob gestão da Microsoft não será iniciado em grupos individuais de failover ou num subconjunto de grupos de failover numa 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, como resume a tabela a seguir:

Gerenciado pelo cliente

Em raras ocasiões, a disponibilidade interna ou alta disponibilidade não é suficiente para atenuar uma interrupção e seus bancos de dados em um grupo de failover podem estar 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 datacenter, na zona de disponibilidade ou no nível 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 como gerenciada pelo cliente é altamente recomendável, 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:

• A interrupção no 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 e a mitigação da interrupção dependem de 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 para ser gerida pela Microsoft apenas quando:

• Você deseja delegar a responsabilidade de recuperação de desastres ao serviço SQL do Azure.
• O aplicativo é tolerante a que seu banco de dados fique indisponível por pelo menos uma hora ou mais.
• É aceitável acionar failovers forçados algum tempo após o período de carência expirar, 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 da configuração de redundância de zona ou do 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 gerenciada pela Microsoft.
• É aceitável realizar failovers forçados de bases de dados no grupo de failover sem ter em conta a dependência da aplicação de outros serviços ou componentes do Azure utilizados pela aplicação, o que pode causar uma degradação do desempenho ou indisponibilidade da aplicação.
• É 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.
• As réplicas primária e secundária no grupo de failover têm a mesma camada de serviço, camada de computação e tamanho de computação.

Quando um failover é acionado pela Microsoft, uma entrada para o nome da operação Failover do grupo de failover do Azure SQL é adicionada ao log de atividades do Azure Monitor. A entrada inclui o nome do grupo de failover sob 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 capacidades

• Grupo de tolerância a falhas (FOG)

  Um grupo de failover permite que todos os bancos de dados de usuário em uma instância gerenciada pelo SQL façam failover como uma unidade para outra região do Azure caso a instância gerenciada SQL primária fique indisponível devido a uma interrupção da região primária. Como os grupos de failover para Instância Gerenciada SQL contêm todos os bancos de dados de usuário dentro da instância, apenas um grupo de failover pode ser configurado em uma instância.

  Importante

  O nome do grupo de failover deve ser globalmente único dentro do domínio .database.windows.net.

• Primária

  A instância SQL gerida que aloja os bancos de dados primários no grupo de failover.

• Secundário

  A instância gerenciada SQL 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 que o principal.

  Importante

  Se um banco de dados contiver objetos OLTP na memória, a instância de réplica geográfica primária e secundária deverá ter camadas de serviço correspondentes, pois os objetos OLTP na memória residem na memória. Uma camada de serviço mais baixa na instância de réplica geográfica pode resultar em problemas de falta de memória. Se isso ocorrer, a réplica secundária pode não conseguir recuperar o banco de dados, causando a indisponibilidade do banco de dados secundário juntamente com os objetos OLTP na memória no geo-secundário. Isso, por sua vez, pode fazer com que o failover também não seja bem-sucedido. Para evitar isso, verifique se a camada de serviço da instância geosecundária corresponde à do banco de dados primário. As atualizações da camada de serviço podem ser operações que exigem o processamento de grandes volumes de dados e podem demorar algum tempo a finalizar.

• Failover (sem perda de dados)

  O failover executa a sincronização completa de dados entre bancos de dados primários e secundários antes que o secundário alterne para a função principal. Isso garante que não haja perda de dados. O failover só é possível quando o primário está acessível. O mecanismo de failover é usado nos seguintes cenários:

  • Execute exercícios de recuperação de desastres (DR) na produção quando a perda de dados não for aceitável
  • Realocar a carga de trabalho para uma região diferente
  • Retornar a carga de trabalho para a região primária após a interrupção ter sido resolvida.

• Failover forçado (perda potencial de dados)

  O failover forçado transfere imediatamente o secundário para a função primária sem esperar que as alterações recentes se propaguem a partir da primária. Esta operação pode resultar em perda potencial de dados. O failover forçado é usado como um método de recuperação durante falhas quando o servidor principal não está acessível. Quando a interrupção for atenuada, o primário antigo se reconectará automaticamente e se tornará um novo secundário. Um failover pode ser executado para 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 gerenciadas 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 SQL do Azure aguarda antes de iniciar um failover forçado, o que pode resultar em perda de dados.

• zona DNS

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

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

  Um registro DNS CNAME que aponta para o primário atual. É criado automaticamente quando o grupo de failover é criado e permite que as cargas de trabalho de leitura e escrita voltem a ligar-se de forma transparente ao servidor principal quando este for alterado após o failover. Quando o grupo de failover é criado numa instância SQL gerenciada, o registo CNAME DNS para a URL do escutador é estabelecido como <fog-name>.<zone_id>.database.windows.net.

• Ouvinte de leitura só do grupo de reserva

  Um registro DNS CNAME que aponta para o secundário atual. Criado automaticamente quando o grupo de failover é criado, permite que a carga de trabalho SQL só de leitura se conecte de forma transparente ao secundário quando este é alterado após o failover. Quando o grupo de failover é criado numa instância SQL gerenciada, o registo CNAME DNS para a URL do escutador é estabelecido como <fog-name>.secondary.<zone_id>.database.windows.net. Por padrão, a comutação automática do ouvinte em modo apenas leitura é desativada para garantir que o desempenho do primário não seja afetado quando o secundário está offline. No entanto, isso também significa que as sessões somente leitura não poderão se conectar até que o secundário seja recuperado. Se não conseguires tolerar o tempo de inatividade das sessões somente leitura e puderes usar a instância primária para tráfego somente leitura e leitura-escrita à custa de uma potencial degradação do desempenho da primária, podes ativar a comutação por erro para o listener somente leitura ao configurar a propriedade AllowReadOnlyFailoverToPrimary. Nesse caso, o tráfego só de 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 gerenciada pela Microsoft estiver habilitada e um failover forçado tiver sido acionado. Nesse caso, se a propriedade estiver definida como True, o novo servidor primário servirá sessões de leitura-gravação e somente leitura.

Arquitetura de grupo de failover

O grupo de failover deve ser configurado na instância primária e conecta-o à instância secundária em uma região diferente do Azure. Todos os bancos de dados de usuários na instância primária são replicados para a instância secundária. As bases de dados do sistema, como master e msdb, não são replicadas.

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 SQL e um grupo de failover:

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

Criar a instância geosecundária

Para garantir conectividade ininterrupta com a Instância Gerenciada SQL primária após o failover, as instâncias primária e secundária devem estar na mesma zona DNS. Ele garante que o mesmo certificado de vários domínios (SAN) possa ser usado para autenticar conexões de cliente para qualquer uma das duas instâncias no grupo de failover. Quando seu aplicativo estiver pronto para implantação de produção, crie uma Instância Gerenciada SQL secundária em uma região diferente e verifique se ela compartilha a zona DNS com a Instância Gerenciada SQL primária. Você pode fazer isso especificando um parâmetro opcional ao criar a instância. 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 é Instância Gerenciada Primária.

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

Usar regiões emparelhadas

Implante ambas as instâncias gerenciadas SQL em regiões emparelhadas por motivos de desempenho. Os grupos de failover da Instância Gerenciada SQL em regiões emparelhadas apresentam um desempenho superior em relação às não emparelhadas.

A Instância Gerenciada SQL do Azure segue uma prática de implantação segura na qual 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 Gerida do Azure SQL faz parte de um grupo de failover, e as instâncias no grupo não estão em regiões emparelhadas do Azure, escolha horários de manutenção diferentes para as suas bases de dados primária e secundária. Por exemplo, selecione uma janela de manutenção dias úteis para o seu banco de dados geosecundário e uma janela de manutenção de fim de semana para o seu banco de dados geoprimário.

Habilite e otimize 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 um fluxo de tráfego de replicação geográfica ininterrupto. 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:

• Interconexão de rede virtual global
• Gateways VPN
• Azure ExpressRoute

O emparelhamento de rede virtual global (emparelhamento de VNet) é a maneira recomendada de estabelecer conectividade entre duas instâncias num 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 é necessária Internet pública, gateways ou encriptação adicional na comunicação entre as redes virtuais em modo de peering.

Semeadura inicial

Ao estabelecer um grupo de failover entre instâncias gerenciadas pelo SQL, há uma fase inicial de propagação antes do início da replicação de dados. A fase inicial de semeadura é a parte mais longa e cara da operação. Quando a propagação inicial é concluída, os dados são sincronizados e apenas as alterações de dados subsequentes são replicadas. O tempo necessário para a conclusão da propagação inicial 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 link entre as redes virtuais que hospedam a instância primária e secundária, o que depende 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 transferência pode chegar a 360 GB por hora para a Instância Gerida do SQL. A semeadura é realizada para um lote de bancos de dados de usuários em paralelo, mas não necessariamente para todos os bancos de dados ao mesmo tempo. Vários lotes podem ser necessários se houver muitos bancos de dados hospedados na instância.

Se a velocidade da ligação entre as duas instâncias for mais lenta do que o necessário, é provável que o tempo de inicialização seja perceptivelmente 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 inicial de propagação leva antes do início da replicação de dados. Por exemplo, para um único banco de dados de 100 GB, a fase inicial de propagação levaria cerca de 1,2 horas se o link for capaz de enviar 84 GB por hora e se não houver outros bancos de dados sendo semeados. 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 replicar, a propagação será executada em paralelo. Quando combinada com uma velocidade de link lenta, a fase inicial de semeadura pode levar consideravelmente 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.

Gerenciar failover geográfico para uma instância geosecundária

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

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 servidor principal. 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 roteadas para o novo primário somente depois que o cache DNS do cliente for atualizado. Como a instância secundária compartilha a zona DNS com a principal, o aplicativo cliente poderá se reconectar a ela usando o mesmo certificado SAN do lado do servidor. As conexões de cliente existentes precisam ser encerradas e, em seguida, recriadas para serem roteadas para a nova primária. O ouvinte de leitura-gravação e o ouvinte somente leitura não podem ser acessados por meio do ponto de extremidade público para instância gerenciada do SQL.

Usar o ouvinte de apenas leitura (MI secundário)

Se tiver cargas de trabalho somente de leitura, logicamente isoladas e tolerantes à latência de dados, pode executá-las no geo-secundário. Para conectar-se diretamente ao geosecundário, use <fog-name>.secondary.<zone_id>.database.windows.net como o nome do servidor.

Na camada Business Critical, a Instância Gerenciada SQL oferece 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. Depois de configurar um secundário replicado geograficamente, você pode usar esse recurso para se conectar a uma réplica somente leitura no local primário ou no local replicado geograficamente:

• Para se conectar a uma réplica somente leitura no local principal, use ApplicationIntent=ReadOnly e <fog-name>.<zone_id>.database.windows.net.
• Para se conectar a uma réplica de leitura única na localização secundária, 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 acessados por meio do ponto de extremidade público para instância gerenciada do SQL.

Potencial degradação do desempenho após 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 é acionado com base apenas no estado dos componentes SQL do Azure. Uma interrupção pode não afetar outros serviços do Azure na região principal e seus componentes ainda podem estar disponíveis nessa região. Quando os bancos de dados primários alternam para a região secundária, a latência entre os componentes dependentes pode aumentar. Garanta a redundância de todos os componentes do aplicativo na região secundária e faça failover dos componentes do aplicativo junto com o banco de dados para que a latência mais alta entre regiões não afete o desempenho de um aplicativo.

Perda potencial de dados após failover forçado

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

Atualização de DNS

A atualização do DNS do escutador de leitura e escrita acontecerá imediatamente após o processo de failover ser iniciado. Esta operação não resultará em perda de dados. No entanto, o processo de alternar funções de banco de dados pode levar até cinco minutos em condições normais. Até que esteja concluído, algumas bases de dados na nova instância primária ainda serão de leitura apenas. 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 for iniciada usando o portal do Azure, a interface do usuário indica o status de conclusão. Se for iniciado usando a API REST, use o mecanismo de sondagem padrão do Azure Resource Manager para monitorar a conclusão.

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

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

Desde que a instância secundária não seja usada para tarefas de leitura, a Microsoft fornece uma quantidade de vCores sem custo para corresponder à instância primária. Você ainda é cobrado pela computação e armazenamento usados pela instância secundária. Os grupos de failover oferecem suporte a apenas uma réplica, e a réplica deve ser legível ou designada como uma réplica somente DR.

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

As bases de dados do sistema não são replicadas para a instância secundária num grupo de tolerância a falhas. Para habilitar cenários que dependem de objetos dos bancos de dados do sistema, certifique-se de criar os mesmos objetos na instância secundária. Mantenha-os sincronizados com a instância principal.

Por exemplo, se você planeja usar os mesmos logins na instância secundária, certifique-se de criá-los com o idêntico SID.

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

Para saber mais, consulte Replicação de logins e tarefas de agente.

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

As instâncias em um grupo de failover permanecem separadas dos recursos do Azure e nenhuma alteração feita na configuração da instância primária é replicada automaticamente para a instância secundária. Certifique-se de executar todas as alterações relevantes na instância primária e 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 principal, certifique-se de alterá-la também na instância secundária.

Dimensionar instâncias

A configuração da instância primária e secundária deve ser a mesma. Isso inclui o tamanho da computação, o tamanho do armazenamento e a camada de serviço. Se você precisar alterar a configuração do seu grupo de failover, poderá fazê-lo dimensionando cada instância para a mesma configuração de acordo. Para saber mais, consulte Dimensionamento de instâncias em um grupo de failover.

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. A replicação assíncrona torna inevitável a possibilidade de perda de dados se o primário falhar. Para saber como pode proteger os seus dados, consulte Prevenir a perda de dados.

Status do grupo de failover

O grupo de failover relata seu status descrevendo o estado atual da replicação de dados:

• Propagação: A propagação inicial ocorre após a criação do grupo de failover, até que todos os bancos de dados de usuários sejam inicializados na instância secundária. O failover não pode ser iniciado enquanto o grupo de failover estiver no estado de 'seeding', pois os bancos de dados dos utilizadores ainda não foram copiados para a instância secundária.
• Sincronização: o status usual 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 todo momento. Podem ocorrer alterações nos dados do primário, ainda não replicadas para o secundário, devido à natureza assíncrona do processo de replicação entre instâncias num grupo de transferência de falha. Os failovers automáticos e manuais podem ser iniciados enquanto o grupo de failover está no estado de sincronização .
• Failover em andamento: esse status indica que o failover iniciado automática ou manualmente está em andamento. Não é possível fazer alterações no grupo de failover nem iniciar failovers adicionais enquanto o grupo de failover se encontra neste estado.

Recuperação automática

Quando os grupos de failover são configurados com uma política de failover gerenciada pela Microsoft, o failover forçado para o servidor geosecundário é iniciado durante um cenário de desastre de acordo com o período de cortesia definido. O regresso ao primário antigo deve ser iniciado manualmente.

Interoperabilidade de funcionalidades

Cópias de Segurança

Um backup completo é feito nos seguintes cenários:

• Antes do início da propagação inicial, quando você cria um grupo de failover.
• Após um failover (alternância de serviço).

Um backup completo é um tipo de operação de dados que não pode ser ignorado ou adiado e pode levar algum tempo para ser concluído. O tempo necessário para concluir depende do tamanho dos dados, do número de bancos de dados e da intensidade da carga de trabalho nos bancos de dados primários. Um backup completo pode atrasar visivelmente a inicialização inicial e pode atrasar ou impedir uma operação de failover em uma nova instância logo após esse failover.

Considere o seguinte:

• Não é feito backup dos bancos de dados hospedados na instância secundária de um grupo de failover até que essa instância se torne primária após um failover ou até que o grupo de failover seja descartado.
• Depois que um banco de dados muda para a função principal após um failover, ou se torna autônomo depois que um grupo de failover é descartado, um backup completo do banco de dados é iniciado automaticamente para facilitar restaurações point-in-time.
• Um banco de dados não pode ser restaurado de uma instância para um ponto no tempo em que essa instância era uma réplica secundária em um grupo de failover. Para restaurar para um ponto no tempo, deve-se restaurar a base de dados da instância que era primária durante esse ponto no tempo.
• Para recriar um grupo de failover descartado no mesmo par de instâncias gerenciadas pelo SQL, todos os bancos de dados de usuários precisam ser removidos do secundário pretendido depois que o grupo de failover é descartado. Uma base de dados só é completamente removida após a conclusão de todas as operações de backup pendentes, incluindo um backup completo caso não tenha sido realizado (o que constitui uma operação de tamanho de dados). Dê tempo para limpar a instância secundária depois de descartar um grupo de failover com bancos de dados muito grandes, pois cada banco de dados pode ter uma operação de backup completo pendente em andamento.

Um backup completo é um processo de operação de dados que não pode ser ignorado ou adiado e pode demorar algum tempo a ser concluído. O tempo necessário para concluir depende do tamanho dos dados, do número de bancos de dados e da intensidade da carga de trabalho nos bancos de dados primários. Um backup completo pode atrasar visivelmente o seeding inicial e pode atrasar ou impedir uma operação de failover em uma nova instância, pouco depois de um failover.

Serviço de Log Replay

Os bancos de dados migrados para a Instância Gerida SQL do Azure usando o Log Replay Service (LRS) não podem ser adicionados a um grupo de failover até que a etapa de transferência seja executada. Um banco de dados migrado com o LRS está em um estado de restauração até a transferência, e os bancos de dados em um estado de restauração não podem ser adicionados a um grupo de failover. A tentativa de criar um grupo de failover com um banco de dados em um estado de restauração atrasa a criação do grupo de failover até que a restauração do banco de dados seja concluída.

Replicação transacional

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

Se uma instância de SQL gerida do editor ou distribuidor estiver em um grupo de failover, o administrador da instância SQL gerida deve remover todas as publicações no primário antigo e reconfigurá-las no novo primário após ocorrer um failover. Analise o guia de replicação transacional para a sequência de atividades necessárias neste cenário.

Permissões e limitações

Analise uma lista de permissões e limitações antes de configurar um grupo de failover.

Gerencie grupos de failover programaticamente

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

Exercícios de recuperação de desastres

A maneira recomendada de executar uma simulação de DR é usando o failover manual planejado, de acordo com o seguinte tutorial: Teste de failover.

A execução de um teste usando failover forçado não é recomendada, pois essa operação não fornece medidas de 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 SQL primária.
• Todas as transações de longa duração foram concluídas.
• Todas as conexões de cliente com a instância gerenciada SQL primária foram desconectadas.
• O estado do grupo de failover é 'Sincronização'.

Certifique-se de que as duas instâncias gerenciadas pelo SQL tenham alternado de função. Além disso, o status do grupo de failover mudou de 'Failover em andamento' para 'Sincronizando' antes de, opcionalmente, estabelecer conexões com a nova instância gerenciada SQL primária e iniciar o workload de leitura/gravação.

Para executar um failback sem perda de dados para as funções das instâncias geridas SQL originais, é altamente recomendável usar um failover planejado manualmente em vez de um failover forçado. Se for utilizado o failback forçado:

• Siga as mesmas etapas para o failover sem perda de dados.
• Espera-se um tempo de execução de failback mais longo se o failback forçado for executado, logo após a conclusão do failover forçado inicial, pois terá que aguardar a conclusão das operações automáticas de backup pendentes na antiga instância de SQL gerida como primária.
• Qualquer operação de backup automático pendente em uma instância em transição da função principal para a secundária pode afetar a disponibilidade do banco de dados nessa instância.
• Use o status do grupo de failover para determinar se ambas as instâncias alteraram com êxito suas funções e estão prontas para aceitar conexões de cliente.

Conteúdo relacionado

• Configurar um grupo de failover para a Instância Gerenciada SQL do Azure
• Usar o PowerShell para adicionar uma instância gerenciada do SQL a um grupo de failover
• Configurar uma réplica em espera sem licença para o Azure SQL Managed Instance
• Visão geral da continuidade de negócios com a Instância Gerenciada SQL do Azure
• Backups automatizados na Instância Gerenciada SQL do Azure
• Restaurar um banco de dados a partir de um backup no da Instância Gerenciada SQL do Azure