Visão geral da continuidade dos negócios com o Banco de Dados do Azure para MySQL – Servidor Flexível
O Banco de Dados do Azure para MySQL servidor flexível permite 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 MySQL servidor flexível 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 ponto no tempo dentro do período de retenção do backup. O tempo de recuperação depende do tamanho dos dados para restaurar + o tempo para executar a recuperação de log. Consulte Backup e restauração no Banco de Dados do Azure para MySQL – Servidor Flexível para obter 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 Backup e restauração no Banco de Dados do Azure para MySQL – Servidor Flexível para obter mais detalhes. | Aplicável em todas as regiões |
| Backup com redundância de zona | A partir de meados de dezembro de 2024, os backups de serviço poderão ser configurados como redundantes de zona no momento da criação. Habilitar a redundância de zona replicará sua conta de armazenamento de forma síncrona em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é um local físico separado com energia, resfriamento e rede independentes. O ZRS oferece durabilidade para recursos de armazenamento de, pelo menos, 99,9999999999% (doze noves) ao ano. Essa configuração habilitará a recuperação perfeita durante as interrupções zonais. | Haverá suporte apenas na camada de computação Comercialmente Crítica até meados de dezembro de 2024. Disponível apenas em regiões em que há várias zonas disponíveis |
| 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 Backup e restauração no Banco de Dados do Azure para MySQL – Servidor Flexível para obter 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 da zona de redundância protege contra falhas no nível da zona e também ajuda a reduzir o tempo de inatividade do aplicativo durante eventos 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 de alta disponibilidade no Banco de Dados do Azure para MySQL – Servidor Flexível para obter mais informações. | 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 Banco de Dados do Azure para MySQL servidor flexível 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 de alta disponibilidade no Banco de Dados do Azure para MySQL – Servidor Flexível para obter mais informações.
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, haverá uma tentativa de reiniciar o servidor de banco de dados em outro nó físico. O RTO (tempo de recuperação) depende de vários fatores, incluindo a atividade no momento da falha, como transação grande e a quantidade de recuperação a ser executada durante o processo de inicialização do servidor de banco de dados. O RPO será zero, pois não são esperadas perdas de dados 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 = 0 segundo 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 que torna a leitura-gravação da réplica de leitura (autônoma e, em seguida, redireciona o tráfego do aplicativo para esse banco de dados). Na maioria dos casos, o RTO será de alguns minutos e o RPO <, 1 hora. 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 detectados erros não recuperáveis ou falhas no servidor de banco de dados, o servidor de banco de dados em espera será ativado, reduzindo assim o tempo de inatividade. Consulte a página de conceitos de alta disponibilidade (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 relacionado à HA] também se aplicam 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 recursos do servidor contra a exclusão acidental ou alterações inesperadas, após as implantações, 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. Consulte Conceitos de alta disponibilidade no Banco de Dados do Azure para MySQL – Servidor Flexível para obter mais informações. 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 segundo Restauração Geográfica: RTO: varia, RPO <1 hora Observação: se você tiver a alta disponibilidade na mesma zona habilitada, as opções serão as mesmas do processo de recuperação [não relacionado à 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 Banco de Dados do Azure para MySQL servidor flexível não move nem armazena dados do cliente para fora da região em que está implantado. No entanto, os clientes podem optar por habilitar backups com redundância geográfica ou configurar a replicação entre regiões para armazenar dados em outra região.