Una capa de proxy entre las aplicaciones y las bases de datos normalmente consistiría en varios nodos de proxy para una alta disponibilidad. Esto no es diferente para ProxySQL. ProxySQL, al igual que otros proxies modernos, se puede usar para crear una lógica compleja para enrutar consultas. Puede agregar reglas de consulta para enviar consultas a hosts particulares, puede almacenar consultas en caché, puede agregar y eliminar servidores backend o administrar usuarios que pueden conectarse a ProxySQL y MySQL. Sin embargo, numerosos nodos de ProxySQL en la capa de proxy presentan otro problema:la sincronización entre instancias distribuidas. Cualquier regla u otra lógica debe sincronizarse entre instancias para garantizar que se comporten de la misma manera. Incluso si no todos los proxies están manejando el tráfico, todavía funcionan como reserva. En caso de que deban hacerse cargo del trabajo, no quiere sorpresas si la instancia utilizada no tiene los cambios de configuración más recientes.
Es bastante engorroso asegurarse de esto manualmente:realizar los cambios a mano en todos los nodos. Puede utilizar herramientas como Ansible, Chef o Puppet para administrar configuraciones, pero el proceso de sincronización debe codificarse y probarse. ClusterControl puede ayudarlo aquí a través de una opción para sincronizar configuraciones entre instancias de ProxySQL, pero también puede configurar y administrar los otros componentes necesarios para una alta disponibilidad, por ejemplo, IP virtual. Pero a partir de la versión 1.4.2, ProxySQL ofrece un mecanismo de sincronización de configuración y agrupamiento nativo. En esta publicación de blog, discutiremos cómo configurarlo con una combinación de acciones realizadas en la interfaz de administración de línea de comandos de ClusterControl y ProxySQL.
En primer lugar, echemos un vistazo a un entorno de replicación típico implementado por ClusterControl.
Como puede ver en la captura de pantalla, esta es una configuración de replicación de MySQL con tres instancias de ProxySQL. La alta disponibilidad de ProxySQL se implementa a través de Keepalived y una IP virtual que siempre se asigna a uno de los nodos de ProxySQL. Hay un par de pasos que debemos seguir para configurar la agrupación en clústeres de ProxySQL. Primero, tenemos que definir qué usuario debe usar ProxySQL para intercambiar información entre los nodos. Definamos uno nuevo además del usuario administrativo existente:
A continuación, debemos definir ese usuario en la configuración admin-cluster_password y admin-cluster_username.
Esto se ha hecho en uno solo de los nodos (10.0.0.126). Sincronicemos este cambio de configuración con los nodos ProxySQL restantes.
Como dijimos, ClusterControl le permite sincronizar la configuración entre los nodos ProxySQL con solo un par de pasos. Cuando el trabajo terminó de sincronizar 10.0.0.127 con 10.0.0.126, solo queda el último nodo que necesitamos sincronizar.
Después de esto, necesitamos hacer un pequeño cambio en la interfaz de la línea de comandos administrativa de ProxySQL, a la que normalmente se puede acceder en el puerto 6032. Tenemos que crear entradas en la tabla 'proxysql_servers' que definiría los nodos en nuestro clúster de ProxySQL.
mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)Después de cargar el cambio en tiempo de ejecución, ProxySQL debería comenzar a sincronizar los nodos. Hay un par de lugares donde puede realizar un seguimiento del estado del clúster.
mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname | port | name | version | epoch | checksum | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_query_rules | 2 | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_servers | 4 | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_users | 2 | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | proxysql_servers | 2 | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_query_rules | 3 | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_servers | 5 | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_users | 3 | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | proxysql_servers | 2 | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_query_rules | 1 | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_servers | 3 | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_users | 1 | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | proxysql_servers | 2 | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0 |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)La tabla stats_proxysql_servers_checksums contiene, entre otros, una lista de nodos en el clúster, tablas que están sincronizadas, versiones y suma de comprobación de la tabla. Si la suma de verificación no está en línea, ProxySQL intentará obtener la última versión de un par de clúster. Puede encontrar información más detallada sobre el contenido de esta tabla en la documentación de ProxySQL.
Otra fuente de información sobre el proceso es el registro de ProxySQL (por defecto se encuentra en /var/lib/proxysql/proxysql.log).
2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032Como puede ver, aquí tenemos información de que se ha detectado una nueva suma de comprobación y el proceso de sincronización está en marcha.
Detengámonos un momento aquí y discutamos cómo ProxySQL maneja las actualizaciones de configuración de múltiples fuentes. En primer lugar, ProxySQL realiza un seguimiento de las sumas de comprobación para detectar cuándo ha cambiado una configuración. También almacena cuándo sucedió:estos datos se almacenan como una marca de tiempo, por lo que tiene una resolución de un segundo. ProxySQL tiene dos variables que también afectan la forma en que se sincronizan los cambios.
Cluster_check_interval_ms:determina la frecuencia con la que ProxySQL debe verificar los cambios de configuración. Por defecto es 1000ms.
Cluster_mysql_servers_diffs_before_sync:nos dice cuántas veces una verificación debe detectar un cambio de configuración antes de que se sincronice. La configuración predeterminada es 3.
Esto significa que, incluso si va a realizar un cambio de configuración en el mismo host, si lo hará con menos frecuencia de 4 segundos, es posible que los nodos ProxySQL restantes no puedan sincronizarlo porque aparecerá un nuevo cambio antes que el anterior. estaba sincronizado. También significa que si realiza cambios de configuración en varias instancias de ProxySQL, debe realizarlos con al menos un descanso de 4 segundos entre ellos, ya que, de lo contrario, algunos de los cambios se perderán y, como resultado, las configuraciones divergirán. Por ejemplo, agrega Server1 en Proxy1 y, después de 2 segundos, agrega Server2 en Proxy2. Todos los demás proxies rechazarán el cambio en Proxy1 porque detectarán que Proxy2 tiene una configuración más nueva. 4 segundos después del cambio en Proxy2, todos los proxies (incluido Proxy1) extraerán la configuración de Proxy2.
Como la comunicación dentro del clúster no es síncrona y si falla un nodo ProxySQL en el que realizó los cambios, es posible que los cambios no se repliquen a tiempo. El mejor enfoque es realizar el mismo cambio en dos nodos de ProxySQL. De esta manera, a menos que ambos fallen exactamente al mismo tiempo, uno de ellos podrá propagar la nueva configuración.
También vale la pena señalar que la topología de clúster de ProxySQL puede ser bastante flexible. En nuestro caso tenemos tres nodos, todos tienen tres entradas en la tabla proxysql_servers. Dichos nodos forman el clúster donde puede escribir en cualquier nodo y los cambios se propagarán. Además de eso, es posible agregar nodos externos que funcionarían en un modo de "solo lectura", lo que significa que solo sincronizarían los cambios realizados en el clúster "núcleo", pero no propagarán los cambios que se realizaron directamente. sobre ellos mismos Todo lo que necesita en el nuevo nodo es tener configurados solo los nodos de clúster "principales" en proxysql_servers y, como resultado, se conectará a esos nodos y obtendrá los cambios de datos, pero no será consultado por el resto del clúster. para sus cambios de configuración. Esta configuración podría usarse para crear una fuente de verdad con varios nodos en el clúster y otros nodos ProxySQL, que solo obtienen la configuración del clúster "núcleo" principal.
Además de todo eso, el clúster ProxySQL admite la reincorporación automática de los nodos:sincronizarán su configuración al iniciarse. También se puede escalar fácilmente agregando más nodos.
Esperamos que esta publicación de blog le brinde una idea de cómo se puede configurar el clúster de ProxySQL. El clúster de ProxySQL será transparente para ClusterControl y no afectará ninguna de las operaciones que desee ejecutar desde la interfaz de usuario de ClusterControl.
