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

  • Artigo

Importante

O Banco de Dados do Azure para MariaDB está a caminho da desativação. É altamente recomendável que você migre 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 a continuidade dos negócios e a recuperação de desastre. Saiba mais sobre as opções para recuperação dos eventos interruptivos que podem causar perda de dados ou tornar o banco de dados e o aplicativo 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 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.
  • Objetivo de ponto de recuperação (RPO): 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 um possui características diferentes para o 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 para restaurar e recuperar depende do tamanho do banco de dados e da quantidade de dados de log a serem recuperados. O tempo geral 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.

Observação

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 (o 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 maior RTO e RPO. 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 à escala de leitura verdadeira para cargas de trabalho de leitura pesada e para cenários de recuperação de desastres.

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

Funcionalidade Basic Propósito geral Memória otimizada
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 de backups replicados geograficamente Sem suporte 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

O RTO e o RPO podem ser muito maiores em alguns casos, dependendo de fatores como a 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 interruptivos. Por exemplo, um usuário pode excluir acidentalmente alguns dados, descartar inadvertidamente uma tabela importante ou até mesmo descartar um banco de dados inteiro. Um aplicativo pode substituir acidentalmente dados bons por dados incorretos devido a um defeito do aplicativo.

Você pode executar uma restauração pontual para criar uma cópia do servidor em um ponto no tempo conhecido e ideal. 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 para o 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 recursos do servidor de exclusão acidental ou de alterações inesperadas após implantações, 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 paralisação, ela causa uma interrupção de negócios que pode durar apenas alguns minutos, mas pode durar horas.

Uma opção é aguardar 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).

Restauração geográfica

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. Você pode restaurar esses backups para qualquer outra região e, em seguida, colocar o servidor online novamente. Saiba mais sobre restauração geográfica no artigo sobre conceitos de backup e restauração.

Importante

A restauração geográfica só será 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 backups com redundância geográfica para um servidor existente, você deve gerar um backup do 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 por meio 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.

Perguntas frequentes

Onde o Azure Database para MariaDB armazena dados do cliente?

Por padrão, o Banco de Dados do Azure para MariaDB não move ou armazena dados de clientes para fora da região onde está 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óximas etapas