Partilhar via

Fiabilidade na Base de Dados SQL do Azure

O Banco de Dados SQL do Azure é um mecanismo de banco de dados de plataforma como serviço (PaaS) totalmente gerenciado que lida com a maioria das funções de gerenciamento de banco de dados, como atualização, aplicação de patches, backups e monitoramento sem o envolvimento do usuário.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar a Azure SQL Database resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas, como gerir a manutenção do serviço e destaca algumas informações chave sobre o acordo de nível de serviço (SLA) Azure SQL Database.

Recomendações de implantação de produção

Para saber como implantar o Banco de Dados SQL do Azure para dar suporte aos requisitos de confiabilidade da sua solução e como a confiabilidade afeta outros aspetos da sua arquitetura, consulte Práticas recomendadas de arquitetura para o Banco de Dados SQL do Azure no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

O Banco de Dados SQL é executado no mecanismo de Banco de Dados SQL Server estável mais recente do sistema operacional Windows, incluindo todos os patches aplicáveis.

O Banco de dados SQL obtém redundância armazenando três cópias de seus dados em um único datacenter na região primária por padrão. Essa abordagem protege seus dados se ocorrer uma falha localizada, como uma falha de rede em pequena escala ou falha de energia, e também durante os seguintes eventos:

  • Operações de gerenciamento iniciadas pelo cliente que resultam em um breve tempo de inatividade

  • Operações de manutenção de serviços

  • Problemas e interrupções do datacenter, onde o datacenter tem os seguintes componentes:

    • Racks, onde as máquinas que alimentam o seu serviço estão funcionando

    • Máquinas físicas que hospedam a máquina virtual (VM) que executa o mecanismo do Banco de dados SQL

  • Outros problemas com o mecanismo do Banco de dados SQL

  • Outras possíveis interrupções localizadas não planejadas

O Banco de Dados SQL usa o Azure Service Fabric para gerenciar a replicação do seu banco de dados.

A redundância é implementada de maneiras diferentes para diferentes camadas de serviço do Banco de dados SQL. Para obter mais informações, consulte Disponibilidade por redundância - Banco de dados SQL.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

O Banco de dados SQL lida automaticamente com tarefas críticas de manutenção, como patches, backups, atualizações do Windows e do mecanismo do Banco de dados SQL. Ele também lida automaticamente com eventos não planejados, como falhas subjacentes de hardware, software ou rede. O Banco de dados SQL foi projetado para se recuperar rapidamente de falhas críticas, o que garante que seus dados estejam sempre disponíveis. A maioria dos usuários não percebe que as atualizações são realizadas continuamente.

Quando um banco de dados é corrigido ou faz failover, o tempo de inatividade não é perturbador se você empregar a lógica de repetição em seu aplicativo.

Você pode testar a resiliência do seu aplicativo a falhas transitórias seguindo as orientações em Testar resiliência de falhas do aplicativo.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Você pode criar um banco de dados único com redundância de zona ou pool elástico. A redundância de zona garante que seu banco de dados seja resiliente a um grande conjunto de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo.

Para a camada de serviço de uso geral, a redundância de zona garante que os componentes de computação sem estado e os componentes de armazenamento de dados com monitoração de estado do Banco de dados SQL sejam resilientes a uma interrupção da zona de disponibilidade.

Para as camadas de serviço Premium, Business Critical e Hyperscale, a redundância de zona coloca réplicas do seu banco de dados SQL em várias zonas de disponibilidade do Azure em sua região principal. Para eliminar um único ponto de falha (SPOF), o anel de controle também é duplicado em várias zonas de disponibilidade.

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Requerimentos

As camadas de serviço Basic e Standard não suportam redundância de zona.

A redundância de zona está disponível para bancos de dados nas camadas de serviço Business Critical, General Purpose e Hyperscale do modelo de compra baseado em vCore e somente na camada de serviço Premium do modelo de compra baseado em DTU.

Para o nível de serviço de uso geral:

Para os níveis de serviço Premium e Business Critical:

Para a camada de serviço Hyperscale:

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Considerações

  • Latência: Os bancos de dados com redundância de zona têm réplicas em datacenters separados. A latência de rede adicionada pode aumentar o tempo de confirmação de transação e potencialmente afetar o desempenho de determinadas cargas de trabalho OLTP (processamento de transações online). A maioria dos aplicativos não é sensível a essa latência extra.

  • master banco de dados: Quando um banco de dados com uma configuração redundante de zona é criado em um servidor lógico, o master banco de dados associado ao servidor também é automaticamente tornado redundante de zona. Para obter mais informações sobre como verificar se o master banco de dados é redundante de zona, consulte Disponibilidade redundante de zona de banco de dados.

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Custo

Para a camada de serviço de uso geral, há uma cobrança extra para habilitar a redundância de zona para o Banco de dados SQL. Para obter mais informações, consulte Preços - Banco de dados SQL.

As camadas de serviço Premium e Business Critical fornecem várias réplicas do seu banco de dados. Quando você habilita a redundância de zona, as réplicas são distribuídas entre zonas de disponibilidade. Essa distribuição significa que não há nenhum custo extra associado à habilitação da redundância de zona em seu banco de dados SQL quando ele estiver na camada de serviço Premium ou Business Critical.

Se você habilitar várias réplicas do banco de dados da camada de serviço Hyperscale, poderá habilitar a redundância de zona. Quando você habilita a redundância de zona, as réplicas são distribuídas entre zonas de disponibilidade. Essa distribuição significa que não há nenhum custo extra associado à habilitação da redundância de zona em seu banco de dados SQL quando ele estiver na camada de serviço Hyperscale, supondo que você tenha várias réplicas.

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Configurar o suporte à zona de disponibilidade

Para os níveis de serviço de uso geral, premium e crítico para os negócios:

Para a camada de serviço Hyperscale:

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Comportamento quando todas as zonas estão íntegras

Esta seção descreve o que esperar quando os bancos de dados são configurados para redundância de zona e todas as zonas de disponibilidade estão operacionais.

Para o nível de serviço de uso geral:

  • Roteamento de tráfego entre zonas: As solicitações são roteadas para um nó que executa a camada de computação do banco de dados SQL. Quando a redundância de zona está ativada, este nó pode estar localizado em qualquer zona de disponibilidade.

  • Replicação de dados entre zonas: Os arquivos de dados e de log são replicados de forma síncrona entre zonas de disponibilidade usando o ZRS. As operações de gravação não são consideradas concluídas até que os dados sejam replicados com êxito em todas as zonas de disponibilidade. Essa replicação síncrona garante forte consistência e zero perda de dados durante falhas de zona. No entanto, isso pode resultar em latência de gravação ligeiramente maior em comparação com o armazenamento com redundância local (LRS).

Para os níveis de serviço Premium e Business Critical:

  • Roteamento de tráfego entre zonas: As réplicas são distribuídas entre zonas de disponibilidade, e uma dessas réplicas é designada como réplica primária . As solicitações são roteadas para a réplica primária do banco de dados.

  • Replicação de dados entre zonas: A réplica primária envia constantemente as alterações para as réplicas secundárias sequencialmente para garantir que os dados persistam em um número suficiente de réplicas secundárias antes de confirmar cada transação. Esse processo garante que, se a réplica primária ou uma réplica secundária legível ficar indisponível por qualquer motivo, uma réplica totalmente sincronizada estará sempre disponível para failover. Quando a redundância de zona está habilitada, essas réplicas estão localizadas em zonas de disponibilidade diferentes. No entanto, o processo pode resultar em latência de gravação um pouco maior devido à latência da rede em zonas de travessia.

Para a camada de serviço Hyperscale:

  • Roteamento de tráfego entre zonas: As réplicas de banco de dados são distribuídas entre zonas de disponibilidade, e uma dessas réplicas é designada como réplica primária . As solicitações são roteadas para a réplica primária do banco de dados.

  • Replicação de dados entre zonas: A réplica do banco de dados primário envia as alterações por meio de um serviço de log com redundância de zona, que replica todas as alterações de forma síncrona nas zonas de disponibilidade. Os servidores de página estão localizados em cada zona de disponibilidade e armazenam o estado do banco de dados. Esse processo garante que, se a réplica primária ou uma réplica secundária legível ficar indisponível por qualquer motivo, uma réplica totalmente sincronizada estará sempre disponível para failover. No entanto, o processo pode resultar em latência de gravação ligeiramente maior em comparação com o LRS.

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando os bancos de dados são configurados para redundância de zona e ocorre uma interrupção de zona de disponibilidade.

  • Deteção e resposta: O Banco de dados SQL é responsável por detetar e responder a uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Solicitações ativas: Quando uma zona de disponibilidade fica offline, todas as solicitações que estão sendo processadas na zona de disponibilidade defeituosa são encerradas e devem ser repetidas. Para mais informações sobre como tornar as suas aplicações resilientes a este tipo de problemas, consulte a orientação Resiliência a falhas transitórias .

  • Reencaminhamento do tráfego: Para a camada de serviço de uso geral, o Banco de dados SQL move o mecanismo de banco de dados para outro nó de computação sem estado que está em uma zona de disponibilidade diferente e tem capacidade livre suficiente. Após a conclusão do failover, novas conexões são redirecionadas automaticamente para o novo nó de computação primário.

    Para obter mais informações, consulte camada de serviço de uso geral.

  • Reencaminhamento do tráfego: Para as camadas de serviço Premium e Business Critical, o Banco de dados SQL seleciona uma réplica em outra zona de disponibilidade para se tornar a réplica principal. Depois que uma réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha um número suficiente de réplicas para manter um quórum. Após a conclusão do failover, as novas conexões são redirecionadas automaticamente para a nova réplica primária (ou réplica secundária legível com base na cadeia de conexão).

    Para obter mais informações, consulte Níveis de serviço Premium e Business Critical.

  • Reencaminhamento do tráfego: Para a camada de serviço Hyperscale, se a réplica primária foi perdida devido à interrupção da zona, o Banco de dados SQL promove uma das réplicas de alta disponibilidade em outra zona para ser a nova primária.

    Para obter mais informações, consulte camada de serviço de hiperescala.

  • Tempo de inatividade esperado: Pode haver uma pequena quantidade de tempo de inatividade durante um failover de zona de disponibilidade. O tempo de indisponibilidade é normalmente inferior a 30 segundos, o que a sua aplicação deve tolerar se seguir as orientações de Resiliência a falhas transitórias .

  • Perda de dados esperada: Não há perda de dados esperada durante um failover de zona de disponibilidade.

Para exibir informações sobre o suporte à zona de disponibilidade para outras camadas de serviço, certifique-se de selecionar a camada de serviço apropriada no início desta página.

Recuperação de zona

Quando a zona de disponibilidade se recupera, o Azure Service Fabric cria automaticamente réplicas de banco de dados na zona de disponibilidade recuperada, remove todas as réplicas temporárias criadas nas outras zonas de disponibilidade e retoma o roteamento de tráfego normal para seu banco de dados. Para evitar interrupções, a réplica primária não retorna automaticamente a zona original após a recuperação da zona.

Teste de falhas de zona

A plataforma do Banco de dados SQL gerencia procedimentos de roteamento de tráfego, failover e recuperação de zona para bancos de dados com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou validar processos de falha da zona de disponibilidade. No entanto, você pode validar o tratamento de falhas e failovers do seu aplicativo seguindo o processo descrito em Testar resiliência de falhas do aplicativo.

Resiliência a falhas em toda a região

Esta seção fornece uma visão geral de dois recursos relacionados, mas separados, que podem ser usados para replicação geográfica de várias regiões do Banco de dados SQL:

Replicação geográfica ativa

A replicação geográfica ativa cria um banco de dados secundário legível continuamente sincronizado (que às vezes é conhecido como geo-secundário ou réplica geográfica) em qualquer região para um único banco de dados primário. A replicação geográfica ativa pode criar bancos de dados secundários na mesma região, mas essa configuração não fornece proteção contra uma interrupção de região. Ao usar a replicação geográfica ativa para obter redundância geográfica, você localiza o banco de dados secundário em uma região diferente do banco de dados primário.

Requerimentos

Ao usar a replicação geográfica ativa, considere os seguintes requisitos:

  • Suporte para regiões: A geo-replicação ativa pode ser ativada em todas as regiões Azure e não exige que uses pares de regiões Azure.

    Sugestão

    O Banco de Dados SQL segue uma prática de implantação segura em que o Azure se esforça para não implantar atualizações em regiões emparelhadas ao mesmo tempo. Se você configurar a replicação geográfica ativa para usar regiões não pareadas, defina janelas de manutenção diferentes para os servidores em cada região. Essa abordagem ajuda a reduzir a chance de ambas as regiões enfrentarem problemas de conectividade causados pela manutenção que ocorre ao mesmo tempo.

  • Configuração: Tanto o primário como o geo-secundário devem ter o mesmo nível de serviço e devem ter o mesmo nível de computação, tamanho de computação e redundância de armazenamento de backup.

  • Firewall: Tanto o primário como o geo-secundário devem ter as mesmas regras de firewall de endereço IP.

  • Azure subscriptions: A geo-replicação ativa é suportada para bases de dados em diferentes subscrições Azure.

Considerações

  • A replicação geográfica ativa foi projetada para fornecer failover de um único banco de dados. Se você precisar fazer failover de vários bancos de dados, considere usar grupos de failover.

  • Como a replicação geográfica é assíncrona, a perda de dados é possível quando ocorre um failover. Se você precisar eliminar a perda de dados da replicação assíncrona durante failovers, configure seu aplicativo para bloquear o thread de chamada até que a última transação confirmada seja transmitida e reforçada no log de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e reduz o desempenho do seu aplicativo. Para obter mais informações, consulte Evitar a perda de dados críticos.

  • Para mais informações sobre limitações e considerações, veja Geo-replicação ativa.

Custo

Os bancos de dados secundários são cobrados como bancos de dados separados.

Se não utilizar uma base de dados secundária para cargas de leitura ou escrita, considere se pode designá-la como uma réplica em espera para reduzir os seus custos.

Configurar suporte a várias regiões

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando um banco de dados é configurado para usar replicação geográfica ativa e todas as regiões estão operacionais.

  • Roteamento de tráfego entre regiões: Seu aplicativo deve ser configurado para enviar solicitações de leitura-gravação para o banco de dados primário. Opcionalmente, você pode enviar solicitações somente leitura para um banco de dados secundário, o que ajuda a reduzir o impacto de cargas de trabalho somente leitura no banco de dados primário.

  • Replicação de dados entre regiões: A replicação entre os bancos de dados primário e secundário ocorre de forma assíncrona, o que significa que pode haver um atraso entre o momento em que uma alteração é aplicada ao banco de dados primário e quando é replicada para o banco de dados secundário.

    Ao executar um failover, você decide como lidar com a possibilidade de perda de dados.

Comportamento durante uma interrupção regional

Esta seção descreve o que esperar quando um banco de dados é configurado para usar replicação geográfica ativa e há uma interrupção na região principal:

  • Deteção e resposta: Você é responsável por detetar a interrupção de um banco de dados ou região e por acionar o failover.
  • Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  • Solicitações ativas: Todas as solicitações ativas durante o failover são encerradas e devem ser repetidas.

  • Perda de dados esperada: Se o banco de dados primário estiver disponível, você poderá, opcionalmente, executar um failover sem perda de dados. O processo de failover sincroniza dados entre os bancos de dados primário e secundário antes de alternar funções.

    Se o banco de dados primário não estiver disponível, talvez seja necessário executar um failover forçado, o que resulta em perda de dados. Você pode estimar a quantidade de perda de dados monitorando o atraso de replicação. Para obter mais informações, consulte Monitorar o Banco de dados SQL com métricas e alertas.

  • Tempo de inatividade esperado: Normalmente, há até 60 segundos de tempo de inatividade durante um failover. Certifique-se de que seu aplicativo lide com falhas transitórias para que possa se recuperar de curtos períodos de inatividade. Além disso, a rapidez com que você reconfigura seu aplicativo para se conectar ao novo banco de dados primário afeta o tempo de inatividade que você enfrenta.

  • Reencaminhamento do tráfego: Você é responsável por reconfigurar seu aplicativo para enviar solicitações ao novo banco de dados primário. Se você precisar ter failover transparente, considere o uso de grupos de failover.

Recuperação da região

Depois que a região primária se recuperar, você poderá executar manualmente um failback para a região primária executando outro failover.

Teste para falhas regionais

Você pode simular uma interrupção de região acionando um failover manual a qualquer momento. Você pode acionar um failover (sem perda de dados) ou um failover forçado.

Grupos de tolerância a falhas

Os grupos de failover baseiam-se na replicação geográfica ativa. Com grupos de failover, você pode executar as seguintes operações:

  • Replique um conjunto de bancos de dados de um único servidor lógico em qualquer combinação de regiões do Azure.

  • Efetuar o failover nos bancos de dados como um grupo.

  • Utilize pontos de extremidade de conexão que direcionem automaticamente as conexões para o principal.

Requerimentos

  • Apoio regional: Grupos de failover podem ser criados em todas as regiões Azure e não exigem que uses pares de regiões Azure.

    Sugestão

    Se você configurar um grupo de failover com regiões não emparelhadas, considere definir janelas de manutenção diferentes para os servidores em cada região. Essa abordagem ajuda a reduzir a chance de ambas as regiões enfrentarem problemas de conectividade causados pela manutenção que ocorre ao mesmo tempo.

  • Configuração: As bases de dados secundárias num grupo de failover devem ter o mesmo nível de serviço, camada de computação, tamanho de computação, regras de firewall de endereço IP e redundância de armazenamento de backup que a base de dados principal.

Considerações

  • Redundância de zonas: Para o nível de serviço Hyperscale, se a tua base de dados principal tiver redundância de zona ativada, então as bases de dados secundárias têm redundância de zona ativada automaticamente.
  • Redundância de zonas: As bases de dados secundárias não têm redundância de zona ativada por defeito, mas podes ativar mais tarde.

  • Possível perda de dados: Como a geo-replicação é assíncrona, é possível haver perda de dados quando ocorre um failover. Se precisar eliminar a perda de dados da replicação assíncrona durante failovers, você pode configurar seu aplicativo para bloquear o thread de chamada até que a última transação confirmada seja transmitida e reforçada no log de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e reduz o desempenho do seu aplicativo. Para obter mais informações, consulte Evitar a perda de dados críticos.

  • Para obter mais informações sobre limitações e considerações, consulte Grupos de failover.

Custo

Os bancos de dados secundários são cobrados como bancos de dados separados.

Se não utilizar uma base de dados secundária para cargas de leitura ou escrita, considere se pode designá-la como uma réplica em espera para reduzir os seus custos.

Configurar suporte a várias regiões

  • Ative grupos de failover: Configurar um grupo de failover em num servidor lógico. Você pode adicionar todos os bancos de dados no servidor lógico ao grupo de failover ou pode selecionar um subconjunto de bancos de dados para adicionar.

    Ao criar um grupo de failover, você seleciona a política de failover, que especifica quem é responsável por detetar uma interrupção e executar um failover. Você pode configurar o failover gerenciado pelo cliente, que é recomendado, ou o failover gerenciado pela Microsoft.

    Importante

    É provável que ocorra um failover iniciado pela Microsoft após um atraso significativo e é feito com base no melhor esforço. O failover de bancos de dados pode ocorrer em um horário diferente de qualquer failover de outros serviços do Azure. Para obter mais informações, consulte Configurar um grupo de failover para o Banco de dados SQL.

    Depois de configurar o grupo de failover, a etapa inicial de propagação pode levar algum tempo.

  • Desative grupos de failover: Você pode remover um banco de dados individual de um grupo de failover, remover um grupo de failover inteiro ou mover um banco de dados para um grupo de failover diferente.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando um banco de dados é configurado dentro de um grupo de failover e todas as regiões estão operacionais.

  • Roteamento de tráfego entre regiões: Para cargas de trabalho de leitura-gravação e somente leitura, os grupos de failover fornecem dois pontos de extremidade de ouvinte onde você pode conectar seus aplicativos. Use os pontos de extremidade de escuta do grupo de failover para minimizar o tempo de inatividade durante failovers. Durante as operações normais, ocorre o seguinte comportamento de roteamento:

    • O endpoint de leitura-escrita encaminha todas as solicitações para as bases de dados principais.

    • O endpoint de escuta em modo somente leitura roteia todas as solicitações para um banco de dados secundário em modo leitura.

  • Replicação de dados entre regiões: A replicação geográfica entre os bancos de dados primário e secundário ocorre de forma assíncrona. Essa latência significa que pode haver um atraso entre uma alteração que está sendo aplicada ao banco de dados primário e quando ela é replicada para o banco de dados secundário.

    Ao executar um failover, você decide como lidar com a possibilidade de perda de dados.

Comportamento durante uma interrupção regional

Esta seção descreve o que esperar quando um banco de dados é configurado em um grupo de failover e há uma interrupção na região principal:

  • A deteção e a resposta dependem da política de failover usada.

    • Failover iniciado pelo cliente: Você é responsável por detetar a interrupção de um banco de dados ou região e por acionar o failover.

    • Failover iniciado pela Microsoft: A Microsoft aciona o failover para todos os grupos de failover na região afetada. A Microsoft espera executar esse tipo de failover somente em situações excecionais. Não confie no failover gerenciado pela Microsoft para a maioria das soluções. Para obter mais informações, consulte Política de failover - gerenciado pela Microsoft.

  • Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

  • Solicitações ativas: Todas as solicitações ativas durante o failover são encerradas e devem ser repetidas.

  • Perda de dados esperada: A perda de dados depende da política de failover que você usa.

    • Failover iniciado pelo cliente: Se o banco de dados primário estiver disponível, você poderá, opcionalmente, executar um failover sem perda de dados. O processo de failover sincroniza dados entre os bancos de dados primário e secundário antes de alternar funções.

      Se o banco de dados primário não estiver disponível, talvez seja necessário executar um failover forçado, o que resulta em perda de dados. Você pode estimar a quantidade de perda de dados monitorando o atraso de replicação. Para obter mais informações, consulte Monitorar o Banco de dados SQL com métricas e alertas.

    • Failover iniciado pela Microsoft: Um failover gerenciado pela Microsoft é acionado somente em situações excecionais. Os failovers gerenciados pela Microsoft são failovers forçados, o que significa que alguma perda de dados é esperada. Você não pode controlar a quantidade de perda de dados que você pode experimentar.

  • Tempo de inatividade esperado: O tempo de inatividade depende da política de failover usada.

    • Failover iniciado pelo cliente: Normalmente, há até 60 segundos de tempo de inatividade durante um failover. Certifique-se de que seu aplicativo lide com falhas transitórias para que possa se recuperar de curtos períodos de inatividade.

    • Failover iniciado pela Microsoft: Você pode especificar um período de cortesia que determina quanto tempo a Microsoft deve esperar antes de iniciar o failover. O período mínimo de carência é de uma hora. No entanto, o tempo de resposta da Microsoft provavelmente será de várias horas, pelo menos.

  • Reencaminhamento do tráfego: Durante o failover, o Banco de dados SQL atualiza os pontos de extremidade de escuta de leitura-gravação e somente leitura para direcionar o tráfego para os novos bancos de dados primários e secundários, conforme necessário.

    Se o novo banco de dados secundário (anteriormente o banco de dados primário) não estiver disponível, o ponto de extremidade de ouvinte somente leitura não poderá se conectar até que o novo secundário esteja disponível.

Recuperação da região

Você é responsável por retornar à região principal, se necessário. Pode realizar manualmente um failback para a região primária ao executar um failover gerido pelo cliente.

Mesmo que a Microsoft tenha iniciado o failover original, você ainda será responsável por retornar à região anterior, se assim desejar.

Teste para falhas regionais

Você pode simular uma interrupção de região acionando um failover manual a qualquer momento. Você pode acionar um failover (sem perda de dados) ou um failover forçado.

Backup e restauração

Faça backups de seus bancos de dados para se proteger contra vários riscos, incluindo perda de dados. Os backups podem ser restaurados para recuperar de perda acidental de dados, corrupção ou outros problemas. Os backups diferem da redundância de zona, replicação geográfica ativa ou grupos de failover e têm finalidades diferentes. Para obter mais informações, consulte Redundância, replicação e backup.

O Banco de dados SQL fornece backups automáticos de seus bancos de dados. Para obter mais informações sobre a frequência de backup, que pode afetar a quantidade de perda de dados se você precisar restaurar a partir de um backup, consulte Backups automatizados no Banco de dados SQL.

Armazenamento de backup

Você pode optar por armazenar seus backups automatizados em LRS ou ZRS. Se você usar uma região emparelhada, poderá optar por replicar seus backups automatizados para a região emparelhada usando armazenamento com redundância geográfica. Esse recurso permite a restauração geográfica de seus backups na região emparelhada. Para obter mais informações, consulte Backups automatizados no Banco de dados SQL.

Se você usar uma região não emparelhada ou se precisar replicar backups para uma região diferente da região emparelhada, considere exportar o banco de dados e armazenar o arquivo exportado em uma conta de armazenamento que use a replicação de objeto blob para replicar para uma conta de armazenamento em outra região. Para obter mais informações, consulte Exportar um banco de dados.

Resiliência à manutenção de serviços

Quando o Banco de dados SQL executa a manutenção em seus bancos de dados e pools elásticos, ele pode fazer failover automaticamente do banco de dados para usar uma réplica secundária. Os aplicativos cliente podem observar breves interrupções de conectividade quando ocorre um failover. As suas aplicações clientes devem seguir a orientação Resiliência a falhas transitórias para minimizar os efeitos.

O Banco de dados SQL permite especificar uma janela de manutenção que normalmente é usada para atualizações de serviço e outras operações de manutenção. Configurar uma janela de manutenção pode ajudá-lo a minimizar quaisquer efeitos colaterais, como failovers automáticos, durante o horário comercial. Você também pode receber uma notificação antecipada da manutenção planejada.

A plataforma mantém automaticamente os gateways usados para processar conexões com o Banco de dados SQL. Upgrades ou operações de manutenção também podem causar breves interrupções de conectividade que os clientes podem tentar novamente.

Para obter mais informações, consulte Janela de manutenção no Banco de dados SQL.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O contrato de nível de serviço (SLA) para o Banco de dados SQL descreve a disponibilidade esperada do serviço e o ponto e o tempo de recuperação esperados para replicação geográfica ativa.

Quando se implanta um banco de dados com redundância de zona ou um pool elástico e se utiliza um nível de serviço suportado, o SLA de tempo de atividade é maior.

Conteúdo relacionado

  • Last updated on