ProxySQL es un balanceador de carga dedicado para MySQL que viene con una variedad de funciones que incluyen, entre otras, la redirección de consultas, el almacenamiento en caché de consultas o la configuración del tráfico. Se puede usar para configurar fácilmente una división de lectura y escritura y redirigir consultas a nodos backend separados. Como resultado, proporciona muchas razones de peso para su uso. Por otro lado, HAProxy es un excelente equilibrador de carga, pero no está dedicado a las bases de datos y, si bien se puede usar, no se puede comparar realmente con las características de ProxySQL. Esta podría ser la razón por la que los entornos que todavía dependen de HAProxy intentan migrar a ProxySQL.
En esta breve publicación de blog, compartiremos un par de sugerencias sobre el proceso de migración.
Planificación de su actualización
Esto es bastante obvio y no debe cuestionarse, pero aun así nos gustaría tenerlo por escrito. Planifique su actualización. Asegúrese de estar familiarizado con el proceso, de haber probado todo exhaustivamente. Configure un entorno de prueba en el que pueda verificar diferentes enfoques para la actualización y decidir cuál funcionaría mejor para usted.
Pruebe la división de lectura/escritura en ProxySQL si considera usarlo
Dependiendo de sus requisitos, es posible que desee considerar el uso de división de lectura/escritura en ProxySQL. Esta es, probablemente, una de las razones más convincentes para la actualización. En lugar de implementarlo en el lado de la aplicación (o no implementarlo en absoluto si no puede lograrlo en la aplicación), puede confiar en ProxySQL para realizar la división de lectura/escritura por usted. La configuración es muy fácil, especialmente si implementa ProxySQL usando ClusterControl; sucede de forma casi automática.
Siempre que no use transacciones implícitas, ClusterControl configurará el división de lectura/escritura para usted usando un conjunto de reglas de consulta:
Aunque es muy sencillo implementar la división de lectura/escritura, debe tenga cuidado cuando planee hacerlo. Las aplicaciones pueden depender de alguna funcionalidad que realmente no funciona de forma predeterminada en ProxySQL. En la mayoría de los casos, la configuración adicional le permitirá beneficiarse de esta función, pero es muy importante durante la fase de prueba identificar si su aplicación funcionará o si necesita agregar alguna configuración personalizada. Las partes especialmente complicadas son los problemas de lectura después de escritura; en ese caso, es posible que deba volver a configurar ProxySQL para deshabilitar la conexión multiplexada para algunas de las consultas.
Olvídese del archivo de configuración en ProxySQL
Esta es una de las cosas que sorprende a los nuevos usuarios de ProxySQL. Realmente no utiliza archivos de configuración. Hay uno, sí, pero prácticamente actúa como una forma de arrancar ProxySQL durante el primer inicio. ProxySQL utiliza una base de datos SQLite que contiene su configuración y la forma correcta de realizar cualquier cambio de configuración es a través de un cliente MySQL conectado al puerto administrativo de ProxySQL. Desde allí, puede realizar los cambios de configuración en tiempo de ejecución, prácticamente sin necesidad de reiniciar ProxySQL.
Por supuesto, la interfaz de usuario de ClusterControl también le permite reconfigurar ProxySQL:
Patrones de implementación de ProxySQL
Hay dos formas principales en las que desea implementar ProxySQL. Puede usar servidores dedicados para implementar ProxySQL en:
O puede ubicar ProxySQL con servidores de aplicaciones:
Esto permite que su aplicación se conecte a la instancia local de ProxySQL usando un socket Unix, que es mejor en cuanto a rendimiento que usar una conexión TCP remota. También simplifica la configuración:no es necesario implementar Keepalived o algún otro proveedor de IP virtual para equilibrar la carga en las instancias de ProxySQL. La aplicación solo se conecta al ProxySQL local y eso es todo.
Utilice clústeres de ProxySQL para implementaciones más grandes
Asegurarse de que sus instancias de ProxySQL contengan la misma configuración todo el tiempo puede ser un desafío, especialmente si su número es grande. Existen numerosas formas de lidiar con tales desafíos:Ansible/Chef/Puppet, scripts de shell, etc. Sugerimos confiar en la solución integrada:ProxySQL Cluster. Con solo un par de cambios de configuración, puede configurar los nodos de ProxySQL para formar un clúster donde un cambio de configuración en uno de los nodos se propagará a todos los miembros del clúster.
Juguete con SO_REUSEPORT para una conmutación elegante del balanceador de carga
Una de las partes más desafiantes podría ser asegurarse de cambiar el tráfico de HAProxy a ProxySQL de manera que minimice el impacto en la aplicación. Por lo general, tendría que cambiar al menos una configuración:el nombre de host o el puerto al que se debe conectar la aplicación. Dependiendo de su entorno, esto podría no ser ideal, especialmente si la configuración de conectividad de la base de datos está integrada en la aplicación. Prácticamente requeriría hacer un cambio en la base del código y enviar un nuevo código a la producción. No es la mayor de las ofertas, pero puedes hacer algo mejor que eso.
La parte interesante es que tanto ProxySQL como las versiones recientes de HAProxy (a partir de la 1.8) pueden utilizar SO_REUSEPORT. Esta opción de socket está disponible en Linux a partir del kernel 3.9 y permite que múltiples procesos compartan el mismo puerto. ProxySQL puede usarlo para actualizaciones ordenadas entre versiones de ProxySQL, HAProxy lo usa para recargar la configuración sin ningún impacto en la aplicación. Lo que es interesante, es posible configurar ProxySQL para compartir el puerto con HAProxy para la migración sin problemas entre esos dos balanceadores de carga.
Hay un par de cosas que debe considerar al intentar hacer esto:primero, ProxySQL no usa esta opción de forma predeterminada, debe agregar el indicador -r a ProxySQL al inicio. Puede hacerlo editando el archivo de unidad systemd de ProxySQL:
[email protected]:~# systemctl edit proxysql --fully cambiando la directiva ExecStart a:
ExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rOtra limitación que debe tener en cuenta en Linux es que solo los procesos iniciados por el mismo ID de usuario pueden compartir el puerto. Esto significará que tendrá que volver a configurar ProxySQL para que se ejecute como un usuario "haproxy".
Como de costumbre, es posible que desee ejecutar pruebas antes de intentar realizar esta operación en un entorno de producción. Definitivamente es posible lograr esta hazaña, pero debe tener cuidado y verificar que no afecte su producción debido a algún tipo de configuración no estándar relacionada con su entorno.
Esperamos que este breve blog le brinde información sobre el proceso de migración de HAProxy a ProxySQL. Para los backends de la base de datos, este cambio será muy beneficioso, incluso si la parte de preparación puede llevar mucho tiempo. Si realiza las pruebas adecuadas, la migración final debería ser bastante sencilla y segura.
