Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Banco de Dados do Azure para Servidor Flexível MySQL permite configurar a alta disponibilidade com failover automático. Essa solução garante que as falhas nunca causem perda de dados confirmados e que o banco de dados não seja um único ponto de falha em sua arquitetura de software. Quando você configura a alta disponibilidade, o Flexible Server provisiona e gerencia automaticamente uma réplica em espera. Você paga pela computação e armazenamento provisionados para as réplicas primária e secundária. Dois modelos de arquitetura de alta disponibilidade estão disponíveis:
Alta disponibilidade com redundância de zona. Essa opção fornece isolamento completo e redundância de infraestrutura em várias zonas de disponibilidade. Ele oferece o mais alto nível de disponibilidade, mas exige que você configure a redundância de aplicativos entre zonas. Escolha HA com redundância de zona quando quiser se proteger contra qualquer falha de infraestrutura na zona de disponibilidade e quando a latência na zona de disponibilidade for aceitável. Você pode habilitar HA com redundância de zona somente quando criar o servidor. A HA com redundância de zona está disponível em um subconjunto de regiões do Azure onde a região oferece suporte a várias zonas de disponibilidade e compartilhamentos de arquivos Premium com redundância de zona estão disponíveis.
Alta redundância local de disponibilidade. Essa opção fornece redundância de infraestrutura com menor latência de rede porque os servidores primário e em espera estão na mesma zona de disponibilidade. Ele oferece alta disponibilidade sem a necessidade de configurar redundância de aplicativos entre zonas. Escolha HA redundante local quando quiser atingir o mais alto nível de disponibilidade em uma única zona de disponibilidade com a menor latência de rede. A HA com redundância local está disponível em todas as regiões do Azure onde você pode usar o Banco de Dados do Azure para o Servidor Flexível MySQL.
Arquitetura de alta disponibilidade (HA) com redundância de zona
Quando você implanta um servidor com alta disponibilidade com redundância de zona, o Azure cria dois servidores:
- Um servidor primário em uma zona de disponibilidade.
- Um servidor de réplica em espera em outra zona de disponibilidade da mesma região do Azure. O servidor de réplica em espera tem a mesma configuração que o servidor primário, incluindo a camada de computação, o tamanho da computação, o tamanho do armazenamento e a configuração da rede.
Você pode escolher a zona de disponibilidade para o servidor primário e a réplica em espera. Colocar os servidores de banco de dados em espera e os aplicativos em espera na mesma zona reduz a latência. Ele também ajuda você a se preparar para situações de recuperação de desastres e cenários de "zona para baixo".
Os dados e arquivos de log são hospedados em armazenamento com redundância de zona (ZRS). O servidor em espera lê e reproduz continuamente os arquivos de log da conta de armazenamento do servidor primário, que a replicação no nível de armazenamento protege.
Se ocorrer um failover:
- A réplica em espera é ativada.
- Os arquivos de log binários do servidor primário continuam a ser aplicados ao servidor em espera para colocá-lo online até a última transação confirmada no servidor primário.
Os logs no ZRS são acessíveis mesmo quando o servidor primário não está disponível. Essa disponibilidade ajuda a garantir que não haja perda de dados. Depois que a réplica em espera é ativada e os logs binários são aplicados, o servidor de réplica em espera atual assume a função de servidor primário. Atualizações de DNS para que as conexões do cliente sejam diretas para o novo primário quando o cliente se reconectar. O failover é totalmente transparente a partir do aplicativo cliente e não requer nenhuma ação sua. A solução HA traz de volta o antigo servidor primário quando possível e o coloca como um modo de espera.
Use o nome do servidor de banco de dados para conectar aplicativos ao servidor primário. A solução não expõe informações de réplica em espera para acesso direto. As confirmações e gravações são confirmadas depois que os arquivos de log são liberados no ZRS do servidor primário. Devido à tecnologia de replicação de sincronização usada no armazenamento ZRS, você pode esperar um aumento de 5% a 10% na latência para gravações e confirmações de aplicativos.
Os backups automáticos, tanto instantâneos quanto backups de log, são executados em armazenamento com redundância de zona a partir do servidor de banco de dados primário.
Arquitetura de alta disponibilidade (HA) com redundância local
Ao implantar um servidor com HA redundante local, você cria dois servidores na mesma zona:
- Um servidor primário
- Um servidor de réplica em espera que tem a mesma configuração do servidor primário (camada de computação, tamanho de computação, tamanho de armazenamento e configuração de rede)
O servidor em espera fornece redundância de infraestrutura com uma máquina virtual separada (computação). Essa redundância reduz o tempo de failover e a latência da rede entre o aplicativo e o servidor de banco de dados devido à colocation.
Os dados e arquivos de log são hospedados em armazenamento localmente redundante (LRS). O servidor em espera lê e reproduz continuamente os arquivos de log da conta de armazenamento do servidor primário, que é protegida pela replicação no nível de armazenamento.
Se ocorrer um failover:
- A réplica em espera é ativada.
- Os arquivos de log binários do servidor primário continuam a ser aplicados ao servidor em espera para colocá-lo online até a última transação confirmada no servidor primário.
Os logs no LRS são acessíveis mesmo quando o servidor primário não está disponível. Essa disponibilidade ajuda a garantir que não haja perda de dados. Depois que a réplica em espera é ativada e os logs binários são aplicados, a réplica em espera atual assume a função de servidor primário. O DNS é atualizado para redirecionar conexões para o novo primário quando o cliente se reconecta. O failover é totalmente transparente a partir do aplicativo cliente e não requer nenhuma ação sua. A solução HA traz de volta o antigo servidor primário quando possível e o coloca como um modo de espera.
O nome do servidor de banco de dados conecta aplicativos ao servidor primário. As informações da réplica em espera não são expostas para acesso direto. As confirmações e gravações são reconhecidas depois que os arquivos de log são liberados no LRS do servidor primário. Como a réplica primária e a réplica em espera estão na mesma zona, há menos atraso de replicação e menor latência entre o servidor de aplicativos e o servidor de banco de dados. A configuração com redundância local não fornece alta disponibilidade quando as infraestruturas dependentes estão inativas para a zona de disponibilidade específica. Há tempo de inatividade até que todos os serviços dependentes estejam online novamente para essa zona de disponibilidade.
Os backups automáticos, tanto instantâneos quanto backups de log, são executados em armazenamento localmente redundante a partir do servidor de banco de dados primário.
Nota
Para HA com redundância de zona e com redundância local:
- Se ocorrer uma falha, o tempo necessário para que a réplica em espera assuma a função de principal depende do tempo necessário para reproduzir o log binário da conta de armazenamento principal para a espera. Para reduzir o tempo de failover, use chaves primárias em todas as tabelas. Os tempos de failover normalmente levam entre 60 e 120 segundos.
- O servidor em espera não está disponível para operações de leitura ou gravação. É um modo de espera passivo para permitir um failover rápido.
- Use sempre um nome de domínio totalmente qualificado (FQDN) para se conectar ao servidor primário. Evite usar um endereço IP para se conectar. Se ocorrer um failover, depois que as funções de servidor primário e em espera forem trocadas, um registro DNS A poderá ser alterado. Essa alteração impede que o aplicativo se conecte ao novo servidor primário se um endereço IP for usado na cadeia de conexão.
Processo de failover
Durante o processo de failover no Banco de Dados do Azure para MySQL, o sistema alterna automaticamente do servidor primário para a réplica em espera. Esse switch garante a continuidade e minimiza o tempo de inatividade. Quando o sistema deteta uma falha, ele promove a réplica em espera para se tornar o novo servidor primário. O sistema aplica os arquivos de log binários do servidor primário original à réplica em espera. Esse processo sincroniza a réplica em espera com a última transação confirmada e garante que não haja perda de dados. Essa transição perfeita ajuda a manter a alta disponibilidade e a confiabilidade do serviço de banco de dados.
Nota
Para reduzir a dependência do tempo de failover do cache DNS, a partir de outubro de 2025, todos os novos servidores HA criados com acesso público ou link privado adotarão a nova arquitetura com um SLB dedicado para cada servidor HA. Ao gerenciar o caminho de tráfego de dados do MySQL, o SLB elimina a necessidade de alterações de DNS durante o failover e melhora significativamente o desempenho do failover. Ele redireciona o tráfego para a instância primária atual durante o failover usando regras de balanceamento de carga. Os servidores existentes com acesso público ou link privado serão migrados gradualmente para minimizar o impacto. Os clientes que preferem a migração antecipada podem desativar e reativar a HA. Este recurso não é suportado para servidores que usam acesso privado com integração VNet.
Planeado: ativação pós-falha forçada
O failover forçado do Banco de Dados do Azure para Servidor MySQL Flexível permite que você force manualmente um failover. Esse recurso permite que você teste a funcionalidade com seus cenários de aplicativo e ajuda você a se preparar para interrupções.
A ativação pós-falha forçada aciona uma ativação pós-falha que ativa a réplica de reserva para se tornar no servidor principal com o mesmo nome do servidor de bases de dados ao atualizar o registo DNS. O servidor primário original é reiniciado e alterna para a réplica em espera. As conexões do cliente se desconectam e precisam se reconectar para retomar suas operações.
A duração total da ativação pós-falha depende da carga de trabalho atual e do último ponto de verificação. Em geral, leva entre 60 e 120 segundos.
Nota
Um evento Azure Resource Health é gerado durante um failover planejado. O evento representa o tempo de failover durante o qual o servidor está indisponível. Você pode ver os eventos acionados quando selecionado em Integridade do Recurso no painel esquerdo. O status representa failover iniciado pelo usuário ou manual como "Indisponível" e marcado como "Planejado". Exemplo - "Uma operação de failover foi acionada por um usuário autorizado (planejado)". Se o seu recurso permanecer nesse estado por um longo período, abra um ticket de suporte e nós o ajudaremos.
Não planeado: ativação pós-falha automática
O tempo de inatividade não planejado do serviço pode ocorrer devido a bugs de software ou falhas de infraestrutura, como falhas de computação, rede ou armazenamento. As quedas de energia também podem afetar a disponibilidade do banco de dados. Se o banco de dados ficar indisponível, a replicação para a réplica em espera será interrompida e a réplica em espera se tornará o banco de dados primário. As atualizações de DNS ocorrem e os clientes se reconectam ao servidor de banco de dados, retomando suas operações.
O tempo geral de failover é geralmente entre 60 e 120 segundos. No entanto, dependendo da atividade no servidor de banco de dados primário no momento do failover (como grandes transações e tempo de recuperação), o failover pode levar mais tempo.
Nota
Um evento de Integridade de Recursos do Azure é gerado durante um failover não planejado. O evento representa o tempo de failover quando o servidor está indisponível. Você pode ver os eventos acionados quando seleciona Integridade do recurso no painel esquerdo. O failover automático mostra um status de "Indisponível" e é marcado como "Não planejado".
Por exemplo, Indisponível: uma operação de failover foi acionada automaticamente (Não planejada). Se o seu recurso permanecer nesse estado por muito tempo, abra um ticket de suporte e nós o ajudamos.
Como funciona a deteção automática de failover em servidores habilitados para HA
O servidor primário e o servidor secundário têm dois pontos de extremidade de rede:
- Ponto de extremidade do cliente: os clientes se conectam e executam consultas na instância usando esse ponto de extremidade.
- Ponto de extremidade de gerenciamento: usado internamente para comunicações de serviço a componentes de gerenciamento e para conexão com armazenamento de back-end.
O componente do monitor de integridade faz continuamente as seguintes verificações:
- O monitor executa ping no ponto de extremidade da rede de gerenciamento do nó. Se essa verificação falhar duas vezes seguidas, ela acionará uma operação de failover automática. Esta verificação de integridade aborda cenários como indisponibilidade ou falta de resposta do nó devido a problemas de sistema operacional, problemas de rede entre componentes de gerenciamento e nós e problemas semelhantes.
- O monitor executa uma consulta simples na instância. Se as consultas não forem executadas, o failover automático será acionado. Essa verificação de integridade aborda cenários como falhas, paradas ou travamentos do daemon MySQL, problemas de armazenamento de back-end e problemas semelhantes.
Nota
A verificação de integridade não monitora problemas de rede entre o aplicativo e o ponto de extremidade de rede do cliente (acesso privado/público). Esses problemas podem ocorrer no caminho de rede, no ponto de extremidade ou em problemas de DNS no lado do cliente. Se você usar o acesso privado, certifique-se de que as regras do NSG para a rede virtual não bloqueiem a comunicação com o ponto de extremidade de rede do cliente da instância na porta 3306. Para acesso público, certifique-se de que as regras de firewall estão definidas e que o tráfego de rede é permitido na porta 3306 (se o caminho de rede tiver outros firewalls). Você também precisa cuidar da resolução de DNS do lado do aplicativo cliente.
Monitore a alta disponibilidade
Para verificar o status de configuração de alta disponibilidade do servidor, use o Status de alta disponibilidade no painel de alta disponibilidade do servidor no portal.
| Estado | Descrição |
|---|---|
| NotEnabled | A alta disponibilidade não está ativada. |
| Replicandodados | O servidor em espera é sincronizado com o servidor primário durante o provisionamento do servidor de alta disponibilidade ou quando você habilita a opção de alta disponibilidade. |
| Failover | O servidor de banco de dados está fazendo failover do primário para o modo de espera. |
| Saudável | A opção de alta disponibilidade está ativada. |
| RemovendoStandby | O processo de exclusão está em andamento quando você desabilita a opção de alta disponibilidade. |
Para monitorar a integridade do servidor de alta disponibilidade, use as seguintes métricas.
| Nome de exibição da métrica | Métrica | Unidade | Descrição |
|---|---|---|---|
IO Estado do HA |
ha_io_running | Estado |
IO O status do HA mostra o estado da replicação do HA. O valor da métrica é 1 se o thread de E/S estiver em execução e 0 se não. |
| Estado de HA SQL | ha_sql_running | Estado | O Status do HA SQL mostra o estado da replicação do HA. O valor da métrica é 1 se o thread SQL estiver em execução e 0 se não. |
| Atraso na replicação de HA | atraso_de_replicação | Segundos | O atraso de replicação é o número de segundos em que o modo de espera está atrasado na reprodução das transações recebidas no servidor primário. |
Limitações
Tenha em mente as seguintes considerações ao usar a alta disponibilidade:
Você pode configurar a alta disponibilidade com redundância de zona somente durante a criação do servidor.
A camada de computação burstable não suporta alta disponibilidade.
A reinicialização do servidor de banco de dados primário para aplicar alterações de parâmetros estáticos também reinicia a réplica em espera.
A solução ativa o modo GTID porque usa GTID. Verifique se sua carga de trabalho tem restrições ou limitações na replicação com GTIDs.
Nota
O crescimento automático de armazenamento está habilitado por padrão para um servidor configurado de alta disponibilidade e não pode ser desativado.
Controlos sanitários
Quando você configura a alta disponibilidade (HA) para o Banco de Dados do Azure para MySQL, as verificações de integridade desempenham um papel crucial na manutenção da confiabilidade e do desempenho do seu banco de dados. Essas verificações monitoram continuamente o status e a integridade das réplicas principal e em espera, garantindo que detetem quaisquer problemas prontamente. Ao rastrear várias métricas, como capacidade de resposta do servidor, atraso de replicação e utilização de recursos, as verificações de integridade ajudam a garantir que os processos de failover possam ser executados sem problemas, minimizando o tempo de inatividade e evitando a perda de dados. Verificações de integridade configuradas corretamente são essenciais para alcançar o nível desejado de disponibilidade e resiliência na configuração do banco de dados.
Monitorando a integridade
Você pode monitorar a integridade da sua configuração de HA por meio do portal do Azure. As principais métricas a serem observadas incluem:
- Capacidade de resposta do servidor: indica se o servidor primário está acessível.
- Atraso de replicação: mede o atraso entre as réplicas principal e em espera, garantindo a consistência dos dados.
- Utilização de recursos: Monitora o uso de CPU, memória e armazenamento para evitar gargalos.