Na primeira parte da série, mostramos como implantar uma configuração de Replicação MySQL com ProxySQL com WHM e cPanel. Nesta parte, mostraremos algumas operações pós-implantação para manutenção, gerenciamento, failover, bem como vantagens sobre a configuração autônoma.
Gerenciamento de usuários do MySQL
Com esta integração habilitada, o gerenciamento de usuários MySQL terá que ser feito a partir do WHM ou cPanel. Caso contrário, a tabela mysql_users do ProxySQL não sincronizaria com o que está configurado para nosso mestre de replicação. Suponha que já criamos um usuário chamado manyn_user1 (o nome de usuário do MySQL é prefixado automaticamente pelo cPanel para cumprir a limitação do MySQL), e gostaríamos de atribuir ao banco de dados váriosn_db1 como abaixo:
O resultado acima resultará na seguinte saída da tabela mysql_users no ProxySQL:
Se você gostaria de criar recursos MySQL fora do cPanel, você pode usar ClusterControl -> Manage -> Schemas and Users recurso e, em seguida, importe o usuário do banco de dados para o ProxySQL acessando ClusterControl -> Nós -> escolha o nó ProxySQL -> Usuários -> Importar usuários .
O módulo Proxysqlhook que usamos para sincronizar usuários do ProxySQL envia os logs de depuração para /usr/local/cpanel/logs/error_log. Use este arquivo para inspecionar e entender o que acontece nos bastidores. As seguintes linhas apareceriam no arquivo de log do cPanel se instalássemos um aplicativo da web chamado Zikula usando o Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Você veria algumas linhas repetidas como "Verificando se {usuário de banco de dados} existe" porque o WHM cria vários usuários/hosts do MySQL para cada solicitação de criação de usuário de banco de dados. Em nosso exemplo, o WHM criaria esses 3 usuários:
O ProxySQL precisa apenas do nome de usuário, senha e informações do grupo de host padrão ao adicionar um usuário. Portanto, as linhas de verificação existem para evitar múltiplas inserções do mesmo usuário.
Se você quiser modificar o módulo e fazer algumas melhorias nele, não se esqueça de registrar novamente o módulo executando o seguinte comando no servidor WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookMonitoramento e armazenamento de consultas
Com o ProxySQL, você pode monitorar todas as consultas provenientes da aplicação que foram passadas ou estão passando por ela. O WHM padrão não fornece esse nível de detalhes no monitoramento de consultas do MySQL. Veja a seguir todas as consultas do MySQL que foram capturadas pelo ProxySQL:
Com o ClusterControl, você pode facilmente pesquisar as consultas mais repetidas e armazená-las em cache por meio do recurso de cache de consultas ProxySQL. Use o menu suspenso "Ordenar por" para classificar as consultas por "Contagem de estrelas", passe para a consulta que deseja armazenar em cache e clique no botão "Consulta de cache" abaixo dela. A seguinte caixa de diálogo aparecerá:
O conjunto de resultados de consultas armazenadas em cache será armazenado e servido pelo próprio ProxySQL, reduzindo o número de acessos ao backend que descarregará seu cluster de replicação MySQL como um todo. A implementação do cache de consulta ProxySQL é fundamentalmente diferente do cache de consulta MySQL. É um cache baseado em tempo e expirará após um tempo limite chamado "Cache TTL". Nesta configuração, gostaríamos de armazenar em cache a consulta acima por 5 segundos (5000 ms) para atingir o grupo de leitores onde o hostgroup de destino é 20.
Divisão e balanceamento de leitura/gravação
Ao ouvir a porta padrão 3306 do MySQL, o ProxySQL está agindo como o próprio servidor MySQL. Ele fala protocolos MySQL no frontend e no backend. As regras de consulta definidas pelo ClusterControl ao configurar o ProxySQL dividirão automaticamente todas as leituras (^SELECT .* na linguagem Regex) para o hostgroup 20 que é o grupo de leitores, e o restante será encaminhado para o hostgroup 10 do gravador, conforme mostrado na seguinte seção de regras de consulta:
Com essa arquitetura, você não precisa se preocupar em dividir as consultas de leitura/gravação, pois o ProxySQL fará o trabalho para você. Os usuários têm alterações mínimas ou nenhuma no código, permitindo que os usuários de hospedagem usem todos os aplicativos e recursos fornecidos pelo WHM e cPanel nativamente, semelhante à conexão a uma configuração autônoma do MySQL.
Em termos de balanceamento de conexão, se você tiver mais de um nó ativo em um hostgroup específico (como o hostgroup 20 do leitor neste exemplo), o ProxySQL distribuirá automaticamente a carga entre eles com base em vários critérios - pesos, atraso de replicação, conexões usadas , carga geral e latência. O ProxySQL é conhecido por ser muito bom em ambientes de alta simultaneidade, implementando um mecanismo avançado de pool de conexões. Citado na postagem do blog ProxySQL, o ProxySQL não apenas implementa a conexão persistente, mas também a multiplexação de conexão. Na verdade, o ProxySQL pode lidar com centenas de milhares de clientes e ainda encaminhar todo o tráfego para poucas conexões com o back-end. Portanto, o ProxySQL pode lidar com N conexões de clientes e M conexões de back-end, onde N> M (mesmo N milhares de vezes maiores que M).
Failover e recuperação do MySQL
Com o ClusterControl gerenciando o cluster de replicação, o failover é executado automaticamente se a recuperação automática estiver habilitada. Em caso de falha do mestre:
- O ClusterControl detectará e verificará a falha do mestre por meio do cliente MySQL, SSH e ping.
- O ClusterControl aguardará 3 segundos antes de iniciar um procedimento de failover.
- ClusterControl promoverá o escravo mais atualizado para se tornar o próximo mestre.
- Se o antigo mestre voltar a ficar online, ele será iniciado como somente leitura, sem participar da replicação ativa.
- Cabe aos usuários decidir o que acontecerá com o antigo mestre. Ele pode ser introduzido de volta à cadeia de replicação usando a funcionalidade "Reconstruir Escravo de Replicação" no ClusterControl.
- O ClusterControl só tentará executar o failover mestre uma vez. Se falhar, é necessária a intervenção do usuário.
Você pode monitorar todo o processo de failover em ClusterControl -> Activity -> Jobs -> Failover to a new master como mostrado abaixo:
Durante o failover, todas as conexões com os servidores de banco de dados serão enfileiradas no ProxySQL. Eles não serão encerrados até o tempo limite, controlado por mysql-default_query_timeout variável que é 86400000 milissegundos ou 24 horas. Os aplicativos provavelmente não veriam erros ou falhas no banco de dados neste momento, mas a compensação é o aumento da latência, dentro de um limite configurável.
Neste ponto, o ClusterControl apresentará a topologia conforme abaixo:
Se quisermos permitir que o antigo mestre se junte novamente à replicação depois que ele estiver ativo e disponível, precisaríamos reconstruí-lo como escravo indo para ClusterControl -> Nodes -> escolher o antigo mestre -> Reconstruir Replicação Slave -> escolha o novo master -> Proceed . Quando a reconstrução estiver concluída, você deverá obter a seguinte topologia (observe que 192.168.0.32 é o mestre agora):
Consolidação de servidores e dimensionamento de banco de dados
Com esta arquitetura, podemos consolidar muitos servidores MySQL que residem em cada servidor WHM em uma única configuração de replicação. Você pode dimensionar mais nós de banco de dados à medida que cresce ou ter vários clusters de replicação para oferecer suporte a todos eles e gerenciados por um único servidor ClusterControl. O diagrama de arquitetura a seguir ilustra se temos dois servidores WHM conectados a um único cluster de replicação MySQL via arquivo de soquete ProxySQL:
O acima nos permite separar as duas camadas mais importantes em nosso sistema de hospedagem - aplicativo (front-end) e banco de dados (back-end). Como você deve saber, colocar o MySQL no servidor WHM geralmente resulta em esgotamento de recursos, pois o MySQL precisa de uma enorme alocação de RAM inicial para iniciar e ter um bom desempenho (principalmente dependendo do innodb_buffer_pool_size variável). Considerando que o espaço em disco é suficiente, com a configuração acima, você pode ter mais contas de hospedagem hospedadas por servidor, onde todos os recursos do servidor podem ser utilizados pelos aplicativos de camada de front-end.
A ampliação do cluster de replicação do MySQL será muito mais simples com uma arquitetura de camada separada. Se digamos que o mestre requer uma manutenção de expansão (atualização de RAM, disco rígido, RAID, NIC), podemos alternar a função de mestre para outro escravo (ClusterControl -> Nodes -> pick a slave -> Promote Slave ) e, em seguida, execute a tarefa de manutenção sem afetar o serviço MySQL como um todo. Para operação de scale-out (adicionando mais escravos), você pode fazer isso sem afetar o mestre, executando o staging diretamente de qualquer escravo ativo. Com o ClusterControl, você pode até preparar um novo escravo a partir de um backup MySQL existente (somente compatível com PITR):
A reconstrução de um escravo a partir do backup não trará carga adicional ao mestre. O ClusterControl copiará o arquivo de backup selecionado do servidor ClusterControl para o nó de destino e realizará a restauração lá. Uma vez feito, o nó estará se conectando ao mestre e começará a recuperar todas as transações ausentes desde o tempo de restauração e recuperar o atraso com o mestre. Quando estiver atrasado, o ProxySQL não incluirá o nó no conjunto de balanceamento de carga até que o atraso de replicação seja inferior a 10 segundos (configurável ao adicionar uma tabela mysql_servers por meio da interface de administração do ProxySQL).
Considerações finais
O ProxySQL estende os recursos do WHM cPanel no gerenciamento da Replicação MySQL. Com o ClusterControl gerenciando seu cluster de replicação, todas as tarefas complexas envolvidas no gerenciamento do cluster de replicação agora são mais fáceis do que nunca.
