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

APPLIES TO: Instância Gerenciada de SQL do Azure

O recurso de grupos de failover automático 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 se concentra no uso do recurso de grupo de failover automático com a Instância Gerenciada de SQL do Azure e algumas melhores práticas.

Para começar, examine Configurar o grupo de failover automático. Para uma experiência de ponta a ponta, consulte o Tutorial de grupo de failover automático.

Observação

Este artigo aborda os grupos de failover automático para a Instância Gerenciada de SQL do Azure. Para Banco de Dados SQL do Azure, consulte Grupos de failover automático no Banco de Dados SQL.

Visão geral

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 de usuário em uma instância gerenciada para outra região do Azure. Ele é uma abstração declarativa junto ao recurso de replicação geográfica ativa, projetado para simplificar a implantação e o gerenciamento de bancos de dados replicados geograficamente em escala.

Automatic failover

Você pode iniciar um failover geográfico 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. Normalmente, essas são paralisações que não podem ser atenuadas automaticamente pela infraestrutura de alta disponibilidade interna. OS exemplos de gatilhos de failover geográfico incluem desastres naturais ou incidentes causados por um anel de controle ou locatário que está sendo desativado devido a um vazamento de memória do kernel do sistema operacional em nós de computação. Para saber mais, consulte Alta disponibilidade do SQL do Azure.

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.

Redirecionamento de ponto de extremidade

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 geográficos. Isso significa que 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. Seja usando a ativação de failover manual ou automática, 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. Para os RPO e RTO do failover geográfico, confira Visão geral da continuidade de negócios.

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.

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.

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

  • 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 geográfico 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, por exemplo, devido à escala do impacto. Se você quiser controlar o fluxo de trabalho de failover geográfico pelo aplicativo ou manualmente, poderá desativar a política de 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 geográfico 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 um failover geográfico 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 dados são replicados para o banco de dados secundário usando replicação assíncrona, um failover geográfico 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.

Arquitetura do grupo de failover

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:

Auto-failover group diagram for SQL MI

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.

Importante

Se você implantar grupos de failover automático em uma topologia de rede de hub e spoke entre regiões, o tráfego de replicação deverá passar diretamente entre as duas sub-redes da instância gerenciada, em vez de ser direcionado pelas redes de hub.

Propagação inicial

Ao adicionar as 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é 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, 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 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.

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

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.

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

Já que cada instância gerenciada é 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

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

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

Potencial perda de dados após o failover

Se ocorrer uma paralisação na região primária, as transações recentes poderão não ser capazes de replicar para a área geográfica secundária. O failover será adiado para o período especificado usando GracePeriodWithDataLossHours. Esteja preparado para perda de dados, se configurou a política de failover automático. Em geral, durante interrupções, o Azure favorece a disponibilidade. Definir GracePeriodWithDataLossHours como um número maior, como 24 horas ou desabilitar o failover geográfico automático permite reduzir a probabilidade de perda de dados em detrimento da disponibilidade do banco de dados.

Atualização de DNS

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

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.

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.

Usar grupos de failover e pontos de extremidade de serviço de rede virtual

Se você está usando Pontos de extremidade e regras de serviço de Rede Virtual para restringir o acesso à sua 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.

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.

Observação

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 automático 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 automático 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 automático. 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 automático. Os failovers automáticos e manuais podem ser iniciados enquanto o grupo de failover automático está no status de Propagaçã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 automático estiver nesse status.

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.

O acesso de gravação do RBAC do Azure é necessário para criar e gerenciar grupos de failover. O Colaborador da Instância Gerenciada de SQL tem todas as permissões necessárias para gerenciar grupos de failover.

Para escopos de permissão específicos, consulte como configurar grupos de failover automático em Instância Gerenciada de SQL do Azure.

Limitações

Esteja ciente das seguintes limitações:

  • Os grupos de failover não podem ser criados entre 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 banco de dados no grupo de failover. Você precisará excluir temporariamente o grupo de failover para poder renomear um banco de dados.
  • Os bancos de dados do 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, como logons do servidor e cargos do agente 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. Para saber mais, veja como Habilitar cenários dependentes de objetos dos bancos de dados do sistema.
  • Os grupos de failover não poderão ser criados entre instâncias se qualquer uma delas estiver em um pool de instâncias.

Gerenciar programaticamente grupos de failover

Os grupos de failover automático também podem ser gerenciados programaticamente usando o Azure PowerShell, a CLI do Azure 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.

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