Os grupos de falhas automáticas compreendem as & melhores práticas (SQL do Azure Database)

Aplica-se a: Base de Dados SQL do Azure

A funcionalidade de grupos de falha automática permite-lhe gerir a replicação e falha de algumas ou todas as bases de dados de um servidor lógico para outra região. Este artigo centra-se na utilização da funcionalidade do grupo Auto-failover com SQL do Azure Database e algumas boas práticas.

Para começar, reveja o grupo de falha automática Configure. Para uma experiência de ponta a ponta, consulte o tutorial do grupo Auto-failover.

Nota

  • Este artigo abrange grupos de falha automática para SQL do Azure Base de Dados. Para Azure SQL Managed Instance, consulte os grupos auto-failover em Azure SQL Managed Instance.
  • Os grupos de falha automática suportam a geo-replicação de todas as bases de dados do grupo para apenas um servidor secundário numa região diferente. Se precisar de criar réplicas geo-secundárias de SQL do Azure múltiplas (nas mesmas regiões ou diferentes) para a mesma réplica primária, utilize a geo-replicação ativa.

Descrição Geral

A funcionalidade grupos de falha automática permite-lhe gerir a replicação e falha de um grupo de bases de dados num servidor ou em todas as bases de dados de utilizadores, numa instância gerida para outra região do Azure. É uma abstração declarativa em cima da funcionalidade de geo-replicação ativa , projetada para simplificar a implementação e gestão de bases de dados geo-replicadas em escala.

Ativação pós-falha automática

Pode iniciar uma falha de geodestrução manual ou pode deleitá-la ao serviço Azure com base numa política definida pelo utilizador. Esta última opção permite-lhe recuperar automaticamente várias bases de dados relacionadas numa região secundária após uma falha catastrófica ou outro evento não planeado que resulte em perda total ou parcial da Base de Dados SQL ou SQL Managed Instance disponibilidade na região primária. Tipicamente, trata-se de falhas que não podem ser atenuadas automaticamente pela infraestrutura de alta disponibilidade incorporada. Exemplos de gatilhos de geo-falha incluem desastres naturais, ou incidentes causados por um inquilino ou anel de controlo sendo abatido devido a uma fuga de memória de kernel em nós computacional. Para mais informações, consulte SQL do Azure alta disponibilidade.

Descarrega cargas de trabalho apenas de leitura

Para reduzir o tráfego para as suas bases de dados primárias, também pode utilizar as bases de dados secundárias num grupo de falha para descarregar cargas de trabalho apenas de leitura. Utilize o ouvinte apenas para ler o tráfego apenas de leitura para uma base de dados secundária legível.

Reorientação do ponto final

Os grupos de ativação pós-falha automática proporcionam pontos finais de serviço de escuta só de leitura e de leitura-escrita que permanecem inalterados durante as ativações pós-falha geográficas. Isto significa que não tem de alterar o fio de ligação para a sua aplicação após uma falha geo-failover, porque as ligações são automaticamente encaminhadas para a corrente primária. Quer utilize ativação manual ou automática de falha, uma falha geo-falha muda todas as bases de dados secundárias do grupo para a função principal. Após a conclusão do geo-failover, o registo dns é automaticamente atualizado para redirecionar os pontos finais para a nova região. Para o RPO geo-failover e RTO, consulte a Visão Geral da Continuidade do Negócio.

Recuperação de um pedido

Para alcançar a plena continuidade do negócio, adicionar o despedimento regional da base de dados é apenas uma parte da solução. A recuperação de uma aplicação (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 destes componentes incluem o software do cliente (por exemplo, um navegador com um JavaScript personalizado), extremidades frontais web, armazenamento e DNS. É fundamental que todos os componentes sejam resistentes às mesmas falhas e estejam disponíveis dentro do objetivo de tempo de recuperação (RTO) da sua aplicação. Por isso, é necessário identificar todos os serviços dependentes e compreender as garantias e capacidades que eles fornecem. Em seguida, deve tomar as medidas adequadas para garantir que o seu serviço funciona durante a caduência dos serviços de que depende.

Terminologia e capacidades

  • Grupo failover (FOG)

    Um grupo de failover é um grupo de bases de dados nomeado gerido por um único servidor que pode falhar como uma unidade para outra região de Azure no caso de todas ou algumas bases de dados primárias ficarem indisponíveis devido a uma falha na região primária.

    Importante

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

  • Servidores

    Algumas ou todas as bases de dados dos utilizadores num servidor lógico podem ser colocadas num grupo de failover. Além disso, um servidor suporta vários grupos de falha num único servidor.

  • Principal

    O servidor que acolhe as bases de dados primárias do grupo de failover.

  • Secundária

    O servidor que acolhe as bases de dados secundárias no grupo de failover. O secundário não pode estar na mesma região de Azure que as primárias.

  • Adicionar bases de dados únicas ao grupo failover

    Pode colocar várias bases de dados individuais no mesmo servidor no mesmo grupo de falhas. Se adicionar uma única base de dados ao grupo de failover, cria automaticamente uma base de dados secundária utilizando a mesma edição e tamanho de cálculo no servidor secundário. Especificou o servidor quando o grupo de failover foi criado. Se adicionar uma base de dados que já tenha uma base de dados secundária no servidor secundário, essa ligação de geo-replicação é herdada pelo grupo. Quando adiciona uma base de dados que já tem uma base de dados secundária num servidor que não faz parte do grupo de failover, um novo secundário é criado no servidor secundário.

    Importante

    Certifique-se de que o servidor secundário não tem uma base de dados com o mesmo nome, a menos que seja uma base de dados secundária existente.

  • Adicionar bases de dados em piscina elástica para grupo failover

    Pode colocar todas ou várias bases de dados dentro de uma piscina elástica no mesmo grupo de failover. Se a base de dados primária estiver numa piscina elástica, a secundária é automaticamente criada na piscina elástica com o mesmo nome (piscina secundária). Deve certificar-se de que o servidor secundário contém uma piscina elástica com o mesmo nome exato e capacidade livre suficiente para hospedar as bases de dados secundárias que serão criadas pelo grupo failover. Se adicionar uma base de dados na piscina que já tem uma base de dados secundária na piscina secundária, essa ligação de geo-replicação é herdada pelo grupo. Quando adiciona uma base de dados que já tem uma base de dados secundária num servidor que não faz parte do grupo de failover, um novo secundário é criado no pool secundário.

  • Ouvinte de leitura de grupo failover

    Um registo DONS CNAME que aponta para as primárias atuais. É criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho de leitura-escrita se reconecte transparentemente à primária quando o primário muda após o failover. Quando o grupo de failover é criado num servidor, o registo DNS CNAME para o URL do ouvinte é formado como <fog-name>.database.windows.net.

  • Ouvinte de leitura de grupo de failover

    Um registo do DNS CNAME que aponta para o secundário atual. É criado automaticamente quando o grupo de failover é criado e permite que a carga de trabalho SQL apenas de leitura se conecte transparentemente ao secundário quando o secundário muda após o failover. Quando o grupo de failover é criado num servidor, o registo DNS CNAME para o URL do ouvinte é formado como <fog-name>.secondary.database.windows.net.

  • Vários grupos de failover

    Pode configurar vários grupos de failover para o mesmo par de servidores para controlar o alcance das falhas de geo-falhas. Cada grupo falha de forma independente. Se a sua aplicação de inquilino por base de dados for implementada em várias regiões e utilizar piscinas elásticas, pode utilizar esta capacidade para misturar bases de dados primárias e secundárias em cada piscina. Desta forma poderá reduzir o impacto de uma paralisação para apenas algumas bases de dados de inquilinos.

  • Política automática de failover

    Por predefinição, um grupo de incumprimento é configurado com uma política automática de incumprimento. O sistema desencadeia uma falha geo-failover após a falha ser detetada e o período de carência expirou. O sistema deve verificar se a paralisação não pode ser atenuada pela infraestrutura de alta disponibilidade incorporada, por exemplo, devido à dimensão do impacto. Se pretender controlar o fluxo de trabalho de geo-falha da aplicação ou manualmente, pode desligar a política de falha automática.

    Nota

    Uma vez que a verificação da escala da paralisação e a rapidez com que pode ser atenuada envolve ações humanas, o período de carência não pode ser definido abaixo de uma hora. Esta limitação aplica-se a todas as bases de dados do grupo de failover, independentemente do seu estado de sincronização de dados.

  • Política de failover só de leitura

    Por predefinição, a falha do ouvinte apenas de leitura é desativada. Garante que o desempenho do primário não é impactado quando o secundário está offline. No entanto, também significa que as sessões só de leitura não poderão ligar-se até que o secundário seja recuperado. Se não conseguir tolerar tempo de inatividade para as sessões de leitura e puder utilizar o tráfego primário apenas de leitura e leitura em detrimento da potencial degradação do desempenho da primária, pode permitir a falha para o ouvinte apenas de leitura configurando a AllowReadOnlyFailoverToPrimary propriedade. Nesse caso, o tráfego só de leitura será automaticamente redirecionado para o primário se o secundário não estiver disponível.

    Nota

    A AllowReadOnlyFailoverToPrimary propriedade só tem efeito se a política automática de failover estiver ativada e se tiver sido acionada uma geo-falha automática. Nesse caso, se a propriedade estiver definida para True, a nova primária servirá sessões de leitura e leitura.

  • Ativação pós-falha planeada

    O failover planeado realiza uma sincronização completa de dados entre bases de dados primárias e secundárias antes que o secundário mude para o papel principal. Isto garante que não há perda de dados. O failover planeado é utilizado nos seguintes cenários:

    • Realizar exercícios de recuperação de desastres (DR) na produção quando a perda de dados não for aceitável
    • Realocar as bases de dados para uma região diferente
    • Devolva as bases de dados à região primária depois de a paralisação ter sido atenuada (falha)

    Nota

    Se uma base de dados contiver objetos OLTP na memória, as bases de dados primárias e as bases de dados de geo-réplicas secundárias do alvo devem ter níveis de serviço correspondentes, uma vez que os objetos OLTP na memória estão sempre hidratados na memória. Um nível de serviço mais baixo na base de dados de geo-réplicas-alvo pode resultar em problemas fora de memória. Se isso acontecer, a réplica da base de dados geocondusídua associada pode ser colocada num modo de leitura limitado chamado apenas o modo de ponto de verificação OLTP na memória . Consultas de tabela apenas de leitura são permitidas, mas as consultas de tabela OLTP apenas de leitura são proibidas na réplica da base de dados geoconsusícola afetada. A falha planeada está bloqueada se todas as réplicas na base de dados geoconsusídua estiverem apenas no modo de verificação. A falha não planeada pode falhar devido a problemas fora de memória. Para evitar isto, atualize o nível de serviço da base de dados secundária para corresponder à base de dados primária durante a falha planeada, ou perfurar. As atualizações de nível de serviço podem ser operações de tamanho de dados, e podem demorar algum tempo a terminar.

  • Ativação pós-falha não planeada

    O fracasso não planeado ou forçado muda imediatamente o secundário para o papel primário sem esperar que as recentes alterações se propaguem a partir das primárias. Esta operação pode resultar em perda de dados. A falência não planeada é utilizada como método de recuperação durante as interrupções quando a primária não está acessível. Quando a paralisação for atenuada, a antiga primária reconecta-se automaticamente e torna-se secundária. Um failover planeado pode ser executado para falhar, devolvendo as réplicas aos seus papéis primários e secundários originais.

  • Falha manual

    Pode iniciar uma geo-falha manualmente a qualquer momento, independentemente da configuração automática de falha. Durante uma paragem que impacta a política primária, se a política de failover automática não estiver configurada, é necessário um failover manual para promover o secundário para o papel primário. Pode iniciar uma falha forçada (não planeada) ou amigável (planeada). Um failover amigável só é possível quando a antiga primária é acessível, e pode ser usada para deslocalizar o primário para a região secundária sem perda de dados. Quando uma falha é concluída, os registos DNS são automaticamente atualizados para garantir a conectividade com o novo primário.

  • Período de graça com perda de dados

    Como os dados são replicados na base de dados secundária utilizando a replicação assíncronea, uma falha automática do geo-failover pode resultar na perda de dados. Pode personalizar a política de failover automática para refletir a tolerância da sua aplicação à perda de dados. Ao configurar GracePeriodWithDataLossHours, pode controlar quanto tempo o sistema aguarda antes de iniciar uma falha forçada, o que pode resultar na perda de dados.

Arquitetura de grupo failover

Um grupo de failover na base de dados SQL do Azure pode incluir uma ou várias bases de dados, normalmente utilizadas pela mesma aplicação. Quando estiver a utilizar grupos de falha automática com uma política automática de failover, uma paragem que impacte uma ou várias bases de dados do grupo resultará numa falha automática de geo-falha.

O grupo de falha automática deve ser configurado no servidor primário e conectá-lo ao servidor secundário numa região de Azure diferente. Os grupos podem incluir todas ou algumas bases de dados nestes servidores. O diagrama seguinte ilustra uma configuração típica de uma aplicação na cloud georredundante ao utilizar várias bases de dados e o grupo de ativação pós-falha automática.

O diagrama mostra uma configuração típica de uma aplicação de nuvem geo-redundante utilizando várias bases de dados e grupo de falha automática.

Ao conceber um serviço com continuidade empresarial em mente, siga as orientações gerais e as melhores práticas descritas neste artigo. Ao configurar um grupo de failover, certifique-se de que a autenticação e o acesso à rede no secundário estão configurados para funcionar corretamente após a geo-falhação, quando o geo-secundário se torna o novo primário. Para mais detalhes, consulte Base de Dados SQL segurança após a recuperação de desastres. Para obter mais informações sobre a conceção de soluções para recuperação de desastres, consulte a conceção de soluções cloud para recuperação de desastres utilizando a geo-replicação ativa.

Para obter informações sobre a utilização de pontos no tempo, consulte Point in Time Recovery (PITR).

Sementeira inicial

Ao adicionar bases de dados ou piscinas elásticas a um grupo de failover, existe uma fase inicial de sementeira antes do início da replicação de dados. A fase inicial de sementeira é a operação mais longa e cara. Uma vez concluída a sementeira inicial, os dados são sincronizados e apenas as alterações de dados subsequentes são replicadas. O tempo que a sementeira inicial leva a ser concluída depende do tamanho dos seus dados, do número de bases de dados replicadas, da carga nas bases de dados primárias e da velocidade da ligação entre o primário e o secundário. Em circunstâncias normais, a velocidade de sementeira possível é de até 500 GB por hora para Base de Dados SQL. A sementeira é realizada para todas as bases de dados em paralelo.

Utilize vários grupos de failover para falhar em várias bases de dados

Um ou muitos grupos de failover podem ser criados entre dois servidores em diferentes regiões (servidores primários e secundários). Cada grupo pode incluir uma ou várias bases de dados que são recuperadas como uma unidade no caso de todas ou algumas bases de dados primárias ficarem indisponíveis devido a uma falha na região primária. A criação de um grupo de failover cria bases de dados geoconducionárias com o mesmo objetivo de serviço que o principal. Se adicionar uma relação de geo-replicação existente a um grupo de failover, certifique-se de que o geo-secundário está configurado com o mesmo nível de serviço e tamanho de cálculo que o principal.

Utilize o ouvinte de leitura -escrita (primário)

Para cargas de trabalho de leitura-escrita, utilize <fog-name>.database.windows.net como o nome do servidor na cadeia de ligação. As ligações serão automaticamente direcionadas para as primárias. Este nome não muda após o fracasso. Note que a falha envolve a atualização do registo DNS para que as ligações do cliente sejam redirecionadas para a nova primária apenas após a atualização da cache DNS do cliente. O tempo de vida (TTL) do gravador de DNS primário e secundário é de 30 segundos.

Utilize o ouvinte apenas de leitura (secundário)

Se tiver cargas de trabalho apenas de leitura logicamente isoladas que sejam tolerantes à latência de dados, pode executá-las no geo-secundário. Para cargas de trabalho só de leitura, utilize <fog-name>.secondary.database.windows.net como o nome do servidor na cadeia de ligação. As ligações serão automaticamente direcionadas para o geoconsusío secundário. Recomenda-se também que indique a intenção de leitura na cadeia de ligação utilizando ApplicationIntent=ReadOnly.

Nos níveis de serviço Premium, Crítico para a Empresa e Hyperscale, Base de Dados SQL suporta o uso de réplicas apenas de leitura para descarregar cargas de trabalho de consulta apenas de leitura, utilizando o ApplicationIntent=ReadOnly parâmetro na cadeia de ligação. Quando tiver configurado um geo-secundário, pode utilizar esta capacidade para ligar a uma réplica apenas de leitura na localização primária ou na localização geo-replicada:

  • Para ligar a uma réplica apenas de leitura no local secundário, utilize ApplicationIntent=ReadOnly e <fog-name>.secondary.database.windows.net.

Potencial degradação do desempenho após falha

Uma aplicação típica do Azure utiliza vários serviços Azure e consiste em múltiplos componentes. O geo-failover automático do grupo de failover é desencadeado com base no estado em que os componentes SQL do Azure. Outros serviços Azure na região primária não podem ser afetados pela paralisação e os seus componentes podem ainda estar disponíveis nessa região. Uma vez que as bases de dados primárias mudam para a região secundária (DR), a latência entre os componentes dependentes pode aumentar. Para evitar o impacto de uma maior latência no desempenho da aplicação, garantir a redundância de todos os componentes da aplicação na região DR, seguir estas orientações de segurança da rede e orquestrar o geo-failover dos componentes de aplicação relevantes juntamente com a base de dados.

Perda potencial de dados após falha

Se ocorrer uma indisponibilidade na região primária, poderá não ser possível replicar as transações recentes para a georreplicação secundária. Se a política de falha automática estiver configurada, o sistema aguarda o período por GracePeriodWithDataLossHours que especificou antes de iniciar uma falha automática de geo-falha. O valor predefinido é de 1 hora. Este processamento favorece a disponibilidade da base de dados em oposição a nenhuma perda de dados. Definir GracePeriodWithDataLossHours para um número maior, como 24 horas, ou desativar o geo-failover automático permite reduzir a probabilidade de perda de dados em detrimento da disponibilidade de base de dados.

Importante

Os conjuntos elásticos com 800 ou menos DTUs ou 8 ou menos vCores e mais de 250 bases dados podem registar problemas, incluindo ativações pós-falha geográficas planeadas mais longas e desempenho degradado. Estas questões são mais propensas a ocorrer para escrever cargas de trabalho intensivas, quando as geo-réplicas são amplamente separadas pela geografia, ou quando várias réplicas secundárias são usadas para cada base de dados. Um sintoma destes problemas é um aumento do atraso da georreplicação ao longo do tempo, o que pode levar a uma perda de dados mais extensa durante uma interrupção. Este lag pode ser monitorizado utilizando sys.dm_geo_replication_link_status. Se estes problemas ocorrerem, então a mitigação inclui o escalonamento da piscina para ter mais DTUs ou vCores, ou reduzir o número de bases de dados geo-replicadas na piscina.

Grupos de failover e segurança da rede

Para algumas aplicações, as regras de segurança exigem que o acesso à rede ao nível dos dados seja restrito a um componente ou componentes específicos, tais como um VM, serviço web, etc. Esta exigência apresenta alguns desafios para o design da continuidade do negócio e para a utilização de grupos de failover. Considere as seguintes opções ao implementar tal acesso restrito.

Utilize grupos de failover e pontos finais de serviço de rede virtual

Se estiver a utilizar Rede Virtual pontos finais de serviço e regras para restringir o acesso à sua base de dados em Base de Dados SQL, esteja ciente de que cada ponto final de serviço de rede virtual se aplica apenas a uma região de Azure. O ponto final não permite que outras regiões aceitem a comunicação a partir da sub-rede. Portanto, apenas as aplicações de clientes implementadas na mesma região podem ligar-se à base de dados primária. Uma vez que uma geo-falha resulta na Base de Dados SQL sessões de clientes serem reencaminhadas para um servidor numa região diferente (secundária), estas sessões falharão se forem originadas por um cliente fora dessa região. Por essa razão, a política de failover automática não pode ser ativada se os servidores ou instâncias participantes estiverem incluídos nas regras Rede Virtual. Para suportar o failover manual, siga estes passos:

  1. Forneça as cópias redundantes dos componentes frontais da sua aplicação (serviço web, máquinas virtuais, etc.) na região secundária.
  2. Configurar as regras de rede virtual individualmente para o servidor primário e secundário.
  3. Ativar a falha frontal utilizando uma configuração de gestor de tráfego.
  4. Inicie a geo-falha manual quando a paragem for detetada. Esta opção é otimizada para as aplicações que requerem latência consistente entre a extremidade frontal e o nível de dados e suporta a recuperação quando ambos os lados da frente, nível de dados ou ambos são impactados pela paralisação.

Nota

Se estiver a utilizar o ouvinte apenas para equilibrar uma carga de trabalho apenas de leitura, certifique-se de que esta carga de trabalho é executada num VM ou noutro recurso na região secundária para que possa ligar-se à base de dados secundária.

Utilize grupos de failover e regras de firewall

Se o seu plano de continuidade de negócios necessitar de falha usando grupos com falha automática, pode restringir o acesso à sua base de dados em Base de Dados SQL utilizando as regras públicas de firewall IP. Para apoiar o failover automático, siga estes passos:

  1. Criar um IP público.
  2. Crie um equilibrador de carga pública e atribua-lhe o IP público.
  3. Crie uma rede virtual e as máquinas virtuais para os seus componentes frontais.
  4. Crie um grupo de segurança de rede e configuure as ligações de entrada.
  5. Certifique-se de que as ligações de saída estão abertas a SQL do Azure Base de Dados de uma região utilizando uma Sql.<Region>etiqueta de serviço.
  6. Crie uma regra de firewall Base de Dados SQL para permitir o tráfego de entrada a partir do endereço IP público que cria no passo 1.

Para obter mais informações sobre como configurar o acesso de saída e o QUE IP utilizar nas regras de firewall, consulte as ligações de saída do balanceador de carga.

A configuração acima irá garantir que uma geo-falha automática não bloqueie as ligações dos componentes frontais e pressupõe que a aplicação pode tolerar a latência mais longa entre a extremidade frontal e o nível de dados.

Importante

Para garantir a continuidade do negócio durante as interrupções regionais, deve garantir redundância geográfica tanto para componentes frontais como para bases de dados.

Base de dados primária de escala

Pode escalar ou escalar a base de dados primária para um tamanho de cálculo diferente (dentro do mesmo nível de serviço) sem desligar quaisquer geo-secundários. Ao escalonar, recomendamos que escale primeiro o geo-secundário e, em seguida, escale o primário. Ao escalonar, inverta a ordem: reduza a primária primeiro e, em seguida, reduza o secundário. Quando escala uma base de dados para um nível de serviço diferente, esta recomendação é executada.

Esta sequência é recomendada especificamente para evitar o problema em que o geo-secundário de um SKU inferior fica sobrecarregado e deve ser re-semeado durante um processo de upgrade ou downgrade. Também pode evitar o problema ao tornar a instância primária só de leitura, em detrimento de afetar todas as cargas de trabalho de leitura/gravação na instância primária.

Nota

Se criou um geo-secundário como parte da configuração do grupo failover, não é aconselhável reduzir a escala geo-secundária. Isto é para garantir que o seu nível de dados tem capacidade suficiente para processar a sua carga de trabalho regular após uma falha geo-failover.

Prevenir a perda de dados críticos

Devido à elevada latência de amplas redes de área, a geo-replicação utiliza um mecanismo de replicação assíncronos. A replicação assíncronia torna inevitável a possibilidade de perda de dados se as primárias falharem. Para proteger as transações críticas da perda de dados, um desenvolvedor de aplicações pode ligar para o procedimento sp_wait_for_database_copy_sync armazenado imediatamente após a efeção da transação. A chamada sp_wait_for_database_copy_sync bloqueia o fio de chamada até que a última transação comprometida tenha sido transmitida e endurecida no registo de transações da base de dados secundária. No entanto, não espera que as transações transmitidas sejam reproduzidas (refeitos) no secundário. sp_wait_for_database_copy_sync é traçado para uma ligação de geo-replicação específica. Qualquer utilizador com os direitos de ligação à base de dados primária pode ligar para este procedimento.

Nota

sp_wait_for_database_copy_sync impede a perda de dados após geo-falha para transações específicas, mas não garante a sincronização completa para o acesso à leitura. O atraso causado por uma sp_wait_for_database_copy_sync chamada de procedimento pode ser significativo e depende do tamanho do registo de transações ainda não transmitido no início da chamada no momento da chamada.

Permissões

As permissões para um grupo de failover são geridas através do controlo de acesso baseado em funções Azure (Azure RBAC).

O Azure RBAC escreve que o acesso é necessário para criar e gerir grupos de failover. O papel de contribuinte SQL Server tem todas as permissões necessárias para gerir grupos de failover.

Para obter âmbitos de permissão específicos, reveja como configurar grupos de falha automática na SQL do Azure Database.

Limitações

Esteja atento às seguintes limitações:

  • Os grupos de failover não podem ser criados entre dois servidores na mesma região de Azure.
  • Os grupos de failover não podem ser renomeados. Terá de eliminar o grupo e reu criá-lo com um nome diferente.
  • O renomeador da base de dados não é suportado para bases de dados no grupo failover. Terá de eliminar temporariamente o grupo de failover para poder mudar o nome de uma base de dados ou remover a base de dados do grupo de failover.

Gerir programáticamente grupos de failover

Como discutido anteriormente, os grupos de auto-failover também podem ser geridos programáticamente usando Azure PowerShell, Azure CLI e REST API. As tabelas seguintes descrevem o conjunto de comandos disponíveis. A geo-replicação ativa inclui um conjunto de APIs Azure Resource Manager para gestão, incluindo a API de base de dados de SQL do Azure e Azure PowerShell cmdlets. Estas APIs requerem a utilização de grupos de recursos e apoiam o controlo de acesso baseado em funções Azure (Azure RBAC). Para obter mais informações sobre como implementar funções de acesso, consulte o controlo de acesso baseado em funções Azure (Azure RBAC).

Cmdlet Descrição
New-AzSqlDatabaseFailoverGroup Este comando cria um grupo de failover e regista-o em servidores primários e secundários
Remove-AzSqlDatabaseFailoverGroup Remove um 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 Desencadeia falha de um grupo de failover para o servidor secundário
Add-AzSqlDatabaseToFailoverGroup Adiciona uma ou mais bases de dados a um grupo de failover

Passos seguintes