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

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

Importante

Base de Dados do Azure para MySQL - O Servidor Único está no caminho da reforma. Recomendamos vivamente que faça upgrade para Base de Dados do Azure para MySQL - Servidor Flexível. Para obter mais informações sobre migração para Base de Dados do Azure para MySQL - Servidor Flexível, veja o que está a acontecer com Base de Dados do Azure para MySQL Servidor Único?

Este artigo descreve as capacidades que Base de Dados do Azure para MySQL prevê para a continuidade do negócio e recuperação de desastres. Saiba mais sobre opções para recuperar de eventos disruptivos que possam causar perda de dados ou fazer com que a sua base de dados e aplicação fiquem indisponíveis. Saiba o que fazer quando um utilizador ou erro de aplicação afeta a integridade dos dados, uma região do Azure tem uma paragem ou a sua aplicação requer manutenção.

Características que pode usar para proporcionar continuidade ao negócio

À medida que desenvolve o seu plano de continuidade de negócio, precisa de compreender o tempo máximo aceitável antes que a aplicação recupere totalmente após o evento disruptivo - este é o seu Objetivo de Tempo de Recuperação (RTO). Também precisa de compreender a quantidade máxima de atualizações de dados recentes (intervalo de tempo) que a aplicação pode tolerar a perda ao recuperar após o evento disruptivo - este é o seu Objetivo de Ponto de Recuperação (RPO).

Base de Dados do Azure para MySQL Single Server fornece funcionalidades de continuidade do negócio e recuperação de desastres que incluem backups geo-redundantes com a capacidade de iniciar o geo-restauro, e implantar réplicas de leitura numa região diferente. Cada funcionalidade tem características diferentes quanto ao tempo de recuperação e à potencial perda de dados. Com a funcionalidade Geo-restauro , um novo servidor é criado usando os dados de backup que são replicados a partir 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 lidas, os registos de transações das primárias são assíncronos transmitidos para a réplica. Em caso de interrupção da base de dados primária devido a uma falha ao nível da zona ou a uma falha a nível da região, a falha na réplica fornece um RTO mais curto e uma redução da perda de dados.

Nota

O desfasamento entre o primário e a réplica depende da latência entre os sites, da quantidade de dados a transmitir e, mais importante, da carga de trabalho de escrita do servidor primário. Cargas pesadas de trabalho de escrita podem gerar um atraso significativo.

Devido à natureza assíncronia da replicação utilizada para réplicas de leitura, não devem ser consideradas como uma solução de Alta Disponibilidade (HA), uma vez que os lags mais elevados podem significar rto e RPO mais elevados. Apenas para cargas de trabalho onde o lag permanece menor através dos tempos de pico e não-pico da carga de trabalho, as réplicas lidas podem funcionar como uma alternativa HA. Caso contrário, as réplicas lidas destinam-se a uma verdadeira escala de leitura para cargas de trabalho pesadas prontas e para cenários DR (Recuperação de Desastres).

A tabela a seguir compara RTO e RPO num cenário típico de carga de trabalho :

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 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
Geo-restauro a partir de backups geo-replicados Não suportado 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*

* O RTO e o RPO podem ser muito mais elevados em alguns casos, dependendo de vários fatores, incluindo a latência entre sites, a quantidade de dados a transmitir, e, importantemente, a base de dados primária escrever carga de trabalho.

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

Pode utilizar as cópias de segurança do serviço para recuperar um servidor de vários eventos disruptivos. Um utilizador pode acidentalmente eliminar alguns dados, deixar cair inadvertidamente uma tabela importante ou mesmo deixar cair uma base de dados inteira. Uma aplicação pode acidentalmente substituir bons dados com dados maus devido a um defeito de aplicação, 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 de os dados terem sido restaurados para o novo servidor, pode substituir o servidor original pelo servidor recentemente restaurado ou copiar os dados necessários do servidor restaurado para o servidor original.

Importante

Os servidores eliminados só podem ser restaurados no prazo de cinco dias após o qual as cópias de segurança são eliminadas. A cópia de segurança da base de dados só pode ser acedida e restaurada a partir da subscrição Azure que hospeda o servidor. Para restaurar um servidor abandonado, consulte os passos documentados. Para proteger os recursos do servidor, a implantação de posts, de eliminação acidental ou alterações inesperadas, os administradores podem alavancar os bloqueios de gestão.

Recuperar de uma paragem do centro de dados regional do Azure

Embora seja raro, um centro de dados do Azure pode ficar indisponível. Quando ocorre uma paralisação, causa uma perturbação de negócio que pode durar apenas alguns minutos, mas pode durar horas.

Uma opção é esperar que o seu servidor volte a estar online quando a falha do data center terminar. Isto funciona para aplicações que podem dar ao luxo de ter o servidor offline por algum tempo, por exemplo, um ambiente de desenvolvimento. Quando o data center tem uma paragem, não sabe quanto tempo a paralisação pode durar, por isso esta opção só funciona se não precisar do seu servidor durante algum tempo.

Georrestauro

A função de geo-restauro restaura o servidor utilizando cópias de segurança geo-redundantes. As cópias de segurança estão hospedadas na região emparelhada do seu servidor. Estas cópias de segurança são acessíveis mesmo quando a região em que o seu servidor está hospedado está offline. Pode restaurar destas cópias de segurança para qualquer outra região e voltar a colocar o seu servidor online. Saiba mais sobre o geo-restauro a partir do backup e restaurar o artigo conceitos.

Importante

O geo-restauro só é possível se forte o servidor com armazenamento de backup geo-redundante. Se desejar mudar de cópias de segurança locais redundantes para geo-redundantes para um servidor existente, deve descarregar usando o mysqldump do seu servidor existente e restaurá-lo para um servidor recém-criado configurado com cópias de segurança geo-redundantes.

Réplicas de leitura transversal

Você pode usar réplicas de leitura de região cruzada para melhorar o seu plano de continuidade de negócios e recuperação de desastres. As réplicas de leitura são atualizadas assíncronea usando a tecnologia binária de replicação de registos do MySQL. Saiba mais sobre réplicas de leitura, regiões disponíveis e como falhar a partir do artigo de conceitos de réplicas lidos.

FAQ

Onde Base de Dados do Azure para MySQL armazena os dados dos clientes?

Por padrão, Base de Dados do Azure para MySQL não move nem armazena os dados dos clientes para fora da região em que está implantado. No entanto, os clientes podem optar opcionalmente por permitir backups geo-redundantes ou criar réplicas de leitura transversal para armazenar dados noutra região.

Passos seguintes