Comparar as opções de continuidade de negócios e recuperação de desastres
O Banco de Dados do Azure para MySQL - Servidor Flexível fornece recursos de continuidade de negócios para proteger seu banco de dados em caso de interrupções planejadas ou não planejadas. Para lidar com diferentes tipos de interrupções, você pode aplicar níveis variados de proteção contra falhas com diferentes tempos de recuperação ou risco de perda de dados.
Exemplos de tempo de inatividade
A seguir, alguns exemplos de cenários de tempo de inatividade planejado e não planejado.
Cenários de tempo de inatividade planejado
Os dois cenários mais comuns de tempo de inatividade planejado são a escala da computação iniciado pelo usuário e a manutenção programada realizada pelo Azure.
Quando você executa uma operação de escala da computação, o Azure provisiona um novo servidor flexível MySQL com a configuração de computação solicitada. O servidor existente permite que os pontos de verificação ativos sejam concluídos, drena as conexões existentes, cancela as transações não confirmadas e, em seguida, o servidor existente é desligado. Nesse ponto, o Azure anexa o armazenamento do servidor existente ao novo servidor e inicia o banco de dados. Em seguida, o banco de dados executa qualquer recuperação necessária antes de continuar a aceitar conexões de clientes.
Novos recursos e correções de bugs ocorrem automaticamente como parte da manutenção planejada do serviço. Os patches de atualização de versões menores também são aplicados durante a manutenção planejada, incorrendo em alguns segundos de tempo de inatividade. É possível agendar essas atividades conforme descrito na seção a seguir, "Tempo de inatividade agendado e janelas de manutenção."
Tempo de inatividade não planejado
O banco de dados pode ficar inativo inesperadamente por vários motivos, como:
- Falha no hardware do banco de dados.
- Falha na unidade de armazenamento.
- Erros do aplicativo ou do usuário (por exemplo, eliminação acidental de tabelas).
- Falhas na zona de disponibilidade e na região.
Se a alta disponibilidade (HA) não estiver habilitada, o Azure tentará executar a recuperação, como copiar dados perdidos, reiniciar o servidor ou até mesmo iniciar o servidor em outro nó físico. Habilitar a HA pode reduzir ou até eliminar esses tipos de tempo de inatividade, conforme discutido na seção a seguir.
Alta disponibilidade
O Banco de Dados do Azure para MySQL - Servidor Flexível fornece HA com failover automático, que fornece uma solução projetada para nunca perder dados confirmados e para evitar que o banco de dados seja um ponto único de falha. Quando você tiver configurado a HA, o servidor flexível MySQL provisionará e gerenciará automaticamente uma réplica em espera.
Há dois tipos de alta disponibilidade com diferentes tolerâncias a falhas e compensações de latência: com redundância de zona e mesma zona.
HA com redundância de zona
A HA com redundância de zona fornece redundância em várias zonas de disponibilidade, oferecendo o mais alto nível de disponibilidade com a capacidade de recuperação mesmo que uma zona inteira fique inoperante. O uso de uma configuração de HA com redundância de zona introduz latência adicional, portanto, certifique-se de determinar se isso é aceitável no seu aplicativo. Além disso, o uso de uma configuração de HA com redundância de zona também exige que os aplicativos clientes do banco de dados sejam com redundância de zona para garantir que as operações gerais continuem.
HA da mesma zona
Em uma configuração de HA na mesma zona, os servidores primário e em espera residem na mesma zona de disponibilidade, o que minimiza a latência. Embora a baixa latência possa ser necessária em alguns casos de uso, com uma configuração de HA na mesma zona, se a zona de disponibilidade ficar inativa, o tempo de inatividade resultante será maior à medida que o servidor flexível MySQL se recuperar.
Ao contrário da HA com redundância de zona, a HA na mesma zona está disponível em todas as regiões que dão suporte ao Banco de Dados do Azure para MySQL - Servidor Flexível.
Backup e restauração
Os backups de servidor são um componente crucial de qualquer estratégia de continuidade de negócios. O Banco de Dados do Azure para MySQL - Servidor Flexível cria automaticamente backups armazenados com segurança no armazenamento com redundância local na região que hospeda o banco de dados. Você pode usar esses backups para restaurar o banco de dados para um ponto específico no tempo, em caso de falha ou corrupção de dados (por exemplo, um bug de aplicativo ou erro de desenvolvimento).
Há dois tipos de backups. Com os backups automatizados, o servidor flexível MySQL tira instantâneos dos arquivos de dados do banco de dados, bem como dos registros de transações associados. Os backups automatizados de instantâneos ocorrem uma vez por dia e os backups de registros de transações ocorrem a cada cinco minutos. Se um backup falhar, o servidor tentará novamente a cada 20 minutos até que o backup seja bem-sucedido.
Com os backups sob demanda, é possível criar um backup do banco de dados a qualquer momento. Em ambos os tipos de backups, os arquivos de backup são mantidos por sete dias por padrão. Entretanto, com base em suas necessidades comerciais, é possível configurar o valor do período de retenção de 1 a 35 dias.
Você pode reter os backups por até 10 anos usando o recurso de retenção de longo prazo, atualmente em visualização pública. A solução de backup de longo prazo pode ser usada separadamente ou em adição aos backups automatizados do Banco de Dados do Azure para MySQL. Os backups de longo prazo podem ser feitos em um agendamento controlado pelo cliente ou sob demanda. Os backups são armazenados em contas de armazenamento gerenciadas pelo Backup do Azure, em domínios separados de segurança e falha.
Além de fazer o backup do banco de dados, você pode exportar arquivos de backup para o Armazenamento de Blobs do Azure, que pode ser usado para migrações, recuperação de dados ou arquivamento. As exportações sob demanda estão atualmente em visualização pública e disponíveis apenas em regiões de nuvem pública.
Para armazenar os arquivos de backup, você pode selecionar entre várias opções de armazenamento:
Com o armazenamento com redundância local (mesmo datacenter, mesma zona), os arquivos de backup são armazenados no mesmo datacenter que o banco de dados. Essa opção oferece onze 9s (99,999999999%) de durabilidade para objetos de backup ao longo de um ano. Por padrão, os servidores sem HA ou com HA na mesma zona usam o armazenamento com redundância local.
Com o armazenamento de backup com redundância de zona (zona diferente, mesma região), os arquivos de backup são armazenados na zona de disponibilidade do servidor e replicados para outra zona de disponibilidade na mesma região. Essa opção oferece doze 9s (99,9999999999%) de durabilidade em um determinado ano. O armazenamento com redundância de zona é importante para a HA com redundância de zona e é necessário se os dados precisarem permanecer em uma única região.
Com o armazenamento de backup com redundância geográfica (regiões diferentes), os arquivos de backup são armazenados na região do servidor e, em seguida, replicados para outra região emparelhada geograficamente. Essa opção oferece dezesseis 9s (99,99999999999999%) de durabilidade em um determinado ano. Só há suporte para armazenamento com redundância geográfica nas regiões emparelhadas do Azure.
Observação: Com o Banco de Dados do Azure para MySQL - Servidor Flexível, o espaço de backup de até 100% do espaço de armazenamento provisionado está disponível sem custo adicional. O armazenamento adicional é cobrado em GB por mês. Para obter mais informações, consulte a documentação de preços.
Depois de fazer um backup, você pode restaurá-lo em um novo servidor flexível MySQL. Você pode selecionar o backup de três maneiras: selecionar manualmente um backup completo, selecionar automaticamente o ponto de restauração mais recente ou selecionar automaticamente o ponto de restauração mais rápido. Se você tiver backups com redundância geográfica, também poderá restaurar para a região emparelhada (a região cruzada).
Tempo de inatividade agendado e janelas de manutenção
A manutenção periódica é necessária para manter o servidor gerenciado estável, seguro e atualizado. Durante as janelas de manutenção, o serviço recebe implantações de novos recursos, atualizações e patches. Normalmente, as janelas de manutenção são agendadas para ocorrer pelo menos a cada 30 dias, mas os patches de segurança críticos são aplicados, às vezes, dentro de sete dias ou menos.
Você pode escolher uma programação gerenciada pelo sistema ou definir um agendamento personalizado para cada servidor flexível MySQL em sua assinatura do Azure.
Você pode receber as notificações de manutenção agendadas de várias maneiras. As notificações podem ser:
- Enviadas por email para um endereço específico ou função do Azure Resource Manager.
- Enviadas por mensagem de texto (SMS).
- Enviadas como uma notificação de aplicativo do Azure.
- Entregues por mensagem de voz.
Janelas de manutenção personalizadas
Por padrão, com um agendamento gerenciado pelo sistema, o sistema escolhe uma janela de uma hora entre 23h e 7h no fuso horário da região do servidor flexível MySQL. Com um agendamento personalizado, você pode especificar sua janela de manutenção para o servidor escolhendo o dia da semana e um horário de uma hora.
Manutenção com tempo de inatividade quase zero para servidores HA (visualização pública)
Os servidores habilitados para HA se beneficiam do tempo de inatividade de manutenção quase zero, um novo recurso, que reduz substancialmente o tempo de inatividade da manutenção. O tempo de inatividade esperado é de 40 a 60 segundos. A manutenção com tempo de inatividade quase zero é crucial para aplicativos com requisitos de disponibilidade muito altos, exigindo interrupções mínimas na conectividade do banco de dados.
Reagendamento da manutenção (visualização pública)
Você pode reagendar a manutenção ao usar as camadas de serviço de Uso Geral ou Comercialmente Crítico. Na seção de manutenção do portal do Azure, é possível reagendar a próxima manutenção agendada para outra data e hora. Também é possível iniciar a manutenção sob demanda selecionando Reagendar para Agora.