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.
A alta disponibilidade é um recurso fundamental do Banco de Dados do Azure para MySQL, projetado para minimizar o tempo de inatividade e garantir que seus aplicativos permaneçam acessíveis mesmo durante a manutenção planejada ou interrupções inesperadas. Este artigo aborda perguntas comuns sobre opções de alta disponibilidade (HA), cobrança, processos de failover, impactos no desempenho e práticas recomendadas para ajudá-lo a tomar decisões informadas para suas cargas de trabalho do MySQL no Azure.
Quais são os SLAs para servidores flexíveis com HA com redundância local vs com redundância de zona?
Informações de SLA para o Banco de Dados do Azure para o Servidor Flexível MySQL podem ser encontradas em SLA para o Banco de Dados do Azure para MySQL.
Como sou cobrado por servidores de alta disponibilidade (HA)?
Os servidores habilitados com HA têm uma réplica primária e secundária. A réplica secundária pode estar na mesma zona ou zona redundante. Você é cobrado pela computação e armazenamento provisionados para a réplica primária e secundária. Por exemplo, se você tiver um primário com 4 vCores de computação e 512 GB de armazenamento provisionado, sua réplica secundária terá 4 vCores e 512 GB de armazenamento provisionado.
Seu servidor HA redundante de zona é cobrado por 8 vCores e 1.024 GB de armazenamento. Dependendo do volume de armazenamento de backup, você também pode ser cobrado pelo armazenamento de backup.
Posso usar a réplica em espera para operações de leitura ou gravação?
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.
Terei perda de dados quando o failover acontecer?
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, ela assume a função do servidor primário.
Preciso tomar alguma medida após um failover?
Os failovers são totalmente transparentes a partir do aplicativo cliente. Você não precisa tomar nenhuma medida. Os aplicativos devem apenas usar a lógica de repetição para suas conexões.
O que acontece quando não escolho uma zona específica para a minha réplica em espera? Posso alterar a zona mais tarde?
Se você não escolher uma zona, uma será selecionada aleatoriamente. É o usado para o servidor primário. Para alterar a zona mais tarde, você pode definir Alta Disponibilidade como Desabilitada no painel Alta Disponibilidade e, em seguida, defini-la novamente como Zona Redundante e escolher uma zona.
A replicação entre as réplicas principal e em espera é síncrona?
A replicação entre o primário e o modo de espera é semelhante ao modo semissíncrono no MySQL. Quando uma transação é confirmada, ela não necessariamente se compromete com o modo de espera. Mas quando o primário não está disponível, o modo de espera replica todas as alterações de dados do principal para garantir que não haja perda de dados.
Existe um failover para a réplica em espera para todas as falhas não planejadas?
Se houver uma falha de banco de dados ou de nó, a VM do Servidor Flexível será reiniciada no mesmo nó. Ao mesmo tempo, um failover automático é acionado. Se a reinicialização da VM do Servidor Flexível for bem-sucedida antes da conclusão do failover, a operação de failover será cancelada. A determinação de qual servidor usar como réplica primária depende do processo que termina primeiro.
Existe um impacto no desempenho quando utilizo HA?
Para HA com redundância de zona, embora não haja grande impacto no desempenho de cargas de trabalho de leitura em zonas de disponibilidade, pode haver uma queda de até 40% na latência da consulta de gravação. O aumento na latência de gravação se deve à replicação síncrona na zona de disponibilidade. O impacto da latência de gravação é duas vezes no HA redundante de zona em comparação com o mesmo HA de zona. Para HA redundante local, como a réplica primária e a réplica em espera estão na mesma zona, a latência de replicação e, portanto, a latência de gravação síncrona são menores.
Em resumo, se a latência de gravação for mais crítica para você em comparação com a disponibilidade, talvez você queira escolher HA redundante local, mas se a disponibilidade e a resiliência de seus dados forem mais críticas para você em detrimento da queda da latência de gravação, você deverá escolher HA com redundância de zona. Para medir o impacto preciso da queda de latência na configuração de HA, recomendamos que você realize testes de desempenho para sua carga de trabalho para tomar uma decisão informada.
Como acontece a manutenção do meu servidor HA?
Eventos planejados, como dimensionamento de computação e atualizações de versão secundária, acontecem primeiro na instância de espera original e, em seguida, acionam uma operação de failover planejada e, em seguida, operam na instância primária original. Você pode definir a janela de manutenção agendada para servidores HA como faz para Servidores flexíveis. A quantidade de tempo de inatividade é a mesma que o tempo de inatividade da instância do Servidor Flexível do Banco de Dados do Azure para MySQL quando a HA está desabilitada.
Posso fazer uma restauração point-in-time (PITR) do meu servidor HA?
Você pode fazer um PITR para uma instância do Servidor Flexível do Banco de Dados do Azure habilitado para HA para MySQL para uma nova instância do Servidor Flexível do Banco de Dados do Azure para MySQL que tenha HA desabilitada. Se o servidor de origem tiver sido criado com HA com redundância de zona, você poderá habilitar HA com redundância de zona ou HA com redundância local no servidor restaurado posteriormente. Se o servidor de origem tiver sido criado com HA redundante local, você poderá habilitar somente HA redundante local no servidor restaurado.
Posso ativar a HA em um servidor depois de criar o servidor?
A HA com redundância de zona deve ser habilitada durante a criação do servidor. Você pode habilitar a HA com redundância local após a criação do servidor, mas certifique-se de que os parâmetros enforce_gtid_consistency e gtid_mode sejam ajustados para ON antes de prosseguir.
Posso desativar o HA para um servidor depois de criá-lo?
Você pode desativar o HA em um servidor depois de criá-lo. A faturação é interrompida imediatamente.
Como posso reduzir o tempo de inatividade?
Você precisa ser capaz de reduzir o tempo de inatividade do seu aplicativo, mesmo quando não estiver usando HA. O tempo de inatividade do serviço, como patches agendados, atualizações de versões secundárias ou operações iniciadas pelo cliente, como dimensionamento de computação, pode ser executado durante as janelas de manutenção programada. Para reduzir o impacto do aplicativo para tarefas de manutenção iniciadas pelo Azure, você pode agendá-las em um dia da semana e hora que minimize o impacto no aplicativo.
Posso usar uma réplica de leitura para um servidor habilitado para HA?
Sim, réplicas de leitura são suportadas para servidores HA.
Posso usar a replicação Data-in para servidores HA?
O suporte para replicação de dados para servidor habilitado para alta disponibilidade (HA) está disponível somente por meio da replicação baseada em GTID.
O procedimento armazenado para replicação usando GTID está disponível em todos os servidores habilitados para HA pelo nome mysql.az_replication_with_gtid.
Para reduzir o tempo de inatividade, posso fazer failover para o servidor em espera durante a reinicialização do servidor ou durante o dimensionamento para cima ou para baixo?
Atualmente, o Banco de Dados do Azure para Servidor Flexível MySQL utilizou o Failover Planejado para otimizar as operações de HA, incluindo escalonamento para cima/para baixo e manutenção planejada para ajudar a reduzir o tempo de inatividade.
Quando essas operações fossem iniciadas, ele operaria primeiro na instância de espera original, seguida pelo acionamento de uma operação de failover planejada e, em seguida, operaria na instância primária original.
Podemos alterar o modo de disponibilidade (HA redundante de zona/redundante local) do servidor**
Se você criar o servidor com o modo HA com redundância de zona habilitado, poderá mudar de HA com redundância de zona para redundante local e vice-versa.
Para alterar o modo de disponibilidade, você pode definir Alta Disponibilidade como Desabilitado no painel Alta Disponibilidade e, em seguida, defini-lo novamente como Zona Redundante ou Local-redundante e escolher Modo de Alta Disponibilidade.