O que fazemos · Dados e web: Bases de dados em cluster com Percona XtraDB Cluster
A sua aplicação fala com uma base de dados, mas por trás dela estão três cópias síncronas, cada uma em hardware separado. Uma escrita confirmada existe em todos os nós antes de a sua aplicação ouvir «OK», pelo que perder um servidor, corrigi-lo ou reiniciá-lo é trabalho de rotina, não uma falha.
O que é
O Percona XtraDB Cluster é compatível com MySQL e assenta na replicação síncrona do Galera. A sua aplicação em WordPress, Magento, PrestaShop, Laravel ou PHP à medida continua a falar MySQL simples. O que muda está por baixo: deixa de existir um único servidor de base de dados cuja falha leve o site inteiro consigo.
Emparelhamos o cluster com o ProxySQL, que envia as escritas para um nó eleito e distribui as leituras por todos. A aplicação não precisa de alterações nem de conhecer a topologia.
Como o construímos
- Três nós, três failure domains. Cada nó corre no seu próprio blade ou máquina virtual e, onde a plataforma o permite, cada um arranca e guarda os seus dados num array de storage diferente. Uma falha de host ou de array custa uma réplica, nunca o quorum.
- ProxySQL como sidecar local em cada nó web. Não há um load balancer de base de dados partilhado para se tornar o próximo single point of failure. O monitor de saúde do ProxySQL, que conhece o Galera, acompanha o estado do cluster e, se o writer cair, promove um novo em segundos.
- Leituras causais para os editores. Ativamos verificações de leitura síncronas para que um editor que grava num nó e recarrega a partir de outro veja sempre a sua própria alteração. Nenhum ticket de «o meu artigo desapareceu».
- Espaço para voltar a entrar. A cache de write sets é dimensionada para que um nó possa estar offline durante horas de manutenção e voltar a entrar de forma incremental, em vez de copiar de novo todo o conjunto de dados.
- Backups a cada trinta minutos. O Percona XtraBackup faz backups físicos a quente e consistentes, que são comprimidos e puxados para um host de backup separado. O lado de produção nunca envia nada para a infraestrutura de backup.
- Vigiado continuamente. Todos os nós estão no Percona Monitoring and Management.
No OpenShift aplicam-se as mesmas regras
Quando a base de dados corre em OpenShift ou OKD, corre como StatefulSet com anti-affinity rígida entre chassis e um PodDisruptionBudget que mantém o quorum intacto. Um reinício rolante de nós provocado por uma atualização da plataforma nunca pode assim deitar abaixo mais do que um membro da base de dados de cada vez. É o padrão de desenho que seguimos em todas as plataformas de containers, não um extra opcional.
Do que o protege
- A falha clássica: o site inteiro em baixo porque o único servidor MySQL está em baixo.
- Tempestades de deadlocks por escrever em todos os nós ao mesmo tempo, que as configurações round robin ingénuas produzem sob carga de WordPress e de plugins de e-commerce.
- Editores que perdem uma gravação porque a leitura seguinte caiu num nó que ainda não a tinha aplicado.
- Janelas de manutenção para atualizações de kernel, correções da base de dados e trabalhos de hardware.
- Um array de storage ou um chassis que leva a base de dados consigo.
- Uma atualização rolante do Kubernetes que quebra o quorum em silêncio.
Na prática
Uma plataforma de analytics. Para a plataforma de analytics e transações de um cliente construímos a camada transacional em Percona XtraDB Cluster com ProxySQL e um endereço flutuante. Antes da entrega removemos o writer de propósito; o ProxySQL passou as escritas para um nó sobrevivente e a aplicação continuou a funcionar.
Porquê a EuroVPS
- Desenhamos os failure domains, não apenas o cluster: hosts diferentes, arrays diferentes, chassis diferentes.
- Nenhum proxy de base de dados partilhado no meio. Cada nó web encaminha as suas próprias queries.
- Os backups são físicos, frequentes e puxados pelo lado do backup, nunca enviados a partir da produção.
- Testamos o failover antes da entrega, com a aplicação do cliente a correr sobre ele.
- A mesma disciplina em máquinas virtuais, bare metal e OpenShift.
Perguntas frequentes
- Temos de alterar a nossa aplicação? Não. O ProxySQL apresenta um endpoint MySQL normal. Aplicações que escrevem em tabelas não transacionais ou dependem de locking invulgar são analisadas primeiro consigo.
- É compatível com MySQL ou com MariaDB? O Percona XtraDB Cluster é um servidor compatível com MySQL. Migramos bases de dados MySQL e MariaDB para ele e verificamos character sets, plugins de autenticação e SQL modes durante a mudança.
- A replicação síncrona de três nós torna as escritas mais lentas? Cada commit espera que os outros nós o certifiquem, pelo que a latência entre nós conta. É por isso que todos os membros ficam no mesmo fabric de baixa latência num único datacenter, com as cópias offsite a cargo de réplicas assíncronas.
- Podemos executá-lo dentro do OpenShift? Sim, como StatefulSet com anti-affinity entre chassis e um PodDisruptionBudget, que é o nosso padrão para qualquer base de dados com quorum em Kubernetes.
- O que acontece durante a falha de um nó? Os nós sobreviventes mantêm o quorum e continuam a servir. O ProxySQL contorna o nó em falta e, quando este regressa, recupera o atraso de forma incremental.
Quer uma base de dados que aguenta a perda de um servidor sem se ressentir? Fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.