Este documento descreve várias arquiteturas que oferecem alta disponibilidade (HA) para implementações do MySQL no Google Cloud. A HA é a medida da resiliência do sistema em resposta a falhas da infraestrutura subjacente. Neste documento, a HA aborda a disponibilidade de clusters do MySQL numa única região da nuvem.
Este documento destina-se a administradores de bases de dados, arquitetos da nuvem e engenheiros de DevOps que querem saber como aumentar a fiabilidade da camada de dados do MySQL melhorando o tempo de atividade geral do sistema. Este documento destina-se a si se estiver a executar o MySQL no Compute Engine. Se usar o Cloud SQL para MySQL, este documento não se destina a si.
Para um sistema ou uma aplicação que requer um estado persistente para processar pedidos ou transações, a camada de persistência de dados tem de estar disponível para processar com êxito pedidos de consultas ou mutações de dados. Se a aplicação tiver de interagir com a camada de dados para processar pedidos, qualquer tempo de inatividade na camada de dados impede a aplicação de realizar as tarefas necessárias.
Consoante os objetivos ao nível do serviço (SLOs) do sistema, pode precisar de uma topologia arquitetónica que ofereça um nível de disponibilidade mais elevado. Existem várias formas de alcançar a HA, mas, em geral, aprovisiona uma infraestrutura redundante que pode tornar rapidamente acessível à sua aplicação.
Este documento aborda os seguintes tópicos:
- Defina termos para ajudar a compreender os conceitos de base de dados de HA.
- Ajudar a compreender várias opções para topologias MySQL de HA.
- Fornecer informações contextuais para ajudar a compreender o que deve considerar em cada opção.
Terminologia
Existem vários termos e conceitos que são padrão da indústria e úteis para compreender para fins que vão além do âmbito deste documento.
Replicação. O processo através do qual as transações de escrita (INSERT, UPDATE ou DELETE) são captadas, registadas e, em seguida, aplicadas em série a todos os nós da base de dados na topologia.
Replicação síncrona. Um método de replicação de dados que garante a consistência dos dados em tempo real escrevendo simultaneamente nas bases de dados primárias e de réplica.
Replicação semissíncrona. Um método de replicação de dados que garante um grau limitado de consistência dos dados ao escrever simultaneamente na base de dados principal e, pelo menos, noutra base de dados replicada.
Replicação assíncrona. Um método de replicação de dados que permite um atraso entre as atualizações primárias e de réplica, dando prioridade ao desempenho em detrimento da consistência imediata.
Nó de origem. Todas as gravações na base de dados têm de ser direcionadas para um nó de origem. O nó de origem fornece uma leitura com o estado mais atualizado dos dados persistentes.
Nó de réplica. Uma cópia online do nó da base de dados de origem. As alterações são replicadas quase em simultâneo para os nós de réplica a partir do nó de origem. Pode ler a partir de nós de réplica, tendo em atenção que os dados podem estar ligeiramente atrasados devido ao intervalo de tempo da replicação.
Atraso na replicação. Uma medição de tempo que expressa a diferença entre o momento em que uma transação é aplicada à réplica em comparação com o momento em que é aplicada ao nó de origem.
Tempo de atividade. A percentagem do tempo em que um recurso está a funcionar e é capaz de enviar uma resposta a um pedido.
Deteção de falhas. O processo de identificar que ocorreu uma falha de infraestrutura.
Failover. O processo para promover a infraestrutura de reserva (neste caso, o nó de réplica) para se tornar a infraestrutura principal (o nó de origem).
Objetivo de tempo de recuperação (OTR). A duração, em tempo real decorrido, que é aceitável, do ponto de vista empresarial, para que o nível de dados fique offline até que o processo de comutação por falha seja concluído.
Objetivo de ponto de recuperação (OPR). A duração, em tempo real decorrido, que é aceitável, do ponto de vista empresarial, para que os dados sejam perdidos até que o processo de comutação por falha seja concluído.
Alternativo. O processo para repor o nó de origem anterior após uma comutação por falha.
Autorreparação. A capacidade de um sistema resolver problemas sem ações externas por parte de um operador humano.
Partição de rede. Uma condição em que dois nós numa topologia, por exemplo, os nós de origem e de réplica, não conseguem comunicar entre si através da rede.
Cérebro dividido. Uma condição que ocorre quando dois nós acreditam simultaneamente que são o nó de origem.
Grupo de nós. Um conjunto de tarefas de recursos de computação que fornecem um serviço. Para este documento, esse serviço é o nível de persistência de dados.
Nó de testemunha ou quórum. Um recurso de computação separado que ajuda um grupo de nós a determinar o que fazer quando ocorre uma condição de divisão de cérebro.
Eleição de origem ou líder. O processo através do qual um grupo de nós com reconhecimento de pares, incluindo nós de testemunho, determina qual deve ser o nó de origem.
Grupo de nós. Um conjunto de tarefas de recursos de computação que fornecem um serviço. Para este documento, esse serviço é o nível de persistência de dados.
Hot standby. Um nó que representa uma cópia exata de outro nó de origem e que pode tornar-se o novo nó de origem com um tempo de inatividade mínimo.
Quando deve considerar uma arquitetura de HA
As arquiteturas de HA oferecem maior proteção contra o tempo de inatividade da camada de dados. Compreender a sua tolerância a tempo de inatividade e as respetivas compensações das várias arquiteturas é fundamental para escolher a opção adequada ao seu exemplo de utilização de empresa.
Use uma topologia de AD quando quiser oferecer um tempo de atividade da camada de dados aumentado para cumprir os requisitos de fiabilidade para as suas cargas de trabalho e serviços. Para ambientes onde é tolerada alguma indisponibilidade, uma topologia de HA introduz custos e complexidade desnecessários. Por exemplo, os ambientes de desenvolvimento ou teste raramente precisam de uma disponibilidade de nível de base de dados elevada.
Considere os seus requisitos de HA
O custo é uma consideração importante, uma vez que deve esperar que os custos de armazenamento e infraestrutura de computação, pelo menos, dupliquem para fornecer HA. É importante que avalie cuidadosamente este custo em função do potencial impacto financeiro da inatividade. Quando avaliar as possíveis opções de HA do MySQL, considere as seguintes perguntas:
- Que serviços ou clientes dependem do seu nível de dados?
- Qual é o seu orçamento operacional?
- Qual é o custo para a sua empresa em caso de tempo de inatividade na camada de persistência de dados?
- Quão automatizado tem de ser o processo?
- Que nível de disponibilidade espera alcançar: 99,5%, 99,9% ou 99,99%?
- Com que rapidez precisa de fazer a comutação por falha? Quais são o seu RTO e RPO?
Os seguintes fatores contribuem para o tempo de recuperação e devem ser considerados quando estabelecer o RTO e o RPO:
- Deteção da indisponibilidade
- Disponibilidade da instância de máquina virtual (VM) secundária
- Tipo de replicação e frequência de cópia de segurança
- Failover de armazenamento
- Tempo de recuperação da base de dados
- Tempo de recuperação da aplicação
Arquiteturas de HA do MySQL
Ao nível mais básico, a HA na camada de dados consiste no seguinte:
- Um mecanismo para identificar que ocorreu uma falha no nó de origem.
- Um processo para realizar uma comutação por falha em que o nó de réplica é promovido a nó de origem.
- Um processo para alterar o encaminhamento de consultas de modo que os pedidos da aplicação cheguem ao novo nó de origem.
- Opcionalmente, um método para reverter para a topologia original através de nós de origem e réplica.
Este documento aborda as três arquiteturas de HA seguintes:
Além da falha de infraestrutura, cada uma destas arquiteturas pode ajudar a minimizar o tempo de inatividade no caso improvável de uma interrupção zonal. Usa estas arquiteturas com alterações ao Sistema de Nomes de Domínio (DNS) para fornecer HA multirregional para se proteger contra interrupções de serviço regionais, mas este documento aborda interrupções zonais.
HA com discos persistentes regionais
A HA na camada de dados baseia-se sempre num tipo de replicação de dados. A replicação mais simples é aquela que não tem de gerir.
Com a opção de armazenamento do disco persistente regional do Compute Engine, pode aprovisionar um dispositivo de armazenamento em blocos que oferece replicação de dados síncrona entre duas zonas numa região. Os discos persistentes regionais oferecem uma base sólida para a implementação de serviços de HA no Compute Engine.
O diagrama seguinte ilustra a arquitetura da HA com discos persistentes regionais.
Se a instância de VM do nó de origem ficar indisponível devido a uma falha de infraestrutura ou a uma indisponibilidade zonal, pode forçar a ligação do disco persistente regional a uma instância de VM na sua zona de cópia de segurança na mesma região.
Para realizar esta tarefa, tem de efetuar uma das seguintes ações:
- Inicie outra instância de VM na zona de cópia de segurança onde o acesso ao disco persistente regional partilhado está disponível.
- Mantenha uma instância de VM de espera ativa na zona de cópia de segurança. Uma instância de VM de standby a quente é uma instância de VM em execução idêntica à instância que está a usar. Depois de anexar o disco persistente regional, pode iniciar o motor da base de dados.
Se a indisponibilidade do serviço de dados for identificada rapidamente, a operação de associação forçada normalmente é concluída em menos de um minuto, o que significa que é possível alcançar um RTO medido em minutos, com um RPO zero.
Se a sua empresa puder tolerar o tempo de inatividade adicional necessário para detetar e comunicar uma indisponibilidade, e para realizar a comutação por falha manualmente, não é necessário automatizar o processo.
Se a tolerância de RTO for inferior, pode automatizar o processo de deteção e comutação por falha. Se automatizar esta arquitetura, o sistema torna-se ainda mais complicado, porque existem vários casos extremos no processo de ativação pós-falha e alternativa que tem de considerar. Para mais informações sobre uma implementação totalmente automatizada desta arquitetura, consulte a configuração de alta disponibilidade do Cloud SQL.
Vantagens
Existem várias vantagens em alcançar a HA através da utilização de discos persistentes regionais devido às seguintes funcionalidades:
Esta arquitetura oferece proteção simultânea contra vários modos de falha: falha da infraestrutura da zona do servidor de origem, degradação do armazenamento em blocos de zona única ou interrupção total da zona.
A replicação da camada de aplicação ou de base de dados não é necessária porque os discos persistentes regionais oferecem replicação de dados contínua e síncrona ao nível do bloco, que é totalmente gerida pelo Google Cloud. Um disco persistente regional deteta automaticamente erros e lentidão, muda o modo de replicação e sincroniza os dados replicados para apenas uma zona.
Se existirem problemas de armazenamento numa zona principal, um disco persistente regional faz automaticamente leituras a partir da zona secundária. Esta operação pode resultar num aumento da latência de leitura, mas a sua aplicação pode continuar a funcionar sem qualquer ação manual.
Considerações
As limitações desta arquitetura estão relacionadas com a natureza de região única desta topologia e algumas das seguintes restrições inerentes dos discos persistentes regionais:
- O disco persistente regional só pode ser montado numa base de dados. Mesmo que a instância de VM da base de dados em espera esteja em execução, essa instância não pode ser usada para publicar leituras da base de dados. No entanto, com o Google Cloud Hyperdisk Balanced de alta disponibilidade no modo de gravação múltipla, várias instâncias podem ler e escrever no mesmo disco. Para mais informações sobre o Hyperdisk, consulte o artigo Acerca do Hyperdisk.
- A tecnologia fundamental por detrás desta arquitetura só permite a replicação entre zonas na região mesma. Como resultado, a comutação por falha regional não é uma opção quando usa apenas esta arquitetura.
- O débito de escrita do disco persistente regional é reduzido para metade em comparação com os discos persistentes zonais. Certifique-se de que os limites de débito estão dentro da tolerância necessária.
- A latência de escrita do disco persistente regional é ligeiramente superior à do disco persistente zonal. Recomendamos que teste a sua carga de trabalho para verificar se o desempenho de gravação é aceitável para os seus requisitos.
- Durante um evento de falha e a comutação resultante, tem de forçar a ligação do disco persistente regional à VM da zona de espera. Normalmente, a operação de anexação forçada é executada em menos de um minuto, pelo que tem de considerar este tempo ao avaliar o RTO.
- A estimativa do RTO tem de ter em conta o tempo necessário para a associação forçada do disco persistente regional e a deteção do sistema de ficheiros da VM do disco associado a quente.
HA com espera ativa e nó de testemunho
Se quiser uma comutação por falha automática, é necessária uma arquitetura diferente. Uma opção é implementar um grupo de, pelo menos, dois nós de base de dados, configurar a replicação assíncrona da base de dados e iniciar nós de testemunho para ajudar a garantir que é possível atingir um quórum durante uma eleição de nó de origem.
O nó da base de dados de origem processa transações de escrita e serve consultas de leitura. O processo de replicação da base de dados transmite as alterações ao nó de réplica de standby a quente online.
Uma vez que o nó de testemunho pode ser uma pequena máquina virtual, oferece um mecanismo de baixo custo para garantir que uma maioria do grupo está disponível para uma eleição de nó de origem.
Os nós de grupo avaliam continuamente o estado dos outros nós de grupo. Os sinais que estas verificações de estado consomem a cada poucos segundos são denominados batimentos cardíacos porque são usados para avaliar o estado de funcionamento dos outros nós do grupo. Uma avaliação atempada do estado de funcionamento do nó da base de dados é importante porque um nó da base de dados de origem com problemas de funcionamento tem de ser identificado rapidamente para que seja possível iniciar uma comutação por falha do modo de espera ativo.
O quórum do grupo de nós é determinado pelo número de elementos de votação que têm de fazer parte da associação ativa do cluster para que esse cluster seja iniciado corretamente ou continue a ser executado. Para um grupo de nós atingir um quórum numa eleição de nós da base de dados de origem, a maioria dos nós no grupo tem de participar. Para evitar uma condição de divisão cerebral, o requisito de maioria garante que, no caso de uma partição de rede, dois grupos de votação não podem ter simultaneamente nós suficientes para votar.
Uma maioria de um grupo consiste em (n+1)/2 nós, em que n é o número total de nós no grupo. Por exemplo, se existirem três nós num grupo, pelo menos dois nós têm de estar em funcionamento para uma eleição de nó de origem. Se existirem cinco nós num grupo, são necessários, pelo menos, três nós.
Os grupos têm um número ímpar de nós caso exista uma partição de rede que impeça a comunicação entre subgrupos do grupo de nós. Se o grupo for par, existe uma maior probabilidade de ambos os subgrupos terem menos do que a maioria. Se o tamanho do grupo for ímpar, é mais provável que um dos subgrupos tenha uma maioria ou que nenhum dos grupos tenha uma maioria.
O diagrama seguinte compara um grupo de nós em bom estado com um grupo de nós degradado.
O diagrama mostra dois grupos de nós: um grupo de nós funcional e um grupo de nós degradado. O grupo de nós totalmente funcional e em bom estado tem três membros do grupo. Neste estado, os nós da base de dados de origem e de réplica estão a cumprir o objetivo esperado. O quórum necessário para este grupo de nós é de dois nós.
O grupo de nós degradado mostra o estado em que os sinais de pulsação do nó de origem já não são enviados devido a uma falha de infraestrutura. Este estado pode ser o resultado de uma falha na instância do nó da base de dados de origem ou o nó de origem pode ainda estar em execução. Em alternativa, uma partição de rede pode impedir a comunicação entre o nó de origem e os outros nós no grupo.
Independentemente da causa, o resultado é que a réplica e o testemunho determinam que o nó de origem já não está em bom estado. Neste ponto, a maioria do grupo realiza uma eleição do nó de origem, determina que o nó de reserva a quente deve tornar-se o nó de origem e inicia uma comutação por falha.
O diagrama seguinte mostra a transação da base de dados, a replicação e o fluxo de sinal de pulsação na arquitetura do nó testemunha.
No diagrama anterior, esta arquitetura de HA baseia-se no nó de réplica de espera ativa para iniciar rapidamente o processamento de gravações de produção após uma comutação por falha. A mecânica da comutação por falha, por exemplo, a promoção do nó de origem, é realizada pelos nós da base de dados no grupo.
Para implementar esta arquitetura, considere os dois projetos seguintes:
- A replicação de grupos do MySQL é um plug-in de código aberto para o MySQL que facilita a criação de topologias de HA.
- O Galera Cluster e o Percona XtraDB Cluster são outras opções de código aberto que podem oferecer elevada disponibilidade.
Vantagens
A arquitetura de espera a quente tem poucas peças móveis, é simples de implementar e oferece várias vantagens:
- Com apenas um nó de testemunho adicional de baixo custo, é fornecida uma comutação por falha totalmente automática.
- Esta arquitetura pode resolver eficazmente falhas de infraestrutura a longo prazo e falhas transitórias (por exemplo, devido a um reinício do sistema).
- A HA multirregional é fornecida com alguma latência de replicação associada.
Considerações
A comutação por falha é automática. No entanto, as seguintes tarefas operacionais permanecem:
- Faz a gestão da replicação entre os nós de origem e de réplica.
- Gerir os nós de testemunha.
- Tem de implementar e gerir o encaminhamento de ligações através de um balanceador de carga.
- Sem alterações à lógica da sua aplicação, que estão fora do âmbito deste documento, não pode direcionar as leituras para o nó de réplica.
HA com Orchestrator e ProxySQL
Se combinar os componentes de código aberto, Orchestrator e ProxySQL, tem uma arquitetura que pode detetar interrupções e fazer automaticamente o failover do tráfego de um nó de origem afetado para uma réplica saudável recentemente promovida.
Além disso, pode encaminhar consultas de forma transparente para os nós de leitura ou de leitura e escrita adequados para melhorar o desempenho da camada de dados em estado estacionário.
O Orchestrator é um gestor de topologia de replicação do MySQL de código aberto e uma solução de comutação por falha. O software permite-lhe detetar, consultar e refatorar topologias de replicação complexas, e oferece deteção de falhas fiável, recuperação inteligente e promoção.
O ProxySQL é um proxy de código aberto, de elevado desempenho e altamente disponível com reconhecimento de protocolos de base de dados para o MySQL. O ProxySQL é dimensionado para milhões de ligações em centenas de milhares de servidores de back-end.
O diagrama seguinte mostra a arquitetura combinada do Orchestrator e do ProxySQL.
Nesta arquitetura, conforme ilustrado no diagrama anterior, o tráfego associado à base de dados é encaminhado por um equilibrador de carga interno para instâncias do ProxySQL redundantes. Estas instâncias encaminham o tráfego para uma instância de base de dados com capacidade de leitura ou escrita com base na configuração do ProxySQL.
O Orchestrator fornece os seguintes passos de deteção e recuperação de falhas:
- O orquestrador determina que o nó da base de dados de origem não está disponível.
- Todos os nós de réplica são consultados para fornecer uma segunda opinião sobre o estado do nó de origem.
- Se as réplicas fornecerem uma avaliação consistente de que a origem não está disponível, a comutação por falha prossegue.
- Conforme definido pela topologia, o nó promovido torna-se o novo nó de origem durante a comutação por falha.
- Quando a comutação por falha estiver concluída, o Orchestrator ajuda a garantir que o número correto de novos nós de replicação é aprovisionado de acordo com a topologia.
A replicação contínua entre a base de dados de origem na zona A e as réplicas da base de dados em zonas alternativas mantém as réplicas atualizadas com todas as gravações encaminhadas para a origem. O orquestrador verifica o estado de funcionamento das bases de dados de origem e de réplica enviando continuamente sinais de pulsação. O estado da aplicação do orquestrador é mantido numa base de dados do Cloud SQL separada. Se forem necessárias alterações na topologia, o Orchestrator também pode enviar comandos para as bases de dados.
O ProxySQL encaminha o tráfego adequadamente para os novos nós de origem e réplica quando a comutação por falha estiver concluída. Os serviços continuam a aceder à camada de dados através do endereço IP do balanceador de carga. O endereço IP virtual é comutado sem problemas do nó de origem anterior para o novo nó de origem.
Vantagens
Os componentes arquitetónicos e a automatização oferecem as seguintes vantagens:
- O software usado nesta arquitetura oferece várias funcionalidades de observabilidade, incluindo gráficos de topologia de replicação e visibilidade do tráfego de consultas.
- O ProxySQL e o Orchestrator coordenam-se para fornecer a promoção automática de réplicas e a comutação por falha.
- A política de promoção de réplicas é totalmente configurável. Ao contrário de outras configurações de HA, pode optar por promover um nó de réplica específico para a origem em caso de comutação por falha.
- Após uma comutação por falha, são aprovisionadas novas réplicas de forma declarativa de acordo com a topologia.
- O ProxySQL oferece uma vantagem de equilíbrio de carga suplementar, uma vez que encaminha de forma transparente os pedidos de leitura e escrita para os nós de origem e réplica adequados com base nas políticas configuradas.
Considerações
Esta arquitetura aumenta a responsabilidade operacional e incorre em custos de alojamento adicionais devido às seguintes considerações:
- O Orchestrator e o ProxySQL têm de ser implementados e mantidos.
- O Orchestrator precisa de uma base de dados separada para manter o estado.
- O Orchestrator e o ProxySQL têm de ser configurados para HA, pelo que existe uma complexidade de configuração e implementação adicional.
Além disso, o Orchestrator não suporta replicações de várias origens, não suporta todos os tipos de replicação paralela e não pode ser combinado com software de clustering, como o Galera ou o Percona XtraDB. Para mais informações sobre as limitações atuais, consulte as Perguntas frequentes sobre o Orchestrator.
O que se segue?
- Leia sobre a configuração de alta disponibilidade do Cloud SQL.
- Saiba mais sobre as opções de alta disponibilidade com discos persistentes regionais.
- Reveja a documentação da replicação de grupos do MySQL.
- Saiba mais sobre o Galera Cluster ou o Percona XtraDB Cluster relacionado.
- Reveja a documentação do Orchestrator.
- Saiba mais acerca do ProxySQL.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.