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.
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 manutenções planejadas ou interrupções inesperadas. Este artigo aborda perguntas comuns sobre opções de alta disponibilidade (HA), cobrança, processos de failover, impactos de desempenho e práticas recomendadas para ajudá-lo a tomar decisões informadas sobre suas cargas de trabalho do MySQL no Azure.
Quais são os SLAs para servidores flexíveis habilitados para HA com redundância local versus com redundância de zona?
As informações de SLA para Banco de Dados do Azure para MySQL – Servidor Flexível se encontram em SLA para Banco de Dados do Azure para MySQL.
Como é feita a cobrança dos servidores de HA (alta disponibilidade)?
Os servidores habilitados com HA têm uma réplica primária e uma secundária. A réplica secundária pode estar na mesma zona ou ter redundância de zona. Você receberá uma cobrança pela computação e pelo armazenamento provisionados às réplicas 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 de HA com redundância de zona é cobrado por 8 vCores e 1.024 GB de armazenamento. Dependendo do volume de armazenamento de backup, você também pode receber uma cobrança 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 fica disponível para operações de leitura ou gravação. É uma espera passiva para habilitar o failover rápido.
Haverá perda de dados quando ocorrer failover?
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 for ativada e os logs binários forem aplicados, ela assumirá a função do servidor primário.
Preciso executar alguma ação após um failover?
Os failovers são totalmente transparentes no aplicativo cliente. Você não precisa realizar nenhuma ação. Os aplicativos devem apenas usar a lógica de repetição para as conexões.
O que acontecerá se eu não escolher uma zona específica para a réplica em espera? Posso mudar de zona mais tarde?
Se você não escolher uma zona, uma será selecionada aleatoriamente. É a usada com o servidor primário. Para alterar a zona mais tarde, você poderá definir a Alta Disponibilidade como Desabilitada no painel Alta Disponibilidade e definir novamente como Redundância de Zona e escolher uma zona.
A replicação entre as réplicas primária e em espera é síncrona?
A replicação entre as réplicas primária e em espera é semelhante ao modo semissíncrono no MySQL. Quando uma transação é confirmada, ela não é necessariamente confirmada na réplica em espera. Mas quando a primária não estiver disponível, a réplica em espera replicará todas as alterações de dados da primária para garantir que não haja perda de dados.
Há 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 será disparado. Se a reinicialização da VM do Servidor Flexível for bem-sucedida antes de concluir o failover, a operação de failover será cancelada. A determinação de qual servidor é usado como a réplica primária depende do processo que termina primeiro.
Há um impacto no desempenho quando uso a HA?
Quanto à HA com redundância de zona, embora não haja grande impacto no desempenho das cargas de trabalho de leitura entre as zonas de disponibilidade, é possível que haja uma queda de até 40% na latência das consultas de gravação. O aumento da latência de gravação ocorre devido à replicação síncrona na zona de disponibilidade. O impacto da latência de gravação é duas vezes maior na HA com redundância de zona em comparação com a HA da mesma zona. Para HA com redundância local, como a réplica primária e em espera está na mesma zona, a latência de replicação e, portanto, a latência de gravação síncrona é menor.
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 com redundância local, mas se a disponibilidade e a resiliência de seus dados forem mais críticas para você em detrimento da queda de latência de gravação, você deverá escolher ha com redundância de zona. Para medir o impacto preciso da redução da latência na configuração de HA, recomendamos que você execute testes de desempenho em sua carga de trabalho para tomar uma decisão informada.
Como a manutenção do servidor de HA acontece?
Eventos planejados, como dimensionamento de computação e atualizações de versão secundárias, ocorrem primeiro na instância em espera original e são seguidos pelo gatilho de uma operação de recuperação planejada e operam na instância primária original. Você pode definir a janela de manutenção agendada para os servidores de HA como faz para os servidores flexíveis. O tempo de inatividade é o mesmo que o tempo de inatividade da instância do Servidor Flexível do Banco de Dados do Azure para MySQL quando a HA está desativada.
Posso fazer uma PITR (restauração pontual) do meu servidor de HA?
Você pode fazer um PITR para uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL habilitada para HA para uma nova instância do Servidor Flexível do Banco de Dados do Azure para MySQL que tenha a HA desabilitada. Se o servidor de origem foi criado com HA com redundância de zona, você pode habilitar a HA com redundância de zona ou a HA com redundância local no servidor restaurado posteriormente. Se o servidor de origem tiver sido criado com HA com redundância local, você poderá habilitar apenas a HA com redundância local no servidor restaurado.
Posso habilitar a HA em um servidor depois de criar o servidor?
A HA com redundância de zona deve ser ativada durante a criação do servidor. Você pode habilitar a HA com redundância local após a criação do servidor, mas verifique se os parâmetros do servidor enforce_gtid_consistency e gtid_mode estão definidos ON antes de continuar.
Posso desabilitar a HA de um servidor depois de criá-lo?
Você pode desabilitar a HA em um servidor depois criá-lo. A cobrança é interrompida imediatamente.
Como posso reduzir o tempo de inatividade?
Você precisa ser capaz de reduzir o tempo de inatividade do aplicativo mesmo quando não está usando a HA. O tempo de inatividade de serviço, como patches agendados, atualizações de versão secundária ou operações iniciadas pelo cliente, como a escala de computação, pode ocorrer durante as janelas de manutenção agendada. Para reduzir o impacto no aplicativo das tarefas de manutenção iniciadas pelo Azure, você pode agendá-las em um dia da semana e em uma hora que minimizem o impacto no aplicativo.
Posso usar uma réplica de leitura para um servidor habilitado para HA?
Sim, há suporte para as réplicas de leitura dos servidores de HA.
Posso usar a Replicação de Dados em servidores HA?
O suporte para replicação de dados para servidor habilitado para alta disponibilidade (HA) só está disponível 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 as reinicializações do servidor ou ao escalar ou reduzir o ambiente verticalmente?
Atualmente, o Servidor Flexível do Banco de Dados do Azure para MySQL usa a Recuperação Planejada para otimizar as operações de HA, incluindo a expansão/redução vertical e a manutenção planejada para ajudar a reduzir o tempo de inatividade.
Quando essas operações eram iniciadas, ela operava primeiro na instância em espera original, seguida pelo disparo de uma operação de recuperação planejada e, em seguida, operava na instância primária original.
Podemos alterar o modo de disponibilidade (HA com redundância de zona/com redundância local) do servidor**
Se você criar o servidor com o modo HA com Redundância de zona habilitado, poderá alterar de HA com redundância de zona para redundância local e vice-versa.
Para alterar o modo de disponibilidade, você pode definir Alta Disponibilidade para Desabilitado no painel de Alta Disponibilidade e, em seguida, defina-o de volta como Redundante de Zona ou Com redundância local e escolha Modo de Alta Disponibilidade.