MaxScale 2.4 se lanzó el 21 de diciembre de 2019 y ClusterControl 1.7.6 admite el monitoreo y la administración hasta esta versión. Sin embargo, para la implementación, ClusterControl solo admite hasta la versión 2.3. Uno tiene que actualizar manualmente la instancia y, afortunadamente, los pasos de actualización son muy sencillos. Simplemente descargue la última versión de la página de descarga de MariaDB MaxScale y ejecute el comando de instalación del paquete.
Los siguientes comandos muestran cómo actualizar desde un MaxScale 2.3 existente a MaxScale 2.4 en una caja CentOS 7:
$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10En esta publicación de blog, destacaremos algunas de las mejoras notables y las nuevas características de esta versión y cómo se ve en acción. Para obtener una lista completa de los cambios en MariaDB MaxScale 2.4, consulte su registro de cambios.
Historial de comandos del modo interactivo
Esto es básicamente una pequeña mejora con un gran impacto en la administración de MaxScale y la eficiencia de las tareas de monitoreo. El modo interactivo para MaxCtrl ahora tiene su historial de comandos. El historial de comandos le permite repetir fácilmente el comando ejecutado presionando la tecla de flecha hacia arriba o hacia abajo. Sin embargo, la funcionalidad Ctrl+R (recuperar el último comando que coincida con los caracteres que proporcionó) aún no está disponible.
En las versiones anteriores, uno tiene que usar el modo de shell estándar para asegurarse de que los comandos sean capturados por el archivo .bash_history.
Supervisión de GTID para galeramon
Esta es una buena mejora para quienes ejecutan Galera Cluster con redundancia geográfica a través de la replicación asincrónica, también conocida como replicación de clúster a clúster, o replicación de MariaDB Galera Cluster sobre MariaDB Replication.
En MaxScale 2.3 y versiones anteriores, este es el aspecto si ha habilitado la replicación maestro-esclavo entre clústeres de MariaDB:
Para MaxScale 2.4, ahora se ve así (preste atención a Galera1 fila):
Ahora es más fácil ver el estado de replicación de todos los nodos de MaxScale, sin la necesidad de verificar los nodos individuales repetidamente.
Enrutador inteligente
Esta es una de las nuevas funciones principales de MaxScale 2.4, donde MaxScale ahora es lo suficientemente inteligente como para saber qué servidor backend de MariaDB es el mejor para procesar la consulta. SmartRouter realiza un seguimiento del rendimiento o el tiempo de ejecución de las consultas a los clústeres. Las medidas se almacenan con el canónico de una consulta como clave. El canónico de una consulta es el SQL con todas las constantes definidas por el usuario reemplazadas con signos de interrogación, por ejemplo:
UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? Esta es una función muy útil si está ejecutando MariaDB en una replicación geográfica de múltiples sitios o una combinación de motores de almacenamiento de MariaDB en una cadena de replicación, por ejemplo, un esclavo dedicado para manejar cargas de trabajo de transacciones (OLTP ) con motor de almacenamiento InnoDB y otro esclavo dedicado para manejar cargas de trabajo de análisis (OLAP) con motor de almacenamiento Columnstore.
Supongamos que tenemos dos sitios:Sydney y Singapur, como se ilustra en el siguiente diagrama:
El sitio principal está ubicado en Singapur y tiene un maestro MariaDB y un esclavo , mientras que otro esclavo de solo lectura se encuentra en Sydney. La aplicación se conecta a la instancia de MaxScale ubicada en su respectivo país con la siguiente configuración de puerto:
- División de lectura y escritura:3306
- Todos contra todos:3307
- Enrutador inteligente:3308
Nuestras definiciones de escucha y servicio de SmarRouter son:
[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308Reinicie MaxScale y comience a enviar una consulta de solo lectura a ambos nodos de MaxScale ubicados en Singapur y Sídney. Si la consulta es procesada por el enrutador round-robin (puerto 3307), veríamos que la consulta se enruta según el algoritmo round-robin:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+De lo anterior, podemos decir que MaxScale de Sydney reenvió la consulta anterior a nuestro esclavo de Singapur, que no es la mejor opción de enrutamiento per se.
Con SmartRouter escuchando en el puerto 3308, veríamos que la consulta se enruta al esclavo más cercano en Sydney:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname |
+-----------+-----------------+
| 1000000 | mariadb_sydney1 |
+-----------+-----------------+Y si la misma consulta se ejecuta en nuestro sitio de Singapur, se enrutará al esclavo MariaDB ubicado en Singapur:
(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Sin embargo, hay una trampa. Cuando SmartRouter ve una consulta de lectura cuyo canónico no se ha visto antes, enviará la consulta a todos los clústeres. La primera respuesta de un grupo designará ese grupo como el mejor para ese canónico. Además, cuando se recibe la primera respuesta, se cancelan las demás consultas. La respuesta se envía al cliente una vez que todos los clústeres han respondido a la consulta o la cancelación.
Esto significa que, para realizar un seguimiento de la consulta canónica (consulta normalizada) y medir su rendimiento, probablemente verá que la primera consulta falla en su primera ejecución, por ejemplo:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during queryDesde el registro general en MariaDB Sydney, podemos decir que la primera consulta (ID 74) se ejecutó con éxito (conectar, consultar y salir), a pesar del error "Conexión perdida" de MaxScale:
74 Connect [email protected] as anonymous on
74 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
74 QuitSi bien la consulta posterior idéntica se procesó correctamente y se devolvió con la respuesta correcta:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname |
+-----------+------------------------+
| 1000000 | mariadb_sydney.cluster |
+-----------+------------------------+Mirando nuevamente el registro general en MariaDB Sydney (ID 75), ocurrieron los mismos eventos de procesamiento como en la primera consulta:
75 Connect [email protected] as anonymous on
75 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
75 QuitA partir de esta observación, podemos concluir que, ocasionalmente, MaxScale tiene que fallar en la primera consulta para medir el rendimiento y volverse más inteligente para las consultas idénticas subsiguientes. Su aplicación debe poder manejar este "primer error" correctamente antes de volver al cliente o volver a intentar la transacción una vez más.
Socket UNIX para servidor
Hay varias formas de conectarse a un servidor MySQL o MariaDB en ejecución. Puede utilizar la red TCP/IP estándar con la dirección IP y el puerto del host (conexión remota), canalizaciones con nombre/memoria compartida en Windows o archivos de socket Unix en sistemas basados en Unix. El archivo de socket UNIX es un tipo especial de archivo que facilita la comunicación entre diferentes procesos, que en este caso es el cliente MySQL y el servidor. El archivo de socket es una comunicación basada en archivos y no puede acceder al socket desde otra máquina. Proporciona una conexión más rápida que TCP/IP (sin sobrecarga de red) y un enfoque de conexión más seguro porque solo se puede usar cuando se conecta a un servicio o proceso en la misma computadora.
Supongamos que el servidor MaxScale también está instalado en el propio servidor MariaDB, podemos usar el archivo de socket UNIX en su lugar. En la sección Servidor, elimine o comente la línea de "dirección" y agregue el parámetro de socket con la ubicación del archivo de socket:
[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sockAntes de aplicar los cambios anteriores, debemos crear un usuario MaxScale axscale desde localhost. En el servidor maestro:
MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';Después de reiniciar, MaxScale mostrará la ruta del socket de UNIX en lugar de la dirección real, y la lista de servidores se mostrará así:
Como puede ver, la información de estado y GTID se recupera correctamente a través de una conexión de socket. Tenga en cuenta que este DB_2 todavía está escuchando el puerto 3306 para las conexiones remotas. Solo muestra que MaxScale usa un socket para conectarse a este servidor para monitorear.
Usar socket siempre es mejor debido a que solo permite conexiones locales y es más seguro. También puede cerrar su servidor MariaDB de la red (por ejemplo, --skip-networking) y dejar que MaxScale maneje las conexiones "externas" y las reenvíe al servidor MariaDB a través del archivo de socket UNIX.
Drenaje del servidor
En MaxScale 2.4, los servidores back-end se pueden drenar, lo que significa que se pueden seguir usando las conexiones existentes, pero no se crearán nuevas conexiones al servidor. Con la función de drenaje, podemos realizar una actividad de mantenimiento elegante sin afectar la experiencia del usuario desde el lado de la aplicación. Tenga en cuenta que vaciar un servidor puede llevar más tiempo, dependiendo de las consultas en ejecución que deben cerrarse correctamente.
Para drenar un servidor, use el siguiente comando:
El efecto posterior podría ser uno de los siguientes estados:
- Drenando:el servidor se está drenando.
- Drenado:el servidor se ha vaciado. El servidor se estaba vaciando y ahora el número de conexiones al servidor se ha reducido a 0.
- Mantenimiento:el servidor está en mantenimiento.
Después de vaciar un servidor, el estado del servidor MariaDB desde el punto de vista de MaxScale es "Mantenimiento":
Cuando un servidor está en modo de mantenimiento, no se crearán conexiones con él y las conexiones existentes se cerrarán.
Conclusión
MaxScale 2.4 trae muchas mejoras y cambios con respecto a la versión anterior y es el mejor proxy de base de datos para manejar servidores MariaDB y todos sus componentes.
