Partilhar via

Visão geral da continuidade de negócios com o Banco de Dados do Azure para MySQL - Servidor Único

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

Este artigo descreve os recursos que o Banco de Dados do Azure para MySQL 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 aplicativo afeta a integridade dos dados, uma região do Azure tem uma interrupção ou seu aplicativo requer manutenção.

Recursos que você pode usar para fornecer continuidade de negócios

Ao desenvolver seu plano de continuidade de negócios, você precisa entender o tempo máximo aceitável antes que o aplicativo se recupere totalmente após o evento de interrupção - este é o seu RTO (Recovery Time Objetive, objetivo de tempo de recuperação). Você também precisa entender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que o aplicativo pode tolerar perder ao se recuperar após o evento de interrupção - este é o seu RPO (Recovery Point Objetive, objetivo de ponto de recuperação).

O servidor único do Banco de Dados do Azure para MySQL 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 uma região diferente. Cada funcionalidade tem características diferentes quanto ao tempo de recuperação e à potencial perda de dados. Com o recurso de restauração geográfica, um novo servidor é criado usando os dados de backup que são replicados de outra região. O tempo total que demora a restaurar e recuperar depende do tamanho da base de dados e da quantidade de registos a recuperar. 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 primário são transmitidos de forma assíncrona para a réplica. No caso de 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 fornece um RTO mais curto e uma perda de dados reduzida.

Nota

O atraso entre o 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, elas não devem ser consideradas como uma solução de alta disponibilidade (HA), uma vez que os atrasos mais altos podem significar RTO e RPO mais altos. Somente para cargas de trabalho em que o atraso permanece menor durante os horários de pico e não pico da carga de trabalho, as réplicas de leitura podem atuar como uma alternativa de HA. Caso contrário, as réplicas de leitura destinam-se a uma verdadeira escala de leitura para cargas de trabalho pesadas prontas e para cenários de DR (recuperação de desastres).

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

Capacidade Básica Fins Gerais Com otimização de memória
Restauro para um Ponto Anterior no Tempo a partir de cópia de segurança Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos		 Qualquer ponto de restauração dentro do período de retenção
RTO - Varia
RPO < 15 minutos
Restauração geográfica a partir de backups replicados geograficamente Não suportado RTO - Varia
RPO < 1 h		 RTO - Varia
RPO < 1 h
Réplicas de leitura RTO - Atas*
RPO < 5 min*		 RTO - Atas*
RPO < 5 min*		 RTO - Atas*
RPO < 5 min*

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

Recuperar um servidor após um erro de utilizador ou aplicação

Você pode usar os backups do serviço para recuperar um servidor de vários eventos de interrupção. Um usuário pode excluir acidentalmente alguns dados, inadvertidamente soltar 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 e assim por diante.

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. Este ponto anterior no tempo tem de estar dentro do período de retenção da cópia de segurança que configurou para o seu 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

Os servidores excluídos podem ser restaurados somente dentro de cinco dias após a exclusão, após os quais os backups são excluídos. O backup do banco de dados pode ser acessado e restaurado somente a partir da assinatura do Azure que hospeda o servidor. Para restaurar um servidor descartado, consulte as etapas documentadas. Para proteger os recursos do servidor, após a implantação, contra exclusão acidental ou alterações inesperadas, os administradores podem aproveitar os bloqueios de gerenciamento.

Recuperar de uma interrupção do data center regional do Azure

Embora seja raro, um centro de dados do Azure pode ficar indisponível. 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 data center terminar. Isso funciona para aplicativos que podem se dar ao luxo de ter o servidor offline por algum período de tempo, por exemplo, um ambiente de desenvolvimento. Quando o data center tem uma interrupção, você não sabe quanto tempo a interrupção pode durar, então essa opção só funciona se você não precisar do servidor por um tempo.

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 em que o servidor está hospedado está offline. Você pode restaurar a partir desses backups para qualquer outra região e colocar seu servidor online novamente. Saiba mais sobre a restauração geográfica no artigo 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ê deseja alternar de backups localmente redundantes para geo-redundantes para um servidor existente, você deve fazer um dump usando mysqldump do seu servidor existente e restaurá-lo para um servidor recém-criado configurado com backups geo-redundantes.

Réplicas de leitura entre regiões

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

FAQ

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

Por padrão, o Banco de Dados do Azure para MySQL não move nem armazena dados do cliente para fora da região em que está implantado. No entanto, os clientes podem, opcionalmente, optar por habilitar backups com redundância geográfica ou criar réplica de leitura entre regiões para armazenar dados em outra região.

Próximos passos