ProxySQL é um balanceador de carga dedicado para MySQL que vem com uma variedade de recursos, incluindo, mas não limitado a redirecionamento de consulta, cache de consulta ou modelagem de tráfego. Ele pode ser usado para configurar facilmente uma divisão de leitura/gravação e redirecionar consultas para nós de back-end separados. Como resultado, ele fornece muitas razões convincentes para usar. Por outro lado, o HAProxy é um ótimo balanceador de carga, mas não é dedicado a bancos de dados e, embora possa ser usado, não pode ser realmente comparado com o ProxySQL. Esse pode ser o motivo para ambientes que ainda dependem do HAProxy para tentar migrar para o ProxySQL.
Nesta breve postagem do blog, compartilharemos algumas sugestões sobre o processo de migração.
Planejando seu upgrade
Isso é bastante óbvio e não deve ser questionado, mas ainda gostaríamos de tê-lo por escrito. Planeje sua atualização. Certifique-se de estar familiarizado com o processo, que você testou tudo extensivamente. Configure um ambiente de teste no qual você possa verificar diferentes abordagens para a atualização e decidir qual funcionaria melhor para você.
Teste a divisão de leitura/gravação no ProxySQL se você considerar usá-la
Dependendo de seus requisitos, você pode considerar usar a divisão de leitura/gravação no ProxySQL. Esta é, provavelmente, uma das razões mais convincentes para a atualização. Em vez de implementá-lo no lado do aplicativo (ou não implementá-lo se você não puder realizá-lo no aplicativo), você pode confiar no ProxySQL para executar a divisão de leitura/gravação para você. A configuração é muito fácil, especialmente se você implantar o ProxySQL usando o ClusterControl - isso acontece praticamente automaticamente.
Desde que você não use transações implícitas, o ClusterControl configurará o divisão de leitura/gravação para você usando um conjunto de regras de consulta:
Mesmo que seja muito simples implementar a divisão de leitura/gravação, você deve tenha cuidado quando você planeja fazê-lo. Os aplicativos podem contar com algumas funcionalidades que não funcionam de imediato no ProxySQL. Na maioria dos casos, a configuração adicional permitirá que você se beneficie desse recurso, mas é muito importante durante a fase de teste identificar se seu aplicativo funcionará ou se você precisa adicionar alguma configuração personalizada. Partes especialmente complicadas são problemas de leitura após gravação - nesse caso, você pode ter que reconfigurar o ProxySQL para desabilitar a multiplexação de conexão para algumas das consultas.
Esqueça o arquivo de configuração no ProxySQL
Esta é uma das coisas que surpreendem os novos usuários do ProxySQL. Ele realmente não usa arquivos de configuração. Existe um, sim, mas ele atua como uma maneira de inicializar o ProxySQL durante a primeira inicialização. O ProxySQL utiliza um banco de dados SQLite que contém sua configuração e a maneira correta de fazer qualquer alteração de configuração é através de um cliente MySQL conectado à porta administrativa do ProxySQL. A partir daí, você pode fazer as alterações de configuração em tempo de execução, praticamente sem a necessidade de reiniciar o ProxySQL.
É claro que a interface do usuário do ClusterControl também permite reconfigurar o ProxySQL:
Padrões de implantação do ProxySQL
Existem duas maneiras principais pelas quais você deseja implantar o ProxySQL. Você pode usar servidores dedicados para implantar o ProxySQL em:
Ou você pode colocar ProxySQL com servidores de aplicativos:
Isso permite que seu aplicativo se conecte à instância ProxySQL local usando o soquete Unix, que é melhor em termos de desempenho do que usar uma conexão TCP remota. Ele também simplifica a configuração - não há necessidade de implementar Keepalived ou algum outro provedor de IP virtual para balancear a carga nas instâncias do ProxySQL. O aplicativo se conecta apenas ao ProxySQL local e é basicamente isso.
Use clusters ProxySQL para implantações maiores
Certificar-se de que suas instâncias ProxySQL contenham a mesma configuração o tempo todo pode ser um desafio, especialmente se seus números forem grandes. Existem várias maneiras de lidar com esses desafios - Ansible/Chef/Puppet, scripts de shell e assim por diante. Sugerimos confiar na solução integrada - ProxySQL Cluster. Com apenas algumas alterações de configuração, você pode configurar nós ProxySQL para formar um cluster onde uma alteração de configuração em um dos nós será propagada por todos os membros do cluster.
Ajuste com SO_REUSEPORT para alternância do balanceador de carga gracioso
Uma das partes mais desafiadoras pode ser garantir que você altere o tráfego de HAProxy para ProxySQL de forma a minimizar o impacto no aplicativo. Normalmente, você teria que alterar pelo menos uma configuração - nome do host ou porta à qual o aplicativo deve se conectar. Dependendo do seu ambiente, isso pode não ser o ideal, especialmente se a configuração de conectividade do banco de dados estiver integrada no aplicativo. Isso exigiria, basicamente, fazer uma alteração na base de código e enviar um novo código para a produção. Não é o maior dos negócios, mas você pode fazer melhor do que isso.
A parte interessante é que tanto o ProxySQL quanto as versões recentes do HAProxy (a partir de 1.8) podem utilizar SO_REUSEPORT. Esta opção de soquete está disponível no Linux a partir do kernel 3.9 e permite que vários processos compartilhem a mesma porta. O ProxySQL pode usá-lo para atualizações graciosas entre as versões do ProxySQL, o HAProxy o usa para recarregar a configuração sem nenhum impacto no aplicativo. O interessante é que é possível configurar o ProxySQL para compartilhar a porta com o HAProxy para a migração perfeita entre esses dois balanceadores de carga.
Há algumas coisas que você deve considerar ao tentar fazer isso - primeiro, o ProxySQL não usa essa opção por padrão, você deve adicionar o sinalizador -r ao ProxySQL na inicialização. Você pode fazer isso editando o arquivo de unidade systemd do ProxySQL:
[email protected]:~# systemctl edit proxysql --fulle alterando a diretiva ExecStart para:
ExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rOutra limitação que você deve estar ciente no Linux é que apenas processos iniciados pelo mesmo ID de usuário podem compartilhar a porta. Isso significa que você terá que reconfigurar o ProxySQL para ser executado como um usuário “haproxy”.
Como de costume, você pode querer executar testes antes de tentar realizar esta operação em um ambiente de produção. É definitivamente possível realizar esse feito, mas você deve ter cuidado e verificar novamente se isso não afetará sua produção devido a algum tipo de configuração não padrão relacionada ao seu ambiente.
Esperamos que este breve blog lhe dê algumas dicas sobre o processo de migração do HAProxy para o ProxySQL. Para os backends de banco de dados, essa mudança será muito benéfica, mesmo que a parte de preparação possa ser demorada. Se você passar por testes adequados, a migração final deve ser bastante direta e segura.
