Conceitos de alta disponibilidade no Banco de Dados do Azure para MySQL

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor único

Importante

O Banco de Dados do Azure para servidor único MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para o servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

O serviço do Banco de Dados do Azure para MySQL fornece um alto nível de disponibilidade garantido com o SLA (contrato de nível de serviço) com suporte financeiro de 99,99% de tempo de atividade. O Banco de Dados do Azure para MySQL fornece alta disponibilidade durante eventos planejados, como a operação de computação de escala iniciada pelo usuário, e também quando ocorrem eventos não planejados, como falhas de hardware subjacente, software ou rede. Ele pode se recuperar rapidamente das circunstâncias mais críticas, garantindo praticamente nenhum tempo de inatividade do aplicativo ao usar esse serviço.

O Banco de Dados do Azure para MySQL é adequado para a execução de banco de dados de missão crítica que exigem alto tempo de atividade. Baseado na arquitetura do Azure, o serviço tem recursos inerentes de alta disponibilidade, redundância e resiliência para reduzir o tempo de inatividade do banco de dados de interrupções planejadas e não planejadas, sem a necessidade de configurar outro componente adicional.

Componentes no Banco de Dados do Azure para MySQL

Componente Descrição
Servidor de Banco de dados do MySQL O Banco de Dados do Azure para MySQL fornece segurança, isolamento, proteções de recursos e capacidade de reinicialização rápida para servidores de banco de dados. Esses recursos facilitam operações como o dimensionamento e a operação de recuperação do servidor de banco de dados após uma interrupção ocorrer em 60-120 segundos, dependendo da atividade transacional no banco de dados.
Normalmente, as modificações nos servidores de dados ocorrem durante uma transação de um banco de dados. Todas as alterações de banco de dados são gravadas de forma síncrona na maneira de write-ahead logs (ib_log) no Armazenamento do Microsoft Azure, que está anexado ao servidor de banco de dados. Durante o processo de ponto de verificação do banco de dados, as páginas de dados da memória do servidor de banco de dados também são liberadas para o armazenamento.
Armazenamento Remoto Todos os arquivos de dados físicos e arquivos de log do MySQL são armazenados no Armazenamento do Azure, que é arquitetado para armazenar três cópias de dados em uma região para garantir a redundância, a disponibilidade e a confiabilidade dos dados. A camada de armazenamento também é independente do servidor de banco de dados. Ele pode ser desanexado de um servidor de banco de dados com falha e reanexado a um novo servidor de banco de dados dentro de 60 segundos. Além disso, o Armazenamento do Microsoft Azure monitora continuamente as falhas de armazenamento. Se uma corrupção de bloco for detectada, ela será automaticamente corrigida instanciando uma nova cópia de armazenamento.
Gateway O gateway atua como um proxy de banco de dados roteando todas as conexões de cliente para o servidor de banco de dados.

Mitigação de tempo de inatividade planejada

O Banco de Dados do Azure para MySQL é projetado para fornecer alta disponibilidade durante operações de tempo de inatividade planejadas.

view of Elastic Scaling in Azure MySQL

Estes são alguns cenários de manutenção planejada:

Cenário Descrição
Dimensionar/reduzir verticalmente a computação Quando o usuário executa a operação de dimensionar/reduzir verticalmente, um novo servidor de banco de dados é provisionado usando a configuração de computação dimensionada. No servidor de banco de dados antigo, 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 desligadas. Então, o armazenamento é desanexado do servidor de banco de dados antigo e anexado ao servidor de banco de dados novo. Quando o aplicativo cliente tenta se reconectar ou tenta fazer uma nova conexão, o gateway direciona a solicitação de conexão para o servidor de banco de dados novo.
Dimensionamento do armazenamento Dimensionar o armazenamento é uma operação online e não interrompe o servidor de banco de dados.
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. Para saber mais, confira a documentação e também verifique o portal.
Atualizações secundárias de versão O 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. Durante a manutenção planejada, pode haver reinicializações ou failovers do servidor de banco de dados, o que pode levar a uma breve indisponibilidade dos servidores de banco de dados para os usuários finais. Os servidores do Banco de Dados do Azure para MySQL estão em execução em contêineres. Portanto, as reinicializações do servidor de banco de dados normalmente são rápidas, esperadas para ser concluídas em 60 a 120 segundos. Todo o evento de manutenção planejada, incluindo as reinicializações de cada servidor, é cuidadosamente monitorado pela equipe de engenharia. O tempo de failover do servidor depende do tempo de recuperação do banco de dados, o que poderá fazer com que o banco de dados fique online mais tempo se você tiver uma atividade transacional pesada no servidor no momento do failover. Para evitar um tempo de reinicialização mais longo, recomendamos evitar todas as transações de execução prolongada (cargas em massa) durante os eventos de manutenção planejada. Para saber mais, consulte a documentaçãoe também verifique o portal.

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

O tempo de inatividade não planejado pode 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, um novo servidor de banco de dados será provisionado automaticamente em 60-120 segundos. O armazenamento remoto é anexado automaticamente ao novo servidor de banco de dados. O mecanismo do MySQL executa a operação de recuperação usando WAL e arquivos de banco de dados e abre o servidor de banco de dados para permitir que os clientes se conectem. As transações não confirmadas são perdidas e precisam ser repetidas pelo aplicativo. Embora não seja possível evitar um tempo de inatividade não planejado, o banco de dados do Azure para MySQL 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.

view of High Availability in Azure MySQL

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

Aqui estão alguns cenários de falha e como o Banco de Dados do Azure para MySQL se recupera automaticamente:

Cenário Recuperação automática
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. Um novo servidor de banco de dados é implantado automaticamente, e o armazenamento remoto é anexado ao novo servidor de banco de dado. Depois que a recuperação do banco de dados for concluída, os clientes podem se conectar ao novo servidor de banco de dados por meio do gateway.

Os aplicativos que usam os bancos de dados do MySQL precisam ser criados de forma que detectem e repitam as conexões e as transações com falha. Quando o aplicativo repete a operação, o gateway redireciona a conexão de forma transparente para o servidor de banco de dados recém-criado.
Falha de armazenamento Os aplicativos não detectam o impacto de problemas relacionados ao armazenamento, como uma falha de disco ou um dano a bloco físico. Como os dados são armazenados em três cópias, a cópia dos dados é atendida pelo armazenamento remanescente. 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.

Aqui estão alguns cenários de falha que necessitam da ação do usuário para serem recuperados:

Cenário Plano de recuperação
Falha de região A falha de uma região é um evento raro. No entanto, se precisar de proteção contra uma falha de região, você poderá configurar uma ou mais réplicas de leitura em outras regiões para DR (recuperação de desastre). (Para mais detalhes, confira este artigo, sobre como criar e gerenciar réplicas de leitura). No caso de uma falha em nível de região, você pode promover manualmente a réplica de leitura configurada na outra região para ser seu servidor de banco de dados de produção.
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.

Se você quiser restaurar apenas um subconjunto de bancos de dados ou tabelas específicas, em vez de todos os bancos de dados no servidor, poderá restaurar o servidor de banco de dados em uma nova instância, exportar a(s) tabela(s) por meio de mysqldump e usar restore para restaurar essas tabelas em seu banco de dados.

Resumo

O Banco de Dados do Azure para MySQL fornece capacidade de reinicialização rápida de servidores de banco de dados, armazenamento redundante e roteamento eficiente do gateway. Para proteção de dados adicional, você pode configurar os backups para serem replicados geograficamente e também implantar uma ou mais réplicas de leitura em outras regiões. Com os recursos inerentes de alta disponibilidade, o Banco de Dados do Azure para MySQL protege seus bancos de dados contra as interrupções mais comuns e oferece um SLA de tempo de atividade, com suporte financeiro potencial do setor, de 99,99%. Todos esses recursos de disponibilidade e confiabilidade permitem que o Azure seja a plataforma ideal para executar aplicativos críticos.

Próximas etapas