Conceitos de elevada disponibilidade na Base de Dados do Azure para MySQL – Servidor Flexível

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Flexível

O Banco de Dados do Azure para servidor flexível MySQL permite configurar a alta disponibilidade com failover automático. A solução de elevada disponibilidade foi concebida para garantir que os dados consolidados nunca se perdem devido a falhas e que a base de dados não será um ponto único de falha na arquitetura de software. Quando a alta disponibilidade é configurada, o servidor flexível provisiona e gerencia automaticamente uma réplica em espera. Você é cobrado pela computação e armazenamento provisionados para a réplica primária e secundária. Existem dois modelos arquitetónicos de elevada disponibilidade:

• HA redundante de zona. Essa opção é preferida para isolamento completo e redundância de infraestrutura em várias zonas de disponibilidade. Ele fornece o mais alto nível de disponibilidade, mas exige que você configure a redundância de aplicativos entre zonas. A HA com redundância de zona é preferida quando você deseja atingir o mais alto nível de disponibilidade contra qualquer falha de infraestrutura na zona de disponibilidade e quando a latência na zona de disponibilidade é aceitável. Ele pode ser ativado somente quando o servidor é criado. 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.

• HA da mesma zona. Essa opção é preferida para redundância de infraestrutura com menor latência de rede porque os servidores primário e em espera estarão na mesma zona de disponibilidade. Ele fornece alta disponibilidade sem a necessidade de configurar redundância de aplicativos entre zonas. A HA de mesma zona é preferida quando você deseja atingir o mais alto nível de disponibilidade em uma única zona de disponibilidade com a menor latência de rede. A HA da mesma zona 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 HA com redundância de zona

Quando você implanta um servidor com HA com redundância de zona, dois servidores serão criados:

• Um servidor primário em uma zona de disponibilidade.
• Um servidor de réplica em espera que tem a mesma configuração que o servidor primário (camada de computação, tamanho de computação, tamanho de armazenamento e configuração de rede) em outra zona de disponibilidade da mesma região do Azure.

Você pode escolher a zona de disponibilidade para a réplica principal 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 permite que você se prepare melhor 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 os arquivos de log continuamente da conta de armazenamento do servidor primário, que é protegida pela replicação no nível de armazenamento.

Se houver 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 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. O DNS é atualizado para que as conexões do cliente sejam direcionadas 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.

O nome do servidor de banco de dados é usado para conectar 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 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 HA da mesma zona

Quando você implanta um servidor com HA de mesma zona, dois servidores serão criados 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 oferece 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 os arquivos de log continuamente da conta de armazenamento do servidor primário, que é protegida pela replicação no nível de armazenamento.

Se houver 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 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 é usado para conectar 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 da mesma zona não fornece alta disponibilidade quando as infraestruturas dependentes estão inativas para a zona de disponibilidade específica. Haverá tempo de inatividade até que todos os serviços dependentes estejam on-line 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 redundante de zona e HA de mesma zona:

• Se houver 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. Portanto, recomendamos que você use chaves primárias em todas as tabelas para reduzir o tempo de failover. Os tempos de failover são normalmente 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 houver 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 impediria que o aplicativo se conectasse ao novo servidor primário se um endereço IP for usado na cadeia de conexão.

Processo de failover

Planeado: ativação pós-falha forçada

O failover forçado flexível do Banco de Dados do Azure para MySQL permite que você force manualmente um failover. Esse recurso permite que você teste a funcionalidade com seus cenários de aplicativo e ajuda a prepará-lo 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 principal original é reiniciado e mudado para a réplica de espera. As ligações do cliente são desligadas e têm de ser ligadas novamente para retomarem as 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, espera-se que demore entre 60 e 120 segundos.

Nota

O evento Azure Resource Health é gerado no caso de failover planejado, representando o tempo de failover durante o qual o servidor estava indisponível. Os eventos acionados podem ser vistos quando clicado em "Integridade do recurso" no painel esquerdo. O failover iniciado pelo usuário/manual é representado pelo status 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 neste estado por um longo período de tempo, abra um ticket de suporte e nós iremos ajudá-lo.

Não planeado: ativação pós-falha automática

O tempo de inatividade não planejado do serviço pode ser causado por bugs de software ou falhas de infraestrutura, como falhas de computação, rede ou armazenamento, ou quedas de energia que afetam a disponibilidade do banco de dados. Se a base de dados ficar indisponível, a replicação para a réplica de reserva será interrompida e a réplica de reserva será ativada como a base de dados principal. O DNS é atualizado e os clientes se reconectam ao servidor de banco de dados e retomam suas operações.

A duração total da ativação pós-falha deverá ser entre 60 e 120 segundos. Mas, 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

O evento Azure Resource Health é gerado no caso de failover não planejado, representando o tempo de failover durante o qual o servidor estava indisponível. Os eventos acionados podem ser vistos quando clicado em "Integridade do recurso" no painel esquerdo. O failover automático é representado pelo status como "Indisponível" e marcado como "Não planejado". Exemplo - "Indisponível: Uma operação de failover foi acionada automaticamente (Não planejada)". Se o seu recurso permanecer neste estado por um longo período de tempo, abra um ticket de suporte e nós iremos ajudá-lo.

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: o cliente se conecta e executa a consulta 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 faz pings nos nós Endpoint da rede de gerenciamento. Se essa verificação falhar duas vezes continuamente, ela acionará a operação de failover automática. O cenário como nó está indisponível/não está respondendo devido a um problema de sistema operacional, problema de rede entre componentes de gerenciamento e nós, etc. será resolvido por esta verificação de integridade.
• O monitor também executa uma consulta simples na instância. Se as consultas não forem executadas, o failover automático será acionado. Os cenários como o demônio do MySQL travou / parou / travou, problema de armazenamento de back-end, etc., serão abordados por esta verificação de integridade.

Nota

Se houver algum problema de rede entre o aplicativo e o ponto de extremidade de rede do cliente (acesso privado/público), seja no caminho de rede, no ponto de extremidade ou problemas de DNS no lado do cliente, a verificação de integridade não monitorará esse cenário. Se você estiver usando acesso privado, certifique-se de que as regras NSG para a VNet 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). A resolução de DNS do lado do aplicativo cliente também precisa ser cuidada.

Monitoramento para alta disponibilidade

O Status de Alta Disponibilidade localizado no painel Alta Disponibilidade do servidor no portal pode ser usado para determinar o status de configuração de HA do servidor.

Estado	Descrição
NotEnabled	A HA não está ativada.
Replicandodados	O servidor em espera está em processo de sincronização com o servidor primário no momento do provisionamento do servidor HA ou quando a opção HA está habilitada.
Failover	O servidor de banco de dados está em processo de failover do primário para o modo de espera.
Saudável	A opção HA está ativada.
RemovendoStandby	Quando a opção HA estiver desativada e o processo de exclusão estiver em andamento.

Você também pode usar as métricas abaixo para monitorar a integridade do servidor HA.

Nome de exibição da métrica	Metric	Unidade	Description
Estado de E/S do HA	ha_io_running	Estado	HA IO Status indica o estado da replicação de HA. O valor da métrica é 1 se o thread de E/S estiver em execução e 0 se não.
HA SQL Status	ha_sql_running	Estado	HA SQL Status indica o estado da replicação 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	replication_lag	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

Aqui estão algumas considerações que você deve ter em mente ao usar a alta disponibilidade:

• A alta disponibilidade com redundância de zona pode ser definida somente quando o servidor flexível é criado.
• A alta disponibilidade não é suportada na camada de computação burstable.
• Reiniciar o servidor de bases de dados primário para recolher as alterações de parâmetros estáticos também reinicia a réplica de reserva.
• O modo GTID será ativado à medida que a solução HA utilizar GTID. Verifique se sua carga de trabalho tem restrições ou limitações na replicação com GTIDs.

Nota

Se você estiver habilitando HA de mesma zona após a criação do servidor, será necessário verificar se os parâmetros do servidor enforce_gtid_consistency" e "gtid_mode" estão definidos como ON antes de habilitar o HA.

Nota

O crescimento automático de armazenamento está habilitado por padrão para um servidor configurado de Alta Disponibilidade e não pode ser desabilitado.

Perguntas mais frequentes (FAQ)

• Quais são os SLAs para servidor flexível habilitado para HA com redundância de mesma zona vs zona?

  As informações de SLA para o servidor flexível do Banco de Dados do Azure para MySQL podem ser encontradas em SLA do Banco de Dados do Azure para MySQL.

• Como sou cobrado por servidores de alta disponibilidade (HA)? Os servidores ativados com HA têm uma réplica primária e secundária. A réplica secundária pode estar na mesma zona ou pode ter redundância entre zonas. Você é cobrado pela computação e armazenamento provisionados para a réplica primária e secundária. Por exemplo, se tiver uma primária com 4 vCores de computação e 512 GB de armazenamento aprovisionado, a réplica secundária também terá 4 vCores e 512 GB de armazenamento aprovisionado. O servidor HA com redundância de zona será faturado por 8 vCores e 1024 GB de armazenamento. Consoante o volume de armazenamento de cópias de segurança, também poderá ser cobrado o armazenamento de cópias de segurança.

• 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. Será o usado para o servidor primário. Para alterar a zona mais tarde, você pode definir Alta Disponibilidade como Desabilitadano 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 é geralmente duas vezes no HA redundante da zona em comparação com o HA da mesma zona. Para HA de mesma zona, como a réplica primária e a réplica em espera estão na mesma zona, a latência de replicação e, consequentemente, 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 de mesma zona, 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 redundante 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 será a mesma que o tempo de inatividade da instância flexível do servidor do Banco de Dados do Azure para MySQL quando a HA estiver desabilitada.
  

• Posso fazer uma restauração point-in-time (PITR) do meu servidor HA?
  Você pode fazer um PITR para uma instância de servidor flexível do Banco de Dados do Azure habilitado para HA para MySQL para uma nova instância de 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 de mesma zona no servidor restaurado posteriormente. Se o servidor de origem tiver sido criado com HA de mesma zona, você poderá habilitar somente HA de mesma zona no servidor restaurado.
  

• Posso ativar a HA em um servidor depois de criar o servidor?
  A HA com redundância de zona precisa ser habilitada quando o servidor é criado. Você pode habilitar a HA de mesma zona depois de criar o servidor. Antes de ativar a mesma zona HA, certifique-se de que os parâmetros do servidor enforce_gtid_consistency" e "gtid_mode" estão definidos como ON
  

• 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 servidor flexível do Banco de Dados do Azure para MySQL utlizou o Failover Planejado para optar pelas operações de HA, incluindo dimensionamento 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/mesma zona) do servidor
  Se você criar o servidor com o modo HA redundante de zona habilitado, poderá mudar de HA redundante de zona para a mesma zona e vice-versa. Para alterar o modo de disponibilidade, você pode definir Alta Disponibilidade como Desabilitadono painel Alta Disponibilidade e, em seguida, defini-lo de volta para Zona Redundante ou mesma zona e escolher Modo de Alta Disponibilidade.
  

Próximos passos

• Saiba mais sobre a continuidade de negócios.
• Saiba mais sobre a alta disponibilidade com redundância de zona.
• Saiba mais sobre backup e recuperação.