Como escolher sua topologia de alta disponibilidade
Existem várias maneiras de manter a alta disponibilidade com bancos de dados. Você pode usar IPs virtuais (VRRP) para gerenciar a disponibilidade do host, pode usar gerenciadores de recursos como Zookeeper e Etcd para (re)configurar seus aplicativos ou usar balanceadores de carga/proxies para distribuir a carga de trabalho por todos os hosts disponíveis.
Os IPs virtuais precisam de um aplicativo para gerenciá-los (MHA, Orchestrator), algum script (Keepalived, Pacemaker/Corosync) ou um engenheiro para fazer failover manualmente e a tomada de decisão no processo pode se tornar complexa. O failover de IP virtual é um processo direto e simples, removendo o endereço IP de um host, atribuindo-o a outro e usando arping para enviar uma resposta ARP gratuita. Em teoria, um IP virtual pode ser movido em um segundo, mas levará alguns segundos antes que o aplicativo de gerenciamento de failover tenha certeza de que o host falhou e aja de acordo. Na realidade, isso deve estar em algum lugar entre 10 e 30 segundos. Outra limitação dos IPs virtuais é que alguns provedores de nuvem não permitem que você gerencie seus próprios IPs virtuais ou os atribua. Por exemplo, o Google não permite que você faça isso em seus nós de computação.
Gerenciadores de recursos como Zookeeper e Etcd podem monitorar seus bancos de dados e (re)configurar seus aplicativos quando um host falha ou um escravo é promovido a mestre. Em geral, esta é uma boa ideia, mas implementar suas verificações com Zookeeper e Etcd é uma tarefa complexa.
Um balanceador de carga ou proxy ficará entre o aplicativo e o host do banco de dados e funcionará de forma transparente como se o cliente se conectasse diretamente ao host do banco de dados. Assim como com o IP virtual e os gerenciadores de recursos, os balanceadores de carga e proxies também precisam monitorar os hosts e redirecionar o tráfego se um host estiver inativo. ClusterControl suporta dois proxies:HAProxy e ProxySQL e ambos são suportados para replicação mestre-escravo MySQL e cluster Galera. HAProxy e ProxySQL ambos têm seus próprios casos de uso, vamos descrevê-los neste post também.
Por que você precisa de um balanceador de carga?
Em teoria você não precisa de um balanceador de carga, mas na prática você vai preferir um. Explicaremos o porquê.
Se você tiver configuração de IPs virtuais, tudo o que você precisa fazer é apontar seu aplicativo para o endereço IP (virtual) correto e tudo deve estar bem na conexão. Mas suponha que você tenha dimensionado o número de réplicas de leitura, você também pode querer fornecer IPs virtuais para cada uma dessas réplicas de leitura por motivos de manutenção ou disponibilidade. Isso pode se tornar um pool muito grande de IPs virtuais que você precisa gerenciar. Se uma dessas réplicas de leitura tiver uma falha, você precisará reatribuir o IP virtual a outro host, caso contrário, seu aplicativo se conectará a um host que está inativo ou, na pior das hipóteses, a um servidor atrasado com dados obsoletos. Portanto, é necessário manter o estado de replicação para o aplicativo que gerencia os IPs virtuais.
Também para o Galera há um desafio semelhante:você pode, em teoria, adicionar quantos hosts desejar à configuração do seu aplicativo e escolher um aleatoriamente. O mesmo problema surge quando este host está inativo:você pode acabar se conectando a um host indisponível. Também usar todos os hosts para leituras e gravações também pode causar rollbacks devido ao bloqueio otimista no Galera. Se duas conexões tentarem gravar na mesma linha ao mesmo tempo, uma delas receberá uma reversão. Caso sua carga de trabalho tenha essas atualizações simultâneas, é aconselhável usar apenas um nó no Galera para gravar. Portanto, você deseja um gerenciador que acompanhe o estado interno de seu cluster de banco de dados.
Tanto o HAProxy quanto o ProxySQL oferecem a você a funcionalidade de monitorar os hosts do banco de dados MySQL/MariaDB e manter o estado do seu cluster e sua topologia. Para configurações de replicação, caso uma réplica escrava esteja inativa, tanto o HAProxy quanto o ProxySQL podem redistribuir as conexões para outro host. Mas se um mestre de replicação estiver inativo, o HAProxy negará a conexão e o ProxySQL retornará um erro adequado ao cliente. Para configurações do Galera, ambos os balanceadores de carga podem eleger um nó mestre do cluster Galera e enviar apenas as operações de gravação para esse nó específico.
À primeira vista, HAProxy e ProxySQL podem parecer soluções semelhantes, mas diferem muito em recursos e na maneira como distribuem conexões e consultas. O HAProxy oferece suporte a vários algoritmos de balanceamento, como conexões mínimas, origem, aleatório e round-robin, enquanto o ProxySQL distribui conexões usando o algoritmo round-robin baseado em peso (peso igual significa distribuição igual). Como o ProxySQL é um proxy inteligente, ele reconhece o banco de dados e também é capaz de analisar suas consultas. O ProxySQL é capaz de fazer divisão de leitura/gravação com base em regras de consulta, onde você pode encaminhar as consultas para os escravos ou mestres designados em seu cluster. O ProxySQL inclui funcionalidades adicionais como reescrita de consultas, armazenamento em cache e firewall de consultas com geração de estatísticas detalhadas e em tempo real sobre a carga de trabalho.
Isso deve ser informações básicas suficientes sobre este tópico, então vamos ver como você pode implantar os balanceadores de carga para replicação MySQL e topologias Galera.
Implantando o HAProxy
Usar o ClusterControl para implantar o HAProxy em um cluster Galera é fácil:acesse o cluster relevante e selecione “Add Load Balancer”:
E você poderá implantar uma instância HAProxy adicionando o endereço do host e selecionando as instâncias do servidor que deseja incluir na configuração:
Por padrão, a instância do HAProxy será configurada para enviar conexões para as instâncias do servidor que recebem o menor número de conexões, mas você pode alterar essa política para round robin ou origem.
Nas configurações avançadas, você pode definir tempos limite, quantidade máxima de conexões e até proteger o proxy, colocando um intervalo de IP na lista de permissões para as conexões.
Na guia de nós desse cluster, o nó HAProxy aparecerá:
Agora, seu cluster Galera também está disponível por meio do nó HAProxy recém-implantado na porta 3307. Não se esqueça de CONCEDER o acesso ao seu aplicativo a partir do IP do HAProxy, pois agora o tráfego será de entrada do proxy em vez dos hosts do aplicativo. Além disso, lembre-se de apontar sua conexão de aplicativo para o nó HAProxy.
Agora suponha que uma instância do servidor fique inativa, o HAProxy notará isso em alguns segundos e parará de enviar tráfego para esta instância:
Os outros dois nós ainda estão bem e continuarão recebendo tráfego. Isso mantém o cluster altamente disponível sem que o cliente perceba a diferença.
Implantando um nó HAProxy secundário
Agora que transferimos a responsabilidade de manter a alta disponibilidade nas conexões de banco de dados do cliente para o HAProxy, e se o nó proxy morrer? A resposta é criar outra instância do HAProxy e usar um IP virtual controlado pelo Keepalived conforme mostrado neste diagrama:
O benefício comparado ao uso de IPs virtuais nos nós do banco de dados é que a lógica do MySQL está no nível de proxy e o failover para os proxies é simples.
Então, vamos implantar um nó HAProxy secundário:
Depois de implantar um nó HAProxy secundário, precisamos adicionar Keepalived:
E depois que Keepalived for adicionado, sua visão geral de nós ficará assim:
Portanto, agora, em vez de apontar suas conexões de aplicativo para o nó HAProxy diretamente, você precisa apontá-las para o IP virtual.
No exemplo aqui, usamos hosts separados para executar o HAProxy, mas você também pode adicioná-los facilmente a instâncias de servidor existentes. O HAProxy não traz muita sobrecarga, embora você deva ter em mente que, em caso de falha do servidor, você perderá o nó do banco de dados e o proxy.
Implantando ProxySQL
A implantação do ProxySQL em seu cluster é feita de maneira semelhante ao HAProxy:"Add Load Balancer" na lista de clusters na guia ProxySQL.
No assistente de implementação, especifique onde o ProxySQL será instalado, o usuário/senha de administração, o usuário/senha de monitoramento para conectar-se aos backends do MySQL. A partir do ClusterControl, você pode criar um novo usuário para ser usado pelo aplicativo (o usuário será criado no MySQL e no ProxySQL) ou usar os usuários do banco de dados existentes (o usuário será criado apenas no ProxySQL). Defina se você está usando transações implícitas ou não. Basicamente, se você não usar SET autocommit=0 para criar uma nova transação, o ClusterControl configurará a divisão de leitura/gravação.
Após a implantação do ProxySQL, ele estará disponível na guia Nós:
A abertura da visão geral do nó ProxySQL apresentará a interface de monitoramento e gerenciamento do ProxySQL, portanto, não há mais motivo para efetuar login no ProxySQL no nó. O ClusterControl cobre a maioria das estatísticas importantes do ProxySQL, como utilização de memória, cache de consulta, processador de consulta e assim por diante, bem como outras métricas, como grupos de hosts, servidores de back-end, ocorrências de regras de consulta, consultas principais e variáveis ProxySQL. No aspecto de gerenciamento do ProxySQL, você pode gerenciar as regras de consulta, servidores back-end, usuários, configuração e agendador diretamente da interface do usuário.
Confira nossa página de tutorial do ProxySQL, que aborda extensivamente como executar o balanceamento de carga do banco de dados para MySQL e MariaDB com ProxySQL.
Implantando Garbd
Galera implementa um algoritmo baseado em quorum para selecionar um componente primário através do qual impõe consistência. O componente primário precisa ter a maioria dos votos (50% + 1 nó), portanto, em um sistema de 2 nós, não haveria maioria resultando em cérebro dividido. Felizmente, é possível adicionar um garbd (Galera Arbitrator Daemon), que é um daemon sem estado leve que pode atuar como um nó ímpar. O benefício adicional de adicionar o Galera Arbitrator é que agora você pode fazer com apenas dois nós em seu cluster.
Se o ClusterControl detectar que seu cluster Galera consiste em um número par de nós, você receberá o aviso/conselho do ClusterControl para estender o cluster para um número ímpar de nós:
Escolha sabiamente o host para implantar o garbd, pois ele receberá todos os dados replicados. Certifique-se de que a rede pode lidar com o tráfego e é segura o suficiente. Você pode escolher um dos hosts HAProxy ou ProxySQL para implantar o garbd, como no exemplo abaixo:
Observe que a partir do ClusterControl 1.5.1, o garbd não pode ser instalado no mesmo host que o ClusterControl devido ao risco de conflitos de pacote.
Depois de instalar o garbd, você o verá ao lado de seus dois nós Galera:
Considerações finais
Mostramos como tornar suas configurações de cluster MySQL mestre-escravo e Galera mais robustas e manter alta disponibilidade usando HAProxy e ProxySQL. Também garbd é um daemon legal que pode salvar o terceiro nó extra em seu cluster Galera.
Isso finaliza o lado de implantação do ClusterControl. Em nosso próximo blog, mostraremos como integrar o ClusterControl em sua organização usando grupos e atribuindo determinadas funções aos usuários.
