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 servidor único do Banco de Dados do Azure para 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 servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

O serviço Banco de Dados do Azure para MySQL fornece um alto nível de disponibilidade garantido com o SLA (Service Level Agreement, 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 operação de computação em escala iniciada pelo usuário, e também quando ocorrem eventos não planejados, como falhas subjacentes de hardware, software ou rede. O Banco de Dados do Azure para MySQL 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 executar bancos de dados de missão crítica que exigem alto tempo de atividade. Criado com base 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 exigir que você configure componentes adicionais.

Componentes no Banco de Dados do Azure para MySQL

Componente Descrição
Servidor de banco de dados MySQL O Banco de Dados do Azure para MySQL fornece segurança, isolamento, proteção de recursos e capacidade de reinicialização rápida para servidores de banco de dados. Esses recursos facilitam operações como dimensionamento e operação de recuperação do servidor de banco de dados após uma interrupção para acontecer em 60-120 segundos, dependendo da atividade transacional no banco de dados.
As modificações de dados no servidor de banco de dados normalmente ocorrem no contexto de uma transação de banco de dados. Todas as alterações de banco de dados são registradas de forma síncrona na forma de logs de gravação antecipada (ib_log) no Armazenamento do Azure – que é 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 redundância, disponibilidade e confiabilidade de 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 em 60 segundos. Além disso, o Armazenamento do Azure monitoriza continuamente quaisquer falhas de armazenamento. Se uma corrupção de bloco for detetada, ela será corrigida automaticamente instanciando uma nova cópia de armazenamento.
Porta de entrada O Gateway atua como um proxy de banco de dados, roteia todas as conexões de cliente para o servidor de banco de dados.

Redução do tempo de inatividade planejado

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

view of Elastic Scaling in Azure MySQL

Aqui estão alguns cenários de manutenção planejada:

Cenário Descrição
Dimensionamento de computação para cima/para baixo Quando o usuário executa a operação de expansão/redução de escala de computação, 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 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, ele é desligado. O armazenamento é então desanexado do servidor de banco de dados antigo e anexado ao novo servidor de banco de dados. Quando o aplicativo cliente tenta novamente a conexão ou tenta fazer uma nova conexão, o Gateway direciona a solicitação de conexão para o novo servidor de banco de dados.
Ampliando o armazenamento A expansão do armazenamento é uma operação online e não interrompe o servidor de banco de dados.
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. Para obter mais informações, consulte a documentação e também verifique seu portal.
Atualizações de versões secundárias O Banco de Dados do Azure para MySQL corre 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. O Banco de Dados do Azure para servidores MySQL está sendo executado em contêineres, portanto, as reinicializações do servidor de banco de dados geralmente são rápidas, esperando-se que sejam concluídas normalmente em 60 a 120 segundos. Todo o evento de manutenção planejado, incluindo cada reinicialização do 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 pode fazer com que o banco de dados fique online por mais tempo se você tiver uma atividade transacional pesada no servidor no momento do failover. Para evitar um tempo de reinicialização mais longo, recomenda-se evitar transações de longa duração (cargas em massa) durante eventos de manutenção planejados. Para obter mais informações, consulte a documentação e também verifique seu portal.

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

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 cair inesperadamente, um novo servidor de banco de dados será provisionado automaticamente em 60 a 120 segundos. O armazenamento remoto é automaticamente anexado ao novo servidor de bases de dados. O mecanismo 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 um tempo de inatividade não planejado não possa ser evitado, o Banco de Dados do Azure para MySQL 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.

view of High Availability in Azure MySQL

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

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 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. Um novo servidor de banco de dados é implantado automaticamente e o armazenamento remoto de dados é anexado ao novo servidor de banco de dados. Após a conclusão da recuperação do banco de dados, os clientes podem se conectar ao novo servidor de banco de dados por meio do Gateway.

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, o Gateway redireciona de forma transparente a conexão para o servidor de banco de dados recém-criado.
Falha de armazenamento Os aplicativos não veem nenhum impacto para quaisquer problemas relacionados ao armazenamento, como uma falha de disco ou uma corrupção de bloco físico. Como os dados são armazenados em 3 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.

Aqui estão alguns cenários de falha que exigem ação do usuário para recuperar:

Cenário Plano de recuperação
Falha de região O fracasso de uma região é um evento raro. No entanto, se precisar de proteção contra uma falha de região, você pode configurar uma ou mais réplicas de leitura em outras regiões para recuperação de desastres (DR). (Consulte este artigo sobre como criar e gerenciar réplicas de leitura para obter detalhes). No caso de uma falha no nível da 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 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.

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 de banco de dados, poderá restaurar o servidor de banco de dados em uma nova instância, exportar a(s) tabela(s) via 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 obter proteção de dados adicional, você pode configurar backups para serem replicados geograficamente e também implantar uma ou mais réplicas de leitura em outras regiões. Com recursos inerentes de alta disponibilidade, o Banco de Dados do Azure para MySQL protege seus bancos de dados contra interrupções mais comuns e oferece um SLA de 99,99% de tempo de atividade líder do setor. Todos esses recursos de disponibilidade e confiabilidade permitem que o Azure seja a plataforma ideal para executar seus aplicativos de missão crítica.

Próximos passos