Visão geral da continuidade dos 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 da desativação. É altamente recomendável que você atualize para o servidor flexível do Banco de Dados do Azure para MySQL. Para obter mais informações sobre a migração para o servidor flexível do Banco de Dados do Azure para MySQL, confira O que está acontecendo com o Servidor Único do Banco de Dados do Azure para MySQL?

Este artigo descreve os recursos que o Banco de Dados do Azure para MySQL 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. Aprenda o que fazer quando um erro de usuário ou de aplicativo afeta a integridade dos dados, quando uma região do Azure tem uma interrupção ou quando seu aplicativo necessita de manutenção.

Recursos que podem ser utilizados para fornecer continuidade dos negócios

Na medida em que você desenvolve o plano de continuidade dos negócios, será necessário entender qual é o tempo máximo aceitável antes que o aplicativo recupere-se completamente após o evento interruptivo - esse é o RTO (Objetivo do Tempo de Recuperação). Além disso, será necessário entender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que o aplicativo poderá tolerar perder durante a recuperação após um evento interruptivo - esse é o RPO (Objetivo de Ponto de Recuperação).

O servidor único do Banco de Dados do Azure para MySQL fornece recursos de continuidade dos 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 um possui características diferentes para o 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 replicados a partir de outra região. O tempo geral para restaurar e recuperar depende do tamanho dos arquivos de banco de dados e da quantidade de logs 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 primário são transmitidos de forma assíncrona para a réplica. No caso de uma falha do banco de dados primário devido a uma falha de nível da zona ou de nível de região, efetuar failover com a réplica fornece um RTO mais curto e uma perda de dados reduzida.

Observação

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 HA (Alta Disponibilidade), uma vez que o atraso maior pode significar RTO e OPR maiores. Somente para cargas de trabalho nas quais o atraso permanece menor por meio do horário de pico e horário fora de 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 escala de leitura real para cargas de trabalho pesadas e para cenários de DR (Recuperação de Desastre).

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

Recurso Basic Uso Geral Otimizado para memória
Recuperação Pontual do backup Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min		 Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min		 Qualquer ponto de restauração dentro do período de retenção
RTO – Varia
RPO < 15 min
Restauração geográfica de backups replicados geograficamente Sem suporte RTO – Varia
RPO < 1 h		 RTO – Varia
RPO < 1 h
Réplicas de leitura RTO – Minutos*
RPO < 5 min*		 RTO – Minutos*
RPO < 5 min*		 RTO – Minutos*
RPO < 5 min*

*Em alguns casos, o RTO e o OPR podem ser muito maiores, dependendo de vários fatores, incluindo a 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 aplicativo ou usuário

Você pode usar os backups do serviço para recuperar um servidor de vários eventos interruptivos. Um usuário pode excluir alguns dados acidentalmente, remover uma tabela importante inadvertidamente ou até mesmo um banco de dados inteiro. Um aplicativo pode substituir acidentalmente dados corretos por dados incorretos, devido a uma falha de aplicativo, e assim por diante.

Você pode executar uma restauração pontual para criar uma cópia do servidor em um ponto no tempo conhecido e ideal. Esse ponto no tempo 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 de origem pelo servidor restaurado recentemente, ou copiar os dados necessários do servidor restaurado para o servidor de origem.

Importante

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

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

Embora seja raro, um data center do Azure pode ter uma interrupção. Quando uma interrupção ocorre, isso causa uma interrupção dos negócios, que pode durar alguns minutos ou horas.

Uma opção é aguardar até que o servidor retorne online quando a interrupção do data center terminar. Isso funciona para aplicativos que podem ter o servidor offline por algum período de tempo, por exemplo, um ambiente de desenvolvimento. Quando o data center tem uma interrupção, não é possível saber por quanto tempo a interrupção poderá durar, então, essa opção somente funcionará se você não precisar usar o servidor por algum tempo.

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 serão acessíveis mesmo quando a região em que seu servidor está hospedado estiver offline. É possível restaurar a partir desses backups para qualquer outra região e retornar o servidor para online. Saiba mais sobre a restauração geográfica no artigo de conceitos de backup e restauração.

Importante

A restauração geográfica somente será possível se o servidor foi provisionado com armazenamento de backup com redundância geográfica. Se você quiser alternar de backups com redundância local para backups com redundância geográfica de um servidor existente, será necessário fazer um despejo usando o mysqldump do servidor existente e restaurá-lo em 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 sua continuidade de negócios e planejamento de recuperação de desastre. 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.

Perguntas frequentes

Onde o Azure Database para MySQL armazena dados do cliente?

Por padrão, o Banco de Dados do Azure para MySQL não move nem armazena dados do cliente fora da região em que está implantado. No entanto, os clientes podem 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óximas etapas