En la primera parte de la serie, le mostramos cómo implementar una configuración de replicación de MySQL con ProxySQL con WHM y cPanel. En esta parte, mostraremos algunas operaciones posteriores a la implementación para el mantenimiento, la administración, la conmutación por error, así como las ventajas sobre la configuración independiente.
Administración de usuarios de MySQL
Con esta integración habilitada, la administración de usuarios de MySQL deberá realizarse desde WHM o cPanel. De lo contrario, la tabla mysql_users de ProxySQL no se sincronizaría con lo que está configurado para nuestro maestro de replicación. Supongamos que ya creamos un usuario llamado variosn_usuario1 (el nombre de usuario de MySQL es prefijado automáticamente por cPanel para cumplir con la limitación de MySQL), y nos gustaría asignar a la base de datos variosn_db1 como se muestra a continuación:
Lo anterior dará como resultado la siguiente salida de la tabla mysql_users en ProxySQL:
Si desea crear recursos de MySQL fuera de cPanel, puede usar ClusterControl -> Administrar -> Esquemas y usuarios y luego importe el usuario de la base de datos a ProxySQL yendo a ClusterControl -> Nodos -> elija el nodo ProxySQL -> Usuarios -> Importar usuarios .
El módulo Proxysqlhook que usamos para sincronizar a los usuarios de ProxySQL envía los registros de depuración a /usr/local/cpanel/logs/error_log. Use este archivo para inspeccionar y comprender lo que sucede detrás de escena. Las siguientes líneas aparecerían en el archivo de registro de cPanel si instalamos una aplicación web llamada Zikula usando 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 *****Vería algunas líneas repetidas como "Comprobando si {usuario de base de datos} existe" porque WHM crea múltiples usuarios/hosts de MySQL para cada solicitud de creación de usuario de base de datos. En nuestro ejemplo, WHM crearía estos 3 usuarios:
ProxySQL solo necesita el nombre de usuario, la contraseña y la información del grupo de host predeterminado al agregar un usuario. Por lo tanto, las líneas de verificación están ahí para evitar múltiples inserciones del mismo usuario.
Si desea modificar el módulo y realizar algunas mejoras, no olvide volver a registrar el módulo ejecutando el siguiente comando en el servidor WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookSupervisión de consultas y almacenamiento en caché
Con ProxySQL, puede monitorear todas las consultas provenientes de la aplicación que se han pasado o están pasando por ella. El WHM estándar no proporciona este nivel de detalle en el monitoreo de consultas de MySQL. A continuación se muestran todas las consultas de MySQL que han sido capturadas por ProxySQL:
Con ClusterControl, puede buscar fácilmente las consultas más repetidas y almacenarlas en caché a través de la función de caché de consultas de ProxySQL. Use el menú desplegable "Ordenar por" para ordenar las consultas por "Recuento de estrellas", desplácese hasta la consulta que desea almacenar en caché y haga clic en el botón "Cache Query" debajo de ella. Aparecerá el siguiente cuadro de diálogo:
El conjunto de resultados de las consultas almacenadas en caché será almacenado y atendido por el mismo ProxySQL, lo que reducirá la cantidad de visitas al backend que descargará su clúster de replicación de MySQL en su totalidad. La implementación de caché de consultas de ProxySQL es fundamentalmente diferente de la caché de consultas de MySQL. Es un caché basado en el tiempo y caducará después de un tiempo de espera llamado "Caché TTL". En esta configuración, nos gustaría almacenar en caché la consulta anterior durante 5 segundos (5000 ms) antes de llegar al grupo de lectores donde el grupo de host de destino es 20.
División y equilibrio de lectura/escritura
Al escuchar el puerto predeterminado 3306 de MySQL, ProxySQL actúa como el propio servidor MySQL. Habla protocolos MySQL tanto en el frontend como en el backend. Las reglas de consulta definidas por ClusterControl al configurar ProxySQL dividirán automáticamente todas las lecturas (^SELECT .* en lenguaje Regex) al grupo de host 20, que es el grupo de lectores, y el resto se reenviará al grupo de host de escritor 10, como se muestra en el siguiente sección de reglas de consulta:
Con esta arquitectura, no tiene que preocuparse por dividir las consultas de lectura/escritura, ya que ProxySQL hará el trabajo por usted. Los usuarios tienen cambios mínimos o nulos en el código, lo que permite a los usuarios de hospedaje usar todas las aplicaciones y características provistas por WHM y cPanel de forma nativa, similar a conectarse a una configuración independiente de MySQL.
En términos de equilibrio de conexión, si tiene más de un nodo activo en un grupo de host en particular (como el grupo de host de lector 20 en este ejemplo), ProxySQL distribuirá automáticamente la carga entre ellos en función de una serie de criterios:pesos, retraso de replicación, conexiones utilizadas , carga general y latencia. Se sabe que ProxySQL es muy bueno en entornos de alta concurrencia al implementar un mecanismo avanzado de agrupación de conexiones. Citado de la publicación de blog de ProxySQL, ProxySQL no solo implementa la conexión persistente, sino también la multiplexación de la conexión. De hecho, ProxySQL puede manejar cientos de miles de clientes y, sin embargo, reenviar todo su tráfico a unas pocas conexiones al backend. Por lo tanto, ProxySQL puede manejar N conexiones de cliente y M conexiones de servidor, donde N> M (incluso N miles de veces más grande que M).
Conmutación por error y recuperación de MySQL
Con ClusterControl administrando el clúster de replicación, la conmutación por error se realiza automáticamente si la recuperación automática está habilitada. En caso de falla del maestro:
- ClusterControl detectará y verificará la falla maestra a través del cliente MySQL, SSH y ping.
- ClusterControl esperará 3 segundos antes de comenzar un procedimiento de conmutación por error.
- ClusterControl promoverá el esclavo más actualizado para que se convierta en el próximo maestro.
- Si el maestro anterior vuelve a estar en línea, se iniciará como de solo lectura, sin participar en la replicación activa.
- Depende de los usuarios decidir qué sucederá con el antiguo maestro. Podría volver a introducirse en la cadena de replicación utilizando la funcionalidad "Reconstruir esclavo de replicación" en ClusterControl.
- ClusterControl solo intentará realizar la conmutación por error maestra una vez. Si falla, se requiere la intervención del usuario.
Puede monitorear todo el proceso de conmutación por error en ClusterControl -> Actividad -> Trabajos -> Conmutación por error a un nuevo maestro como se muestra a continuación:
Durante la conmutación por error, todas las conexiones a los servidores de la base de datos se pondrán en cola en ProxySQL. No se cancelarán hasta que se agote el tiempo de espera, controlado por mysql-default_query_timeout variable que es 86400000 milisegundos o 24 horas. Lo más probable es que las aplicaciones no vean errores o fallas en la base de datos en este punto, pero la compensación es una mayor latencia, dentro de un umbral configurable.
En este punto, ClusterControl presentará la topología de la siguiente manera:
Si deseamos permitir que el antiguo maestro vuelva a unirse a la replicación después de que esté activo y disponible, tendríamos que reconstruirlo como un esclavo yendo a ClusterControl -> Nodos -> seleccione el antiguo maestro -> Reconstruir replicación Esclavo -> elegir el nuevo maestro -> Continuar . Una vez que se completa la reconstrucción, debe obtener la siguiente topología (observe que 192.168.0.32 es el maestro ahora):
Consolidación de servidores y escalado de bases de datos
Con esta arquitectura, podemos consolidar muchos servidores MySQL que residen en cada servidor WHM en una única configuración de replicación. Puede escalar más nodos de base de datos a medida que crece, o tener varios clústeres de replicación para admitirlos todos y administrarlos mediante un solo servidor ClusterControl. El siguiente diagrama de arquitectura ilustra si tenemos dos servidores WHM conectados a un solo clúster de replicación de MySQL a través de un archivo de socket ProxySQL:
Lo anterior nos permite separar los dos niveles más importantes en nuestro sistema de alojamiento:aplicación (front-end) y base de datos (back-end). Como sabrá, la ubicación conjunta de MySQL en el servidor WHM suele provocar el agotamiento de los recursos, ya que MySQL necesita una gran asignación de RAM inicial para iniciarse y funcionar bien (principalmente dependiendo del innodb_buffer_pool_size). variable). Teniendo en cuenta que el espacio en disco es suficiente, con la configuración anterior, puede tener más cuentas de alojamiento alojadas por servidor, donde las aplicaciones de nivel frontal pueden utilizar todos los recursos del servidor.
Ampliar el clúster de replicación de MySQL será mucho más sencillo con una arquitectura de nivel independiente. Si digamos que el maestro requiere un mantenimiento escalable (actualización de RAM, disco duro, RAID, NIC), podemos cambiar la función de maestro a otro esclavo (ClusterControl -> Nodos -> elegir un esclavo -> Promover esclavo ) y luego realizar la tarea de mantenimiento sin afectar el servicio MySQL en su conjunto. Para la operación de escalamiento horizontal (agregar más esclavos), puede realizarla sin siquiera afectar al maestro realizando la puesta en escena directamente desde cualquier esclavo activo. Con ClusterControl, incluso puede organizar un nuevo esclavo a partir de una copia de seguridad de MySQL existente (solo compatible con PITR):
La reconstrucción de un esclavo a partir de una copia de seguridad no supondrá una carga adicional para el maestro. ClusterControl copiará el archivo de copia de seguridad seleccionado del servidor de ClusterControl al nodo de destino y realizará la restauración allí. Una vez hecho esto, el nodo se conectará al maestro y comenzará a recuperar todas las transacciones faltantes desde el momento de la restauración y se pondrá al día con el maestro. Cuando se está retrasando, ProxySQL no incluirá el nodo en el conjunto de equilibrio de carga hasta que el retraso de la replicación sea inferior a 10 segundos (configurable al agregar una tabla mysql_servers a través de la interfaz de administración de ProxySQL).
Reflexiones finales
ProxySQL amplía las capacidades de WHM cPanel en la gestión de la replicación de MySQL. Con ClusterControl administrando su clúster de replicación, todas las tareas complejas involucradas en la administración del clúster de replicación ahora son más fáciles que nunca.
