Visão geral da continuidade de negócios com o 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 abordam diferentes níveis de proteção contra falhas com diferentes tempos de recuperação e exposições à perda de dados. Ao arquitetar seu aplicativo para proteger contra falhas, você deve considerar o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para cada aplicativo. RTO é a tolerância de tempo de inatividade e 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.

Funcionalidade Descrição Restrições
Backup e recuperação O serviço realiza automaticamente backups diários de seus arquivos de banco de dados e faz backup contínuo de logs de transações. Os backups podem ser retidos por qualquer período entre 1 a 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 obter mais detalhes. Os dados de backup permanecem na região
Backup redundante local Os backups de serviço são armazenados de forma automática e segura em um armazenamento redundante local dentro de 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 com redundância local oferece pelo menos 99,999999999% (11 noves) de durabilidade dos objetos durante um determinado ano. Consulte Conceitos - Backup e restauração para obter mais detalhes. Aplicável em todas as regiões
Backup com redundância geográfica Os backups de serviço podem ser configurados como redundantes geograficamente 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 emparelhada da região ™primária para fornecer resiliência regional. O armazenamento de backup com redundância geográfica oferece pelo menos 99,9999999999999% (16 noves) de durabilidade dos objetos durante um determinado ano. Consulte Conceitos - Backup e restauração para obter mais detalhes. Disponível em todas as regiões emparelhadas do Azure
Alta disponibilidade redundante 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 dentro de 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 principal são replicados de forma síncrona com a réplica de espera. Durante qualquer evento de tempo de inatividade, é feita automaticamente a ativação pós-falha do servidor de bases de dados para a réplica de espera. Consulte Conceitos - Alta disponibilidade para obter mais detalhes. Suportado em níveis de computação de uso geral e críticos para os negócios. Disponível apenas em regiões onde várias zonas estão disponíveis.
Compartilhamentos de arquivos premium Os arquivos de banco de dados são armazenados em compartilhamentos de arquivos premium do Azure 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

Redução do tempo de inatividade planejado

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 você executa 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 podem ser concluídos, as conexões do cliente são drenadas, todas as transações não confirmadas são canceladas e, em seguida, são encerradas. O armazenamento é então anexado ao novo servidor e o banco de dados é iniciado, que executa a recuperação, se necessário, antes de aceitar conexões de cliente.
Nova implantação de software (Azure) A implementação de novos recursos ou correções de bugs acontecem automaticamente como parte da manutenção planejada do serviço, e você pode agendar quando essas atividades acontecerão. Para obter mais informações, consulte a documentação e também verifique seu portal
Atualizações de versões secundárias (Azure) O Banco de Dados do Azure para servidor flexível MySQL aplica automaticamente patches aos 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 incorreria em um curto tempo de inatividade em termos de segundos, e o servidor de banco de dados seria reiniciado automaticamente com a nova versão secundária. Para obter mais informações, consulte a documentação e também verifique seu portal.

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

Mitigação de tempos de inatividade não planeados

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 cair inesperadamente, se configurado com alta disponibilidade [HA], a réplica em espera será ativada. Caso contrário, um novo servidor de banco de dados será provisionado automaticamente. Embora um tempo de inatividade não planejado não possa ser evitado, o servidor flexível reduz o tempo de inatividade executando 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ços

Aqui estão alguns cenários de falha não planejada e o processo de recuperação:

Cenário Processo de recuperação [não-HA] Processo de recuperação [HA]
Falha do servidor de banco de dados Se o servidor de banco de dados estiver inativo devido a alguma falha de hardware subjacente, as conexões ativas serão descartadas e todas as transações de bordo serão anuladas. O Azure tenta reiniciar o servidor de banco de dados. Se isso for bem-sucedido, 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 uma grande transação 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 MySQL precisam ser construídos de forma a detetar e repetir conexões perdidas e transações com falha. Quando o aplicativo é iniciado, as conexões são direcionadas para o servidor de banco de dados recém-criado.

Outras opções disponíveis são restauradas a partir do backup. Você pode usar PITR ou Geo restore da região emparelhada.
PITR : RTO: Varia, RPO=0seg
Geo Restore : RTO: Varia RPO <1 h.

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, redirecionar o tráfego do aplicativo para esse banco de dados). O RTO na maioria dos casos é de poucos minutos e RPO < de 1 h. 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.		 Se forem detetadas falhas no servidor de banco de dados ou erros não recuperáveis, o servidor de banco de dados em espera será ativado, reduzindo assim o tempo de inatividade. Consulte a página de conceitos de HA para obter mais detalhes. Espera-se que o RTO seja de 60-120 s, com RPO=0.

Nota: As opções para o processo de recuperação [non-HA] também são aplicáveis aqui.
Falha de armazenamento Os aplicativos não veem nenhum impacto para problemas relacionados ao armazenamento, como uma falha de disco ou uma corrupção de bloco físico. Como os dados são armazenados em três cópias, a cópia dos dados é servida 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 no pior dos cenários, se todas as cópias estiverem corrompidas, podemos usar a restauração a partir da restauração geográfica (região emparelhada). O RPO seria < de 1 h 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 que para o processo de recuperação [não-HA] .
Erros lógicos/do utilizador A recuperação de erros do usuário, como tabelas descartadas acidentalmente ou dados atualizados incorretamente, envolve a execução de uma recuperação point-in-time (PITR), restaurando e recuperando os dados até o momento imediatamente anterior ao erro ter ocorrido.

Você pode 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 do usuário não são protegidos com alta disponibilidade, pois todas as operações do usuário também são replicadas para o modo de espera. Para esse cenário, as opções são as mesmas do processo de recuperação [non-HA]
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 de uma região emparelhada. O RPO seria <de 1 h e o RTO variaria.

Você também pode usar a réplica de leitura como solução de DR criando réplica em outra zona de disponibilidade. RTO\RPO é como o que é detalhado acima.		 Se você tiver habilitado a HA redundante de zona, o servidor flexível executará failover automático para o site em espera. Consulte os conceitos de HA para obter mais detalhes. Espera-se que o RTO seja de 60-120 s, com RPO=0.

Outras opções disponíveis são restauradas a partir do backup. Você pode usar PITR ou Geo restore da 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 em 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 restaurar depende do backup anterior e do número de logs de transações a serem recuperados. O RPO, na maioria dos casos, seria <de 1 h e o RTO variaria. Para esse cenário, as opções são as mesmas que para o processo de recuperação [não-HA] .

Requisitos e Limitações

Residência de dados da região

Por padrão, o servidor flexível do 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 configurar a replicação entre regiões para armazenar dados em outra região.

Próximos passos