Conceitos de alta disponibilidade no Base de Dados do Azure para MySQL Servidor Flexível

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

Base de Dados do Azure para MySQL Servidor Flexível permite configurar alta disponibilidade com falha automática. A solução de alta disponibilidade é projetada para garantir que os dados comprometidos nunca se percam devido a falhas e que a base de dados não será um único ponto de falha na sua arquitetura de software. Quando a alta disponibilidade é configurada, o servidor flexível fornece automaticamente e gere uma réplica de espera. Está cobrado para o cálculo e armazenamento previstos para a réplica primária e secundária. Existem dois modelos arquitetónicos de elevada disponibilidade:

  • Ha redundante de zona. Esta opção é preferida para isolamento completo e redundância de infraestruturas em várias zonas de disponibilidade. Fornece o mais alto nível de disponibilidade, mas requer que você configuure a redundância de aplicação em todas as zonas. Ha redundante zona é preferido quando você quer alcançar o mais alto nível de disponibilidade contra qualquer falha de infraestrutura na zona de disponibilidade e quando a latência em toda a zona de disponibilidade é aceitável. Só pode ser ativado quando o servidor é criado. A HA redundante de zona está disponível num subconjunto de regiões de Azure onde a região suporta múltiplas zonas de disponibilidade e estão disponíveis ações de ficheiros Premium redundantes de zona .

  • HA da mesma zona. Esta opção é preferida para redundância de infraestrutura com menor latência da rede porque os servidores primários e de espera estarão na mesma zona de disponibilidade. Proporciona uma elevada disponibilidade sem a necessidade de configurar o despedimento de aplicações em todas as zonas. Ha de zona igual é preferido quando pretende atingir o mais alto nível de disponibilidade dentro de uma única zona de disponibilidade com a latência de rede mais baixa. Ha de zona igual está disponível em todas as regiões do Azure onde você pode usar Base de Dados do Azure para MySQL - Servidor Flexível.

Arquitetura HA redundante de zona

Quando implementar um servidor com HA redundante de zona, serão criados dois servidores:

  • Um servidor primário numa zona de disponibilidade
  • Um servidor de réplica de espera que tenha a mesma configuração que o servidor primário (nível 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

Pode escolher a zona de disponibilidade para a réplica primária e de espera. A colocação dos servidores de base de dados de espera e as aplicações de espera na mesma zona reduz a latência. Também permite que se prepare melhor para situações de recuperação de desastres e cenários de "zona para baixo".

Diagrama que mostra a arquitetura para zona redundante alta disponibilidade.

Os ficheiros de dados e registos estão alojados em armazenamento redundante de zona (ZRS). Os ficheiros de registo são replicados no servidor de espera através da replicação de nível de armazenamento disponível com ZRS e aplicados para stand by servidor continuamente.

Se houver um fracasso:

  • A réplica de espera está ativada.
  • Os ficheiros de registo binário do servidor primário continuam a aplicar-se ao servidor de espera para o trazer online para a última transação comprometida na primária.

Os registos em ZRS estão acessíveis mesmo quando o servidor primário não está disponível. Esta disponibilidade ajuda a garantir que não há perda de dados. Após a ativação da réplica de espera e a aplicação de registos binários, o servidor de réplica de espera atual assume o papel do servidor primário. O DNS é atualizado para que as ligações do cliente sejam direcionadas para a nova primária quando o cliente se reconectar. O failover é totalmente transparente a partir da aplicação do cliente e não requer qualquer ação da sua parte. A solução HA, em seguida, traz de volta o antigo servidor primário quando possível e coloca-o como um standby.

O nome do servidor de base de dados é utilizado para ligar as aplicações ao servidor primário. A informação de réplica de espera não está exposta para acesso direto. Os compromissos e as gravações são reconhecidos após os ficheiros de registo serem lavados no ZRS do servidor primário. Devido à tecnologia de replicação de sincronização utilizada no armazenamento do ZRS, pode esperar 5-10% de latência aumentada para a aplicação.

Cópias de segurança automáticas, tanto instantâneas como cópias de segurança de registo, são realizadas no armazenamento redundante da zona a partir do servidor de base de dados primário.

Arquitetura HA da mesma zona

Quando implementar um servidor com HA de mesma zona, dois servidores serão criados na mesma zona:

  • Um servidor primário
  • Um servidor de réplica de espera que tem a mesma configuração que o servidor primário (nível de computação, tamanho do cálculo, tamanho de armazenamento e configuração de rede)

O servidor de espera oferece redundância de infraestrutura com uma máquina virtual separada (computação). Esta redundância reduz o tempo de insuflação e a latência da rede entre a aplicação e o servidor de base de dados devido à colocação.

Diagrama que mostra a arquitetura para a alta disponibilidade da mesma zona.

Os ficheiros de dados e registos estão alojados em armazenamento localmente redundante (LRS). Os ficheiros de registo são replicados no servidor de espera através da replicação de nível de armazenamento disponível com LRS e aplicados para stand by servidor continuamente.

Se houver um fracasso:

  • A réplica de espera está ativada.
  • Os ficheiros de registo binário do servidor primário continuam a aplicar-se ao servidor de espera para o trazer online para a última transação comprometida na primária.

Os registos em LRS estão acessíveis mesmo quando o servidor primário não está disponível. Esta disponibilidade ajuda a garantir que não há perda de dados. Após a ativação da réplica de espera e a aplicação de registos binários, a réplica de espera atual assume o papel do servidor primário. O DNS é atualizado para redirecionar as ligações para a nova primária quando o cliente se reconectar. O failover é totalmente transparente a partir da aplicação do cliente e não requer qualquer ação da sua parte. A solução HA, em seguida, traz de volta o antigo servidor primário quando possível e coloca-o como um standby.

O nome do servidor de base de dados é utilizado para ligar as aplicações ao servidor primário. A informação de réplica de espera não está exposta para acesso direto. Os compromissos e as gravações são reconhecidos após os ficheiros de registo serem lavados no LRS do servidor primário. Como a réplica primária e a réplica de espera estão na mesma zona, há menos lag de replicação e menor latência entre o servidor de aplicação e o servidor de base de dados. A configuração da mesma zona não oferece alta disponibilidade quando as infraestruturas dependentes estão em baixo para a zona de disponibilidade específica. Haverá tempo de inatividade até que todos os serviços dependentes estejam de volta on-line para essa zona de disponibilidade.

As cópias de segurança automáticas, tanto as imagens instantâneas como as cópias de segurança de registo, são realizadas no armazenamento localmente redundante do servidor de base de dados primário.

Nota

Para a zona redundante e para a mesma zona HA:

  • Se houver uma falha, o tempo necessário para a réplica de standby assumir o papel de primária depende da aplicação binária de registo no standby. Por isso, recomendamos que utilize chaves primárias em todas as tabelas para reduzir o tempo de insusição. Os tempos de insusição costumam situar-se entre 60 e 120 segundos.
  • O servidor de espera não está disponível para operações de leitura ou escrita. É um standby passivo para permitir uma rápida falha.
  • Utilize sempre um nome de domínio totalmente qualificado (FQDN) para ligar ao seu servidor primário. Evite utilizar um endereço IP para ligar. Se houver uma falha, depois de as funções do servidor primário e de standby serem trocadas, um registo DNS A pode mudar. Esta alteração impediria a aplicação de se ligar ao novo servidor primário se um endereço IP for utilizado na cadeia de ligação.

Processo de failover

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

A ativação pós-falha forçada da Base de Dados do Azure para MySQL – Servidor Flexível permite forçar manualmente uma ativação pós-falha. Esta capacidade permite-lhe testar a funcionalidade com os cenários da sua aplicação e ajuda a preparem-no 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.

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

O tempo de inatividade do serviço não planeado pode ser causado por bugs de software ou falhas de infraestrutura como falhas de computação, rede ou armazenamento ou falhas de energia que afetam a disponibilidade da base 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 reconectam-se com o servidor de base de dados e retomam as 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 base de dados primário no momento da falha (como grandes transações e tempo de recuperação), o failover pode demorar mais tempo.

Como funciona a deteção automática de falhas nos servidores ativados pela HA

O servidor primário e o servidor secundário têm dois pontos finais de rede,

  • Ponto final do cliente: O cliente conecta e executa a consulta sobre a instância utilizando este ponto final.
  • Modo de Gestão: Utilizado internamente para comunicações de serviço a componentes de gestão e para ligar ao armazenamento de backend.

O componente do monitor de saúde continuamente faz as seguintes verificações

  • O monitor pings para a rede de gestão de nós Endpoint. Se esta verificação falhar duas vezes continuamente, ativa o funcionamento automático de falha. O cenário como o nó está indisponível/não responde devido a problemas de SISTEMA, problema de ligação em rede entre componentes de gestão e nós, etc. será abordado por este exame de saúde.
  • O monitor também executa uma simples consulta sobre o Exemplo. Se as consultas não funcionarem, a falha automática será acionada. Os cenários como o demônio MySQL despenhou-se/ parou/pendurou, problema de armazenamento backend, etc., será abordado por este exame de saúde.

Nota

Se houver algum problema de rede entre a aplicação e o ponto final de rede do cliente (acesso privado/público), seja na via de networking , no ponto final ou problemas de DNS no lado do cliente, o exame de saúde não monitoriza este cenário. Se estiver a utilizar o acesso privado, certifique-se de que as regras NSG para o VNet não bloqueiam a comunicação ao ponto final de rede de clientes da placa na porta 3306. Para o acesso público certifique-se de que as regras de firewall estão definidas e o tráfego de rede é permitido no porto 3306 (se o caminho da rede tiver outras firewalls). A resolução do DNS do lado da aplicação do cliente também precisa de ser cuidada.

Monitorização para alta disponibilidade

A saúde do seu HA é continuamente monitorizada e reportada na página geral. Aqui estão os estatutos de replicação:

Estado Descrição
NotEnabled Ha de zona redundante não está habilitado.
ReplicatingData O standby está a recuperar o servidor primário depois de ter sido criado.
Falha ao fazer O servidor de base de dados está em processo de falha do primário para o standby.
Bom estado de funcionamento Ha zona-redundante está num estado estável e é saudável.
Remoção doStandby Um utilizador eliminou a réplica de espera e a eliminação está em curso.

Limitações

Eis algumas considerações a ter em mente quando utiliza alta disponibilidade:

  • A alta disponibilidade redundante da zona só pode ser definida quando o servidor flexível for criado.
  • A alta disponibilidade não é suportada no nível de cálculo rebentado.
  • 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.
  • As réplicas de leitura não são suportadas para servidores HA.
  • A replicação de dados não é suportada para servidores HA.
  • O modo GTID será ligado à medida que a solução HA utiliza o GTID. Verifique se a sua carga de trabalho tem restrições ou limitações na replicação com GTIDs.

Nota

Se estiver a ativar a mesma zona de HA que o servidor criar, tem de se certificar de que os parâmetros do servidor enforce_gtid_consistency" e "gtid_mode" estão definidos para ON antes de ativar HA.

Perguntas Mais Frequentes (FAQ)

  • Como é que estou cobrado para servidores (HA) disponíveis? 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 zona redundante. Está cobrado para o cálculo e armazenamento previstos 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 a forerado, a sua réplica secundária também terá 4 vCores e 512 GB de armazenamento a provisionado. O servidor HA redundante da sua zona será faturado por 8 vCores e 1.024 GB de armazenamento. Dependendo do seu volume de armazenamento de reserva, também pode ser cobrado para armazenamento de cópias de segurança.

  • Posso usar a réplica de espera para ler ou escrever operações?
    O servidor de espera não está disponível para operações de leitura ou escrita. É um standby passivo para permitir uma rápida falha.

  • Terei perda de dados quando o fracasso acontecer?
    Os registos em ZRS estão acessíveis mesmo quando o servidor primário não está disponível. Esta disponibilidade ajuda a garantir que não há perda de dados. Após a réplica de espera ser ativada e os registos binários são aplicados, assume o papel do servidor primário.

  • Preciso de tomar alguma ação depois de um fracasso?
    As falhas são totalmente transparentes a partir da aplicação do cliente. Não precisas de tomar nenhuma ação. As aplicações devem apenas utilizar a lógica de relemgar para as suas ligações.

  • O que acontece quando não escolho uma zona específica para a minha réplica de espera? Posso mudar a zona mais tarde?
    Se não escolher uma zona, uma será selecionada aleatoriamente. Não será o usado para o servidor primário. Para alterar a zona mais tarde, pode definir Alta Disponibilidade para Desativar no painel de Alta Disponibilidade e, em seguida, repor para a Zona Redundante e escolher uma zona.

  • A replicação entre as réplicas primárias e de espera é sincronizada?
    A replicação entre o primário e o modo de espera é semelhante ao modo semissíncronos no MySQL. Quando uma transação é cometida, não se compromete necessariamente com o standby. Mas quando o primário está indisponível, o standby replica todas as alterações de dados a partir das primárias para garantir que não há perda de dados.

  • Há um falhanço na réplica de espera para todas as falhas não planeadas?
    Se houver uma falha de dados ou falha no nó, o VM do Servidor Flexível é reiniciado no mesmo nó. Ao mesmo tempo, é acionado um failover automático. Se o reinício do VM do Servidor Flexível for bem sucedido antes do fim da falha, 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.

  • Há algum impacto no desempenho quando uso HA?
    Para ha redundante zona, pode haver uma queda de 5-10 por cento na latência se a aplicação estiver conectando-se ao servidor de base de dados através de zonas de disponibilidade onde a latência da rede é relativamente maior (2-4 ms). Para ha da mesma zona, porque a réplica primária e a réplica de espera está na mesma zona, o lag de replicação é menor. Há menos latência entre o servidor de aplicações e o servidor de base de dados quando estão na mesma zona de disponibilidade do Azure.

  • Como é que a manutenção do meu servidor HA acontece?
    Eventos planeados como o dimensionamento de computação e pequenas atualizações de versão acontecem nas primárias e no standby ao mesmo tempo. Pode definir a janela de manutenção programada para servidores HA, como faz para servidores flexíveis. A quantidade de tempo de inatividade será a mesma que o tempo de inatividade para o Base de Dados do Azure para MySQL servidor flexível quando ha estiver desativado. A utilização do mecanismo de failover para reduzir o tempo de inatividade dos servidores HA está no nosso roteiro e estará disponível em breve.

  • Posso fazer uma restauração pontual (PITR) do meu servidor HA?
    Pode fazer um PITR para um servidor flexível Base de Dados do Azure para MySQL com HA para um novo servidor flexível Base de Dados do Azure para MySQL que tenha Desativado HA. Se o servidor de origem foi criado com HA redundante de zona, pode ativar ha redundante de zona ou HA de zona na mesma zona HA mais tarde. Se o servidor de origem foi criado com HA de mesma zona, pode ativar apenas ha zona da mesma zona no servidor restaurado.

  • Posso ativar ha num servidor depois de criar o servidor?
    Ha redundante de zona precisa de ser ativado quando o servidor é criado. Pode ativar 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 para ON

  • Posso desativar o HA para um servidor depois de o criar?
    Pode desativar o HA num servidor depois de o criar. A faturação para imediatamente.

  • Como posso atenuar o tempo de inatividade?
    Precisa de ser capaz de atenuar o tempo de inatividade da sua aplicação, mesmo quando não está a usar HA. O tempo de inatividade do serviço, como patches programados, atualizações de versão menores ou operações iniciadas pelo cliente como o dimensionamento do cálculo podem ser realizadas durante as janelas de manutenção programadas. Para mitigar o impacto da aplicação para tarefas de manutenção iniciadas pelo Azure, pode programar-as num dia da semana e hora que minimize o impacto na aplicação.

  • Posso usar uma réplica de leitura para um servidor ativado por HA?
    As réplicas de leitura não são suportadas para servidores HA. Esta funcionalidade está no nosso roteiro, e estamos a trabalhar para torná-la disponível em breve.

  • Posso usar a replicação de dados para servidores HA?
    A replicação de dados não é suportada para servidores HA. Mas a replicação de dados para servidores HA está no nosso roteiro e estará disponível em breve. Por enquanto, se quiser utilizar a replicação de dados para migração, pode seguir estes passos:

    1. Crie o servidor com HA redundante de zona ativado.
    2. Desativar a HA.
    3. Complete os passos para configurar a replicação de dados. (Certifique-se de que gtid_mode tem a mesma definição nos servidores de origem e alvo.)
    4. Os cortes de postamentos removem a configuração de replicação de dados.
    5. Ativar ha.
  • Para reduzir o tempo de inatividade, posso falhar no servidor de espera durante o reinício do servidor ou enquanto está a escalonar para cima ou para baixo?
    Atualmente, quando se faz uma operação de escala para cima ou para baixo, o standby e o primário são dimensionado ao mesmo tempo. Então falhar não ajuda. Permitir o escalonamento do standby primeiro, seguido de failover, e depois aumentar as primárias está no nosso roteiro, mas ainda não está suportado.

  • Podemos alterar o modo de disponibilidade (Ha/mesma zona redundante) do servidor
    Se criar o servidor com o modo HA redundante da Zona ativado, então pode mudar de HA redundante para a mesma zona e vice-versa. Para alterar o modo de disponibilidade, pode definir Alta Disponibilidade para Desativar no painel de Alta Disponibilidade e, em seguida, recossá-lo para zona redundante ou zona igual e escolher o Modo de Alta Disponibilidade.

Passos seguintes