Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Servidor Flexível do Banco de Dados do Azure para MySQL permite configurar a alta disponibilidade com failover automático. Essa solução garante que 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 Servidor Flexível provisiona e gerencia automaticamente uma réplica em espera. Você paga pela computação provisionada e pelo armazenamento 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 da infraestrutura em várias zonas de disponibilidade. Ele oferece o nível mais alto de disponibilidade, mas requer que você configure a redundância do aplicativo entre zonas. Escolha a HA com redundância de zona quando quiser proteger contra qualquer falha de infraestrutura na zona de disponibilidade e quando a latência em toda a zona de disponibilidade for aceitável. Você pode habilitar a HA com redundância de zona somente ao criar o servidor. A HA com redundância de zona está disponível em um subconjunto de regiões do Azure em que a região dá suporte a várias zonas de disponibilidade e há compartilhamentos de arquivo Premium com redundância de zona disponíveis.
Alta disponibilidade localmente redundante. Essa opção fornece redundância de infraestrutura com menor latência de rede porque os servidores primários e em espera estão na mesma zona de disponibilidade. Ele oferece alta disponibilidade sem a necessidade de configurar a redundância de aplicativo entre zonas. Escolha HA com redundância local quando quiser atingir o nível mais alto 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 em que você pode usar o Servidor Flexível do Banco de Dados do Azure para 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 do servidor primário, incluindo a camada de computação, o tamanho da computação, o tamanho do armazenamento e a configuração de rede.
Você pode escolher a zona de disponibilidade para o servidor primário e a réplica em espera. Quando os servidores de banco de dados em espera e os aplicativos em espera são colocados na mesma zona, a latência é reduzida. Ele também ajuda você a se preparar para situações de recuperação de desastre e cenários de "zona para baixo".
Os dados e os arquivos de log são hospedados no ZRS (armazenamento com redundância de zona). 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ário do servidor primário continuam a ser aplicados ao servidor em espera para colocá-lo online na ú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 do servidor primário. Atualizações de DNS para que as conexões de cliente sejam diretas para o novo primário quando o cliente se reconectar. O failover é totalmente transparente no aplicativo cliente e não exige nenhuma ação sua. Depois, a solução de HA reativa o antigo servidor primário quando possível e coloca-o em 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 as gravações são reconhecidas 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, espera-se um aumento de latência de 5% a 10% nas gravações e confirmações de aplicativos.
Os backups automáticos (instantâneos e backups de log) são executados no armazenamento com redundância de zona do servidor de banco de dados primário.
Arquitetura de alta disponibilidade (HA) com redundância local
Ao implantar um servidor com HA com redundância local, você cria dois servidores na mesma zona:
- Um servidor primário
- Um servidor de réplica em espera com a mesma configuração que o servidor primário (camada de computação, tamanho da computação, tamanho do armazenamento e configuração da 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 de rede entre o aplicativo e o servidor de banco de dados devido à colocação.
Os dados e os arquivos de log são hospedados no LRS (armazenamento com redundância local). 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 em nível de armazenamento.
Se ocorrer um failover:
- A réplica em espera é ativada.
- Os arquivos de log binário do servidor primário continuam a ser aplicados ao servidor em espera para colocá-lo online na ú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 do servidor primário. O DNS é atualizado para redirecionar as conexões ao novo primário quando o cliente se reconectar. O failover é totalmente transparente no aplicativo cliente e não exige nenhuma ação sua. Depois, a solução de HA reativa o antigo servidor primário quando possível e coloca-o em 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 as gravações são reconhecidas depois que os arquivos de log são liberados no LRS do servidor primário. Como o servidor primário e a réplica em espera estão na mesma zona, há menos latência de replicação e uma latência mais baixa 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 inoperantes 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 (instantâneos e backups de log) são executados em um armazenamento com redundância local no servidor de banco de dados primário.
Observação
Para a 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 primário depende do tempo necessário para reproduzir o log binário da conta de armazenamento primária para o 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 fica disponível para operações de leitura ou gravação. É uma espera passiva para habilitar o failover rápido.
- Sempre use o FQDN (nome de domínio totalmente qualificado) para se conectar com o servidor primário. Evite usar um endereço IP para fazer a conexão. Se ocorrer um failover, depois que as funções de servidor primário e em espera forem alternadas, 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. Essa opção garante a continuidade e minimiza o tempo de inatividade. Quando o sistema detecta 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ário do servidor primário original à réplica em espera. Esse processo sincroniza a réplica em espera com a última transação confirmada e não garante nenhuma perda de dados. Essa transição perfeita ajuda a manter a alta disponibilidade e a confiabilidade do serviço de banco de dados.
Observação
Para reduzir a dependência do tempo de failover no 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 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. 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 desabilitar e reabilitar o HA. Esse recurso não tem suporte para servidores que usam acesso privado com integração de VNet.
Planejado: failover forçado
O failover forçado do Banco de Dados do Azure para MySQL – Servidor Flexível permite que você force um failover manualmente. Essa funcionalidade permite testar a funcionalidade com os cenários do aplicativo e ajuda você a se preparar para interrupções.
O failover forçado dispara um failover que ativa a réplica em espera para se tornar o servidor primário com o mesmo nome do servidor de banco de dados atualizando o registro 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.
O tempo de failover geral depende da carga de trabalho atual e do último ponto de verificação. Em geral, isso leva de 60 a 120 segundos.
Observação
Um evento do Azure Resource Health é gerado durante uma recuperação planejada. O evento representa o tempo de failover durante o qual o servidor não está disponível. Você pode ver os eventos disparados quando selecionado no Resource Health no painel esquerdo. O status representa o failover manual ou iniciado pelo usuário como "Indisponível" e marcado como "Planejado". Exemplo - "Uma operação de failover foi disparada por um usuário autorizado (Planejado)". Se o recurso permanecer nesse estado por um longo período, abra um tíquete de suporte e nós o ajudaremos.
Não planejado: failover automático
O tempo de inatividade do serviço não planejado pode ocorrer devido a bugs de software ou falhas de infraestrutura, como falhas de computação, rede ou armazenamento. Interrupções 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 de failover geral geralmente está entre 60 e 120 segundos. No entanto, dependendo da atividade no servidor de banco de dados primário no momento do failover (como transações grandes e tempo de recuperação), o failover pode levar mais tempo.
Observação
Um evento do Azure Resource Health é gerado durante um failover não planejado. O evento representa o tempo de failover quando o servidor não está disponível. Você pode ver os eventos disparados ao selecionar Resource Health 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 disparada automaticamente (não planejada). Se o recurso permanecer nesse estado por muito tempo, abra um tíquete de suporte e nós o ajudaremos.
Como a detecção de failover automático funciona em servidores habilitados para HA
O servidor primário e o servidor secundário têm cada um dois pontos de extremidade de rede:
- Ponto de Extremidade do Cliente: os clientes 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 para componentes de gerenciamento e para se conectar ao armazenamento de back-end.
O componente do monitor de integridade faz continuamente as seguintes verificações:
- O monitor executa ping no ponto de extremidade de rede de gerenciamento do nó. Se essa verificação falhar duas vezes seguidas, ela disparará uma operação de failover automático. Essa verificação de integridade aborda cenários como indisponibilidade ou não capacidade de 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, os gatilhos de failover automático serão executados. Essa verificação de integridade aborda cenários como falhas de daemon do MySQL, paradas ou travamentos e problemas de armazenamento de back-end e problemas semelhantes.
Observação
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, verifique se as regras NSG para a rede virtual não bloqueiam a comunicação com o ponto de extremidade de rede do cliente da instância na porta 3306. Para acesso público, verifique se as regras de firewall estão definidas e 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.
Monitorar alta disponibilidade
Para verificar o status de configuração de alta disponibilidade do servidor, use o Status de alta disponibilidade no painel alta disponibilidade do servidor no portal.
| Estado | Descrição |
|---|---|
| NotEnabled | A alta disponibilidade não está habilitada. |
| ReplicatingData | O servidor em espera sincroniza com o servidor primário durante o provisionamento de servidor de alta disponibilidade ou quando você habilita a opção de alta disponibilidade. |
| FailingOver | O servidor de banco de dados está fazendo failover do primário para o em espera. |
| Íntegro | A opção de alta disponibilidade está habilitada. |
| RemovingStandby | O processo de exclusão está em andamento quando você desabilitar a opção de alta disponibilidade. |
Para monitorar a integridade do servidor de alta disponibilidade, use as métricas a seguir.
| Nome de exibição da métrica | Métrica | Unidade | Descrição |
|---|---|---|---|
Status IO de HA |
ha_io_running | Estado | O Status IO de HA mostra o estado da replicação de HA. O valor da métrica será 1 se o thread de E/S estiver em execução e 0 se não estiver. |
| Status SQL de HA | ha_sql_running | Estado | O Status do SQL de HA mostra o estado da replicação de HA. O valor da métrica será 1 se o thread SQL estiver em execução e 0 se não estiver. |
| Retardo de replicação de HA | atraso_de_replicação | Segundos | O atraso de replicação é o número de segundos de atraso do servidor em espera 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 com capacidade de intermitência não dá suporte à alta disponibilidade.
Reiniciar o servidor de banco de dados primário para aplicar alterações de parâmetro estático também reinicia a réplica em espera.
A solução ativa o modo GTID porque usa GTID. Verifique se a carga de trabalho tem restrições ou limitações para replicação com GTIDs.
Observação
O crescimento automático do armazenamento é habilitado por padrão para um servidor configurado de alta disponibilidade e não pode ser desabilitado.
Verificações de integridade
Quando você configura 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 banco de dados. Essas verificações monitoram continuamente o status e a integridade das réplicas primárias e em espera, garantindo que elas detectem problemas imediatamente. Ao acompanhar várias métricas, como capacidade de resposta do servidor, retardo de replicação e utilização de recursos, as verificações de integridade ajudam a garantir que os processos de failover possam ser executados perfeitamente, minimizando o tempo de inatividade e evitando a perda de dados. As 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.
Monitoramento da integridade
Você pode monitorar a integridade da 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.
- Retardo de replicação: mede o atraso entre as réplicas primária e de espera, garantindo a consistência dos dados.
- Utilização de recursos: Monitora o uso de CPU, memória e armazenamento para evitar gargalos.