Compartilhar via

Visão geral da continuidade dos negócios com Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor flexível

O servidor flexível do Banco de Dados do Azure para MySQL habilita recursos de continuidade de negócios que protegem seus bancos de dados no caso de uma interrupção planejada e não planejada. Recursos como backups automatizados e alta disponibilidade resolvem diferentes níveis de proteção contra falhas com diferentes de tempo de recuperação e exposição a perda de dados. Ao arquitetar seu aplicativo para proteger contra falhas, deverá considerar o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) para cada aplicativo. O RTO é a tolerância a tempo de inatividade e o RPO é a tolerância à perda de dados após uma interrupção no serviço de banco de dados.

A tabela a seguir ilustra os recursos que o Banco de Dados do Azure para servidor flexível MySQL oferece.

Recurso Descrição Restrições
Backup e recuperação O serviço executa automaticamente backups diários de seus arquivos de banco de dados e faz backup contínuo dos logs de transações. Os backups podem ser retidos por qualquer período entre 1 e 35 dias. Você pode restaurar o servidor de banco de dados para qualquer point-in-time dentro do período de retenção de backup. O tempo de recuperação depende do tamanho dos dados a serem restaurados + o tempo para executar a recuperação de log. Consulte Conceitos – backup e restauração para mais detalhes. Os dados de backup permanecem dentro da região
Backup com redundância local Os backups de serviço são armazenados de modo automático e seguro em um armazenamento com redundância local em uma região e na mesma zona de disponibilidade. Os backups com redundância local replicam os arquivos de dados de backup do servidor três vezes em um único local físico na região primária. O armazenamento de backup localmente redundante fornece pelo menos 99,999999999% (11 noves) de durabilidade dos objetos em um determinado ano. Consulte Conceitos – backup e restauração para mais detalhes. Aplicável em todas as regiões
Backup de redundância geográfica Os backups de serviço podem ser configurados com redundância geográfica no momento da criação. A habilitação da redundância geográfica replica os arquivos de dados de backup do servidor na região primária emparelhada para fornecer resiliência regional. O armazenamento de backup com redundância geográfica fornece pelo menos 99,99999999999999% (16 noves) de durabilidade dos objetos em um determinado ano. Consulte Conceitos – backup e restauração para mais detalhes. Disponível em todas as regiões emparelhadas do Azure
Alta disponibilidade com redundância de zona O serviço pode ser implantado no modo de alta disponibilidade, que implanta servidores primários e em espera em duas zonas de disponibilidade diferentes em uma região. A alta disponibilidade redundante de zona protege contra falhas no nível da zona e também ajuda a reduzir o tempo de inatividade do aplicativo durante eventos de tempo de inatividade planejados e não planejados. Os dados do servidor primário são replicados de maneira síncrona para a réplica em espera. Durante qualquer evento de tempo de inatividade, o servidor de banco de dados faz failover automaticamente para a réplica em espera. Consulte Conceitos – alta disponibilidade para obter mais detalhes. Com suporte em camadas de computação de Uso Geral e Comercialmente Crítico. Disponível apenas em regiões em que há várias zonas disponíveis.
Compartilhamentos de arquivos Premium Os arquivos de bancos de dados são armazenados em compartilhamentos de arquivos do Azure Premium altamente duráveis e confiáveis, que fornecem redundância de dados com três cópias de réplica, armazenadas em uma zona de disponibilidade com recursos de recuperação automática de dados. Consulte Compartilhamentos de arquivos Premium para obter mais detalhes. Dados armazenados em uma zona de disponibilidade

Mitigação de tempo de inatividade planejada

Aqui estão alguns cenários de manutenção planejada que incorrem em tempo de inatividade:

Cenário Processo
Dimensionamento de computação (Usuário) Quando é executada a operação de dimensionamento de computação, um novo servidor flexível é provisionado usando a configuração de computação dimensionada. No servidor de banco de dados existente, os pontos de verificação ativos têm permissão para serem concluídos, as conexões de cliente são descarregadas, todas as transações não confirmadas são canceladas e o servidor é desligado. O armazenamento é então anexado ao novo servidor e o banco de dados é iniciado, o que executa a recuperação, se necessário, antes de aceitar conexões de cliente.
Implantação de software novo (Azure) Novos recursos de distribuição ou correções de bugs ocorrem automaticamente como parte da manutenção planejada do serviço, e é possível agendar quando essas atividades devem ocorrer. Para saber mais, consulte a documentaçãoe também verifique o portal
Atualizações secundárias de versão (Azure) O servidor flexível do Banco de Dados do Azure para MySQL corrige automaticamente os servidores de banco de dados para a versão secundária determinada pelo Azure. Isso acontece como parte da manutenção planejada do serviço. Isso causará em alguns segundos de tempo de inatividade e o servidor de banco de dados será reiniciado automaticamente com a nova versão secundária. Para saber mais, consulte a documentaçãoe também verifique o portal.

Quando o servidor flexível é configurado com alta disponibilidade com redundância de zona, o servidor flexível executa operações no servidor em espera primeiro e, em seguida, no servidor primário sem um failover. Consulte Conceitos – alta disponibilidade para obter mais detalhes.

Mitigação de tempo de inatividade não planejada

Tempos de inatividade não planejados podem ocorrer como resultado de falhas imprevistas, incluindo falhas de hardware subjacentes, problemas de rede e bugs de software. Se o servidor de banco de dados ficar inativo inesperadamente, e tiver sido configurado com alta disponibilidade [HA], então será ativada a réplica em espera. Caso contrário, será provisionado automaticamente um novo servidor de banco de dados. Embora não seja possível evitar um tempo de inatividade não planejado, o servidor flexível reduz o tempo de inatividade realizando automaticamente operações de recuperação no servidor de banco de dados e nas camadas de armazenamento sem exigir intervenção humana.

Tempo de inatividade não planejado: cenários de falha e recuperação de serviço

Seguem alguns cenários de falha não planejados e o processo de recuperação:

Cenário Processo de recuperação [não HA] Processo de recuperação [HA]
Falha no servidor de banco de dados Se o servidor de banco de dados estiver inoperante devido a alguma falha de hardware subjacente, as conexões ativas serão removidas e todas as transações em andamento serão anuladas. O Azure tenta reiniciar o servidor de banco de dados. Se tiver êxito, a recuperação do banco de dados será executada. Se a reinicialização falhar, a reinicialização do servidor de banco de dados será tentada em outro nó físico.

O tempo de recuperação (RTO) depende de vários fatores, incluindo a atividade no momento da falha, como transações grandes e a quantidade de recuperação a ser executada durante o processo de inicialização do servidor de banco de dados. O RPO é zero, pois nenhuma perda de dados é esperada para as transações confirmadas. Os aplicativos que usam os bancos de dados do MySQL precisam ser criados de forma que detectem e repitam as conexões com queda e as transações com falha. Quando o aplicativo tentar novamente, as conexões serão direcionadas para o servidor de banco de dados recém-criado.

Outras opções disponíveis incluem a restauração do backup. Você pode usar o PITR ou a restauração geográfica de uma região emparelhada.
PITR : RTO: Varia, RPO = 0sec
Restauração Geográfica: RTO: varia RPO <1 hora.

Você também pode usar a réplica de leitura como solução de DR. Você pode interromper a replicação, o que torna a réplica de leitura leitura-gravação (autônoma e, em seguida, redireciona o tráfego do aplicativo para esse banco de dados). O RTO na maioria dos casos é de poucos minutos e o RPO < de 1 h. O RTO e o RPO podem ser muito maiores em alguns casos, 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.		 Se forem detectadas falhas no servidor de banco de dados ou erros não recuperáveis, o servidor de banco de dados em espera será ativado, reduzindo o tempo de inatividade. Consulte a página de conceitos de HA para obter mais detalhes. Espera-se que o RTO seja de 60 a 120 segundos, com RPO = 0.

Nota:As opções para o processo de recuperação [não-HA] também são aplicáveis aqui.
Falha de armazenamento Os aplicativos não detectam impactos relacionados aos problemas de armazenamento, como uma falha de disco ou uma corrupção do bloco físico. À medida que os dados são armazenados em três cópias, a cópia dos dados é atendida pelo armazenamento sobrevivente. As corrupções de bloco são corrigidas automaticamente. Se uma cópia dos dados for perdida, uma nova cópia dos dados será criada automaticamente.

Em um cenário raro ou de pior caso, se todas as cópias estiverem corrompidas, podemos usar a restauração geográfica (região emparelhada). O RPO seria de <1 hora e o RTO variaria.

Você também pode usar a réplica de leitura como solução de DR, conforme detalhado acima.		 Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade].
Erros de usuário/lógicos A recuperação de erros do usuário, como tabelas removidas por acidente ou dados atualizados incorretamente, envolve a execução de uma PITR (recuperação pontual), que restaura e recupera os dados até o momento anterior da ocorrência do erro.

É possível recuperar um recurso de servidor flexível excluído dentro de cinco dias a partir do momento da exclusão do servidor. Para obter um guia detalhado sobre como restaurar um servidor excluído, [consulte as etapas documentadas] (../flexible-server/how-to-restore-dropped-server.md). Para proteger os recursos do servidor após a implantação contra exclusão acidental ou alterações inesperadas, os administradores podem usar bloqueios de gerenciamento.		 Esses erros de usuário não são protegidos com alta disponibilidade, pois todas as operações de usuário também são replicadas para o estado em espera. Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade]
Falha na zona de disponibilidade Embora seja um evento raro, se você quiser se recuperar de uma falha no nível da zona, poderá executar a restauração geográfica em uma região emparelhada. O RPO seria de <1 hora e o RTO variaria.

Você também pode usar a réplica de leitura como solução de DR criando a réplica em outra zona de disponibilidade. O RTO\RPO é como detalhado acima.		 Caso tenha habilitado a alta disponibilidade com redundância de zona, o servidor flexível executará o failover automático para o site em espera. Veja os conceitos de alta disponibilidade para obter mais detalhes. Espera-se que o RTO seja de 60 a 120 segundos, com RPO = 0.

Outras opções disponíveis incluem a restauração do backup. Você pode usar o PITR ou a restauração geográfica de uma região emparelhada.
PITR : RTO: Varia, RPO = 0 seg
Geo Restore : RTO: Varia, RPO <1 h

Nota:Se você tiver HA de mesma zona habilitada, as opções serão as mesmas do processo de recuperação [não-HA].
Falha de região Embora seja um evento raro, se você quiser se recuperar de uma falha no nível de região, poderá executar a recuperação do banco de dados criando um novo servidor usando o backup com redundância geográfica mais recente disponível na mesma assinatura para obter os dados mais recentes. Um novo servidor flexível é implantado na região selecionada. O tempo necessário para a restauração depende do backup anterior e do número de logs de transações a ser recuperados. Na maioria dos casos, o RPO seria de <1 hora e o RTO variaria. Para esse cenário, as opções são as mesmas do processo de recuperação [não relacionado à alta disponibilidade].

Requisitos e limitações

Residência dos Dados na Região

Por padrão, o servidor flexível do Banco de Dados do Azure para MySQL não move ou armazena dados de clientes para fora da região em que foi implantado. No entanto, os clientes podem, opcionalmente, optar por habilitar backups com redundância geográfica ou configurar a replicação entre regiões para armazenar dados em outra região.

Próximas etapas