Compare 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 tempos de recuperação diferentes ou risco de perda de dados.
Exemplos de tempo de inatividade
Seguem-se alguns exemplos de cenários de tempo de inatividade planeado e não planeado.
Cenários de tempo de inatividade planejados
Os dois cenários de tempo de inatividade planejado mais comuns são o dimensionamento de computação iniciado pelo usuário e a manutenção agendada executada pelo Azure.
Quando você executa uma operação de dimensionamento de 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 transações não confirmadas e, em seguida, o servidor existente é desligado. Neste 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 cliente.
Novos recursos e correções de bugs acontecem automaticamente como parte da manutenção planejada do serviço. Patches de atualização de versões secundárias também são aplicados durante a manutenção planejada, incorrendo em alguns segundos de tempo de inatividade. Você pode agendar essas atividades conforme descrito na seção a seguir, "Tempo de inatividade programado e janelas de manutenção".
Período de indisponibilidade não planeado
O banco de dados pode cair inesperadamente por vários motivos, como:
- Falha de hardware do banco de dados.
- Falha na unidade de armazenamento.
- Erros do aplicativo ou do usuário (por exemplo, queda acidental de tabelas).
- Zona de disponibilidade & falhas de região.
Se a alta disponibilidade (HA) não estiver habilitada, o Azure tentará a recuperação, como copiar dados perdidos, reiniciar o servidor ou até mesmo iniciar o servidor em outro nó físico. Habilitar o HA pode reduzir ou até mesmo eliminar esses tipos de tempo de inatividade, conforme discutido na seção a seguir.
Elevada 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 comprometidos e evitar que o banco de dados seja um único ponto de falha. Quando você configurou o HA, o servidor flexível do MySQL provisiona e gerencia automaticamente uma réplica em espera.
Existem dois tipos de alta disponibilidade com diferentes tolerâncias a falhas e compensações de latência: redundante de zona e mesma zona.
HA com redundância de zona
A HA redundante 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 se uma zona inteira ficar inativa. 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 para seu aplicativo. Além disso, o uso de uma configuração HA redundante de zona também requer que os aplicativos cliente de banco de dados sejam redundantes de zona para garantir que as operações gerais continuem.
HA da mesma zona
Em uma configuração de HA de 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 HA de mesma zona, se a zona de disponibilidade diminuir, o tempo de inatividade resultante será maior à medida que o servidor flexível MySQL se recupera.
Ao contrário da HA com redundância de zona, a HA de 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.
Cópia de segurança e restauro
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 em armazenamento redundante 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, no caso de falha ou corrupção de dados (por exemplo, um bug de aplicativo ou erro de desenvolvimento).
Existem dois tipos de backups. Com backups automatizados , o servidor flexível MySQL tira instantâneos de arquivos de dados de banco de dados, bem como os logs de transações associados. Os backups de snapshot automatizados ocorrem uma vez por dia e os backups de log 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 backups sob demanda , você pode criar um backup de banco de dados a qualquer momento. Com ambos os tipos de backups, os arquivos de backup são retidos por sete dias por padrão. No entanto, com base em suas necessidades de negócios, você pode configurar o valor do período de retenção de um a 35 dias.
Você pode reter 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 além do Banco de Dados do Azure automatizado para backups MySQL. Os backups de longo prazo podem ser feitos em um cronograma controlado pelo cliente ou sob demanda. Os backups são armazenados em contas de armazenamento gerenciado do Backup do Azure, em domínios de segurança e falhas separados.
Além de fazer 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 armazenamento localmente redundante (mesmo datacenter, mesma zona), os arquivos de backup são armazenados no mesmo datacenter que o banco de dados. Essa opção fornece onze 9s (99,999999999%) de durabilidade para objetos de backup ao longo de um ano. Por padrão, servidores sem HA ou com HA de mesma zona usam armazenamento redundante localmente.
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. Esta opção proporciona doze 9s (99,9999999999%) de durabilidade ao longo de um determinado ano. O armazenamento com redundância de zona é importante para 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. Esta opção prevê dezasseis 9s (99,9999999999999%) de durabilidade ao longo de um determinado ano. O armazenamento com redundância geográfica só é suportado em regiões emparelhadas do Azure.
Nota: 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 ter um backup, você pode restaurar o backup para 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 programado 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 estão programadas para ocorrer pelo menos a cada 30 dias, mas patches de segurança críticos às vezes são aplicados dentro de sete dias ou menos.
Você pode escolher uma agenda gerenciada pelo sistema ou definir uma agenda personalizada para cada servidor flexível do MySQL em sua assinatura do Azure.
Você pode receber notificações de manutenção programada de várias maneiras. As notificações podem ser:
- Enviado por email para um endereço específico ou função do Azure Resource Manager.
- Enviado por mensagem de texto (SMS).
- Enviado por push como uma notificação de aplicativo do Azure.
- Entregue via mensagem de voz.
Janelas de manutenção personalizadas
Por padrão, com uma programação gerenciada pelo sistema, o sistema escolhe uma janela de uma hora entre 23h e 7h no fuso horário da região flexível do servidor MySQL. Com uma programação personalizada, 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 nulo para servidores HA (visualização pública)
Os servidores habilitados para HA se beneficiam da manutenção com tempo de inatividade quase nulo, um novo recurso que reduz substancialmente o tempo de inatividade da manutenção. O tempo de inatividade esperado é entre 40 a 60 segundos. A manutenção com tempo de inatividade quase nulo é crucial para aplicativos com requisitos de disponibilidade muito altos, exigindo interrupções mínimas na conectividade do banco de dados.
Reprogramar manutenção (visualização pública)
Você pode reagendar a manutenção ao usar as camadas de serviço de uso geral ou críticas para os negócios. Na seção de manutenção do portal do Azure, você pode reagendar a próxima manutenção agendada para outra data e hora. Você também pode iniciar a manutenção sob demanda selecionando Reagendar para Agora.