Confiabilidade no Banco de Dados SQL do Azure

O Banco de Dados SQL do Azure é um mecanismo de banco de dados de PaaS (plataforma como serviço) totalmente gerenciado que manipula a maioria das funções de gerenciamento de banco de dados, como atualização, correções, 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 dar 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 o Banco de Dados SQL do Azure resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas, como lidar com a manutenção do serviço e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) do Banco de Dados SQL do Azure.

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

Para saber mais sobre como implantar o Banco de Dados SQL do Azure para dar suporte aos requisitos de confiabilidade da solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as 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 SQL Database é executado no motor mais recente e estável do SQL Server 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 protegerá seus dados se ocorrer uma falha localizada, como uma falha de rede em pequena escala ou uma falha de energia, e também durante os seguintes eventos:

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

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

• Problemas e interrupções de datacenter, em que o datacenter tem os seguintes componentes:

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

  • Máquinas físicas que hospedam a VM (máquina virtual) 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 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 meio de redundância – Banco de Dados SQL.

Resiliência a falhas transitórias

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

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

O Banco de Dados SQL lida automaticamente com tarefas críticas de manutenção, como aplicação de patch, backups, atualizações do mecanismo do Windows e do Banco de Dados SQL. Ele também lida automaticamente com eventos não planejados, como hardware subjacente, software ou falhas de 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 executadas continuamente.

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

Você pode testar a resiliência do seu aplicativo a falhas transitórias seguindo as diretrizes em Testar resiliência a falhas do aplicativo.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

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

Requirements

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:

• A replicação geográfica ativa replica um banco de dados individual para um banco de dados secundário sincronizado.

• Os grupos de failover se baseiam na replicação geográfica ativa e permitem que você faça failover de um grupo de bancos de dados.

Replicação geográfica ativa

A replicação geográfica ativa cria um banco de dados secundário legível sincronizado continuamente (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.

Requirements

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

• Suporte à região:a replicação geográfica ativa pode ser habilitada em todas as regiões do Azure e não exige que você use pares de região do Azure.

  Dica

  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 emparelhadas, 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: O primário e o secundário geográfico devem ter a mesma camada de serviço e devem ter a mesma camada de computação, tamanho da computação e redundância de armazenamento de backup.

• Firewall: o primário e o secundário geográfico devem ter as mesmas regras de firewall de endereço IP.

• Assinaturas do Azure: A replicação geográfica ativa tem suporte para bancos de dados em diferentes assinaturas do Azure.

Considerações

• A replicação geográfica ativa foi projetada para oferecer 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 precisar eliminar a perda de dados da replicação assíncrona durante failovers, configure seu aplicativo para bloquear o thread de execução até que a última transação confirmada seja transmitida e persistida no log de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e reduz o desempenho do 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 Replicação geográfica ativa.

Custo

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

Configurar o suporte a várias regiões

• Habilitar a replicação geográfica ativa: Para obter mais informações sobre como habilitar a replicação geográfica ativa no portal do Azure, consulte Configurar a replicação geográfica ativa para o Banco de Dados SQL ou a replicação geográfica ativa.

  Depois de habilitar a replicação geográfica ativa, uma etapa inicial de propagação pode levar algum tempo.

• Desabilitar a replicação geográfica ativa: Para obter mais informações sobre como desabilitar a replicação geográfica ativa em um banco de dados, consulte Remover banco de dados secundário.

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 a 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 e 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 das 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 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 falha de região

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

• Detecção e resposta: Você é responsável por detectar a interrupção de um banco de dados ou região e por disparar o failover.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de 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, opcionalmente, você poderá executar um failover sem perda de dados. O processo de failover sincroniza dados entre os bancos de dados primários e secundários antes de alternar as 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. Verifique se o aplicativo lida com falhas transitórias para que ele possa se recuperar de curtos períodos de tempo 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ê experimenta.

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

Recuperação de região

Após a recuperação da região primária, é possível executar manualmente um failback para a região primária realizando outro failover.

Teste de falhas na região

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

Grupos de failover

Grupos de failover são baseados 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.

• Executar failover dos bancos de dados como um grupo.

• Use endpoints de conexão que direcionam automaticamente as conexões para o principal.

Requirements

• Suporte à região: Os grupos de failover podem ser criados em todas as regiões do Azure e não exigem que você use pares de região do Azure.

  Dica

  Se você configurar um grupo de failover com regiões não pareadas, 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: Os bancos de dados secundários em um grupo de failover devem ter a mesma camada de serviço, camada de computação, tamanho da computação, regras de firewall de endereço IP e redundância de armazenamento de backup que o banco de dados primário.

Considerações

• Possível perda de dados: Como a replicação geográfica é assíncrona, é possível ter perda de dados quando ocorre um failover. Se precisar eliminar a perda de dados da replicação assíncrona durante failovers, poderá configurar seu aplicativo para bloquear o thread de chamada até que a última transação confirmada seja transmitida e protegida no log de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e reduz o desempenho do 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

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

Configurar o suporte a várias regiões

• Ativar grupos de failover: Você configura um grupo de failover em um servidor lógico. Você pode adicionar todos os bancos de dados no servidor lógico ao grupo de failover ou selecionar um subconjunto de bancos de dados a serem adicionados.

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

  Importante

  É provável que um failover iniciado pela Microsoft ocorra após um atraso significativo e seja realizado com base no melhor esforço possível. O failover de bancos de dados pode ocorrer em um momento 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.

• Desabilitar 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 em 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 e gravação e somente leitura, os grupos de failover fornecem dois pontos de extremidade de ouvintes onde você pode conectar seus aplicativos. Use os pontos de extremidade do ouvinte do grupo de failover para minimizar o tempo de inatividade durante failovers. Durante operações normais, o seguinte comportamento de roteamento ocorre:

  • O ponto de extremidade de ouvinte de leitura e gravação direciona todas as solicitações para os bancos de dados primários.

  • O ponto de extremidade de ouvinte somente leitura direciona todas as solicitações para um banco de dados secundário para 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 falha de região

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

• A detecção e a resposta dependem da política de failover que você usa.

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

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

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de 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, opcionalmente, você poderá executar um failover sem perda de dados. O processo de failover sincroniza dados entre os bancos de dados primários e secundários antes de alternar as 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 é disparado apenas em situações excepcionais. Os failovers gerenciados pela Microsoft são failovers forçados, o que significa que algumas perdas de dados são esperadas. 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 que você usa.

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

  • Failover iniciado pela Microsoft: Você pode especificar um período de carência que determina quanto tempo a Microsoft deve aguardar 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.

• Redirecionamento de tráfego: durante o failover, o Banco de Dados SQL do Azure atualiza os pontos de extremidade de ouvinte de leitura e gravação e de somente leitura para direcionar o tráfego aos novos bancos de dados primário e secundário, 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 ouvinte somente leitura não poderá se conectar até que o novo secundário esteja disponível.

Recuperação de região

Você é responsável por realizar o failback para a região primária, se necessário. Você pode executar manualmente um failback para a região primária realizando um failover gerenciado pelo cliente.

Mesmo que a Microsoft tenha iniciado o failover original, você continuará responsável por realizar o failback para a região anterior, se desejar.

Teste de falhas na região

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

Backup e restauração

Faça backups de seus bancos de dados para proteger contra vários riscos, incluindo perda de dados. Os backups podem ser restaurados para se recuperar de perda acidental de dados, corrupção ou outros problemas. Os backups diferem da redundância de zona, da replicação geográfica ativa ou dos grupos de failover e têm propósitos 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 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 o armazenamento com redundância geográfica. Essa capacidade permite a restauração geográfica dos backups na região pareada. 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 usa replicação de objeto de 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 do serviço

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

O Banco de Dados SQL permite especificar uma janela de manutenção normalmente usada para atualizações de serviço e outras operações de manutenção. Configurar uma janela de manutenção pode ajudar a minimizar 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. Atualizações 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 a janela Manutenção no Banco de Dados SQL.

Contrato de nível de serviço

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

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

Ao implantar um banco de dados ou pool elástico com redundância de zona e usar uma camada de serviço com suporte, o SLA de tempo de atividade é maior.

Conteúdo relacionado

• Visão geral da continuidade dos negócios com o Banco de Dados SQL
• Lista de verificação de alta disponibilidade e recuperação de desastre – Banco de Dados SQL
• Confiabilidade no Azure