Visão geral da continuidade de negócios com o Banco de Dados do Azure para MariaDB

  • Artigo

Importante

O Banco de Dados do Azure para MariaDB está no caminho da aposentadoria. É altamente recomendável migrar para o Banco de Dados do Azure para MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para MariaDB?.

Este artigo descreve os recursos que o Banco de Dados do Azure para MariaDB fornece para continuidade de negócios e recuperação de desastres. Saiba mais sobre as opções de recuperação de eventos com interrupções que podem causar perda de dados ou fazer com que seu banco de dados e aplicativo fiquem indisponíveis. Saiba o que fazer quando um erro de usuário ou de aplicativo afeta a integridade dos dados, uma região do Azure tem uma interrupção ou seu aplicativo precisa de manutenção.

Recursos para continuidade de negócios

Ao desenvolver seu plano de continuidade de negócios, você precisa entender o seu:

  • Objetivo de tempo de recuperação (RTO): o tempo máximo aceitável antes que o aplicativo se recupere totalmente após um evento de interrupção.
  • RPO (Recovery Point Objetive, objetivo de ponto de recuperação): a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder quando está se recuperando após um evento de interrupção.

O Banco de Dados do Azure para MariaDB fornece recursos de continuidade de negócios e recuperação de desastres que incluem backups com redundância geográfica com a capacidade de iniciar a restauração geográfica e implantar réplicas de leitura em outra região. Cada funcionalidade tem características diferentes quanto ao tempo de recuperação e à potencial perda de dados.

Com a restauração geográfica, o Banco de Dados do Azure para MariaDB cria um novo servidor usando os dados de backup replicados de outra região. O tempo total de restauração e recuperação depende do tamanho do banco de dados e da quantidade de dados de log a serem recuperados. O tempo total para estabelecer o servidor varia de alguns minutos a algumas horas.

Com réplicas de leitura, os logs de transações do banco de dados primário são transmitidos de forma assíncrona para uma réplica. Se houver uma interrupção do banco de dados primário devido a uma falha no nível da zona ou da região, o failover para a réplica fornecerá um RTO mais curto e uma perda de dados reduzida.

Nota

O atraso entre o banco de dados primário e a réplica depende da latência entre os sites, da quantidade de dados a serem transmitidos e (mais importante) da carga de trabalho de gravação do servidor primário. Cargas de trabalho de gravação pesadas podem gerar um atraso significativo.

Devido à natureza assíncrona da replicação usada para réplicas de leitura, não considere as réplicas de leitura como uma solução de alta disponibilidade. As defasagens mais altas podem significar RTO e RPO mais altos. As réplicas de leitura podem atuar como uma alternativa de alta disponibilidade apenas para cargas de trabalho em que o atraso permanece menor durante os horários de pico e fora de pico. Caso contrário, as réplicas de leitura destinam-se à verdadeira escala de leitura para cargas de trabalho com muita leitura e para cenários de recuperação de desastres.

A tabela a seguir compara RTO e RPO em um cenário de carga de trabalho típica:

Funcionalidade Básica Fins gerais Com otimização de memória
Restauração point-in-time a partir do backup Qualquer ponto de restauração dentro do período de retenção
RTO varia
RPO é inferior a 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO varia
RPO é inferior a 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO varia
RPO é inferior a 15 minutos
Restauração geográfica a partir de backups replicados geograficamente Não suportado RTO varia
RPO é maior que 24 horas		 RTO varia
RPO é maior que 24 horas
Réplicas de leitura RTO é minutos
RPO é inferior a 5 minutos		 RTO é minutos
RPO é inferior a 5 minutos		 RTO é minutos
RPO é inferior a 5 minutos

RTO e RPO podem ser muito maiores em alguns casos, dependendo de fatores como latência entre sites, a quantidade de dados a serem transmitidos e a carga de trabalho de gravação do banco de dados primário.

Recuperação de um servidor após um erro de usuário ou aplicativo

Você pode usar os backups do serviço para recuperar um servidor de vários eventos de interrupção. Por exemplo, um usuário pode excluir acidentalmente alguns dados, descartar inadvertidamente uma tabela importante ou até mesmo soltar um banco de dados inteiro. Um aplicativo pode substituir acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo.

Pode executar um restauro para um ponto anterior no tempo para criar uma cópia do servidor para um ponto anterior no tempo válido e conhecido. Esse point-in-time deve estar dentro do período de retenção de backup que você configurou para o servidor. Depois que os dados forem restaurados no novo servidor, você poderá substituir o servidor original pelo servidor recém-restaurado ou copiar os dados necessários do servidor restaurado para o servidor original.

Importante

Você pode restaurar servidores excluídos somente dentro de cinco dias após a exclusão. Após cinco dias, os backups são excluídos. Você pode acessar e restaurar o backup do banco de dados somente da assinatura do Azure que hospeda o servidor. Para restaurar um servidor descartado, consulte as etapas documentadas. Para ajudar a proteger os recursos do servidor contra exclusão acidental ou alterações inesperadas após a implantação, os administradores podem usar bloqueios de gerenciamento.

Recuperação de uma interrupção do datacenter regional do Azure

Embora seja raro, um datacenter do Azure pode ter uma interrupção. Quando ocorre uma interrupção, ela causa uma interrupção nos negócios que pode durar apenas alguns minutos, mas pode durar horas.

Uma opção é esperar que o servidor volte a ficar online quando a interrupção do datacenter terminar. Quando o datacenter tem uma interrupção, você não sabe quanto tempo a interrupção pode durar. Portanto, essa opção funciona apenas para aplicativos que podem se dar ao luxo de ter o servidor offline por algum tempo (por exemplo, um ambiente de desenvolvimento).

Restauro geográfico

O recurso de restauração geográfica restaura o servidor usando backups com redundância geográfica. Os backups são hospedados na região emparelhada do servidor. Esses backups são acessíveis mesmo quando a região onde o servidor está hospedado está offline. Pode restaurar a partir destas cópias de segurança para qualquer outra região e, em seguida, colocar o seu servidor novamente online. Saiba mais sobre a restauração geográfica no artigo sobre conceitos de backup e restauração.

Importante

A restauração geográfica só é possível se você provisionou o servidor com armazenamento de backup com redundância geográfica. Se você quiser alternar de backups localmente redundantes para geo-redundantes para um servidor existente, você deve gerar um backup do seu servidor existente usando mysqldump. Em seguida, restaure para um servidor recém-criado configurado com backups com redundância geográfica.

Réplicas de leitura entre regiões

Você pode usar réplicas de leitura entre regiões para aprimorar seu planejamento de continuidade de negócios e recuperação de desastres. As réplicas de leitura são atualizadas de forma assíncrona através da tecnologia de replicação do MySQL para logs binários. Saiba mais sobre réplicas de leitura, regiões disponíveis e como fazer failover no artigo sobre conceitos de réplica de leitura.

FAQ

Onde o Banco de Dados do Azure para MariaDB armazena dados de clientes?

Por padrão, o Banco de Dados do Azure para MariaDB não move nem armazena dados do cliente para fora da região onde ele é implantado. No entanto, você pode, opcionalmente, optar por habilitar backups com redundância geográfica ou criar réplicas de leitura entre regiões para armazenar dados em outra região.

Próximos passos