wiki/HowtoMaxScale.md

categories: databases title: How to MaxScale: installation et utilisation

• Documentation : https://mariadb.com/kb/en/maxscale/

MariaDB MaxScale est un serveur proxy pour MySQL et MariaDB.

Installation

Pour installer MariaDB MaxScale il faut soit ajouter le dépot officiel soit télécharger le paquet depuis le site officiel.

Configuration

MariaDB MaxScale est configuré dans le fichier ini /etc/maxscale.cnf, ce fichier peut être séparé en 5 grandes parties: la configuration globale de MaxScale, la liste des serveurs que MaxScale surveille, la configuration du (ou des) service surveillant ces serveurs, la configuration des services par lesquelles MaxScale route les communications entre les applications clients et les serveurs MySQL, et la manière par laquelle les clients se connectent à MaxScale.

La configuration globale de MaxScale se trouve dans un bloc maxscale et contient la configuration du nombre de threads utilisés par MaxScale, ses répertoires de stockages, les accès Rest-API (principalement pour l'administration à distance), …

Puisque MaxScale sert d'intermédiaire entre les applications clients MySQL et des serveurs MySQL, il faut que le serveur MaxScale sache comment communiquer avec les serveurs MySQL, pour cela chaque serveur est configuré dans un bloc ayant la clé type à la valeur server et un nom qui sera le nom du serveur pour MaxScale, les principales clés pour ce type de bloc sont :

• address ayant pour valeur l'adresse du serveur MySQL,
• port ayant pour valeur le port sur lequel le serveur MySQL attend des connections,
• socket qui correspond à la socket du serveur MySQL si celui-ci est un serveur local et
• protocol qui est le protocol que le serveur MaxScale va utiliser pour parler avec le serveur MySQL, les valeurs de cette clé sont MariaDBBackend pour les serveurs MySQL et MariaDBClient si le "serveur" est un service interne de MaxScale.

Exemples de configurations de serveurs

[dbserver1]
type = server
address = 192.0.2.100
port = 3306
protocol = MariaDBBackend

[dbserver2]
type = server
address = db2.example.com
port = 3306
protocol = MariaDBBackend

Afin de pouvoir surveillé l'état des serveurs MySQL, MaxScale a besoin d'avoir un moniteur configuré, cela se fait en configurant un bloc ayant la clé type à la valeur monitor, les autres clés principales sont:

• module définissant le type de moniteur (mariadbmon pour un cluster MySQL simple et galeramon pour un cluster Galera)
• servers qui contient les noms des serveurs surveillés par ce moniteur (séparés par des virgules)
• user configurant l'utilisateur MySQL utiliser pour surveiller le cluster
• password contenant le mot de passe de cet utilisateur MySQL.

D'autres clés de configurations sont disponible pour chaques type de moniteur permettant de controller comment le moniteur interagi avec le cluster qu'il surveille.

Exemple de configuration de moniteur:

[MariaDB-Monitor]
type = monitor
module = mariadbmon
servers = dbserver1, dbserver2
user = monitor
password = PASSWORD1

MaxScale a ensuite besoin de savoir comment répartir la charge entre les serveurs, pour cela il faut configuré un bloc ayant la clé type à la valeur service, le nom du bloc étant le nom que MaxScale donnera à ce service. Les clés principales de ce type de bloc sont :

• router définissant le type de routage utiliser par MaxScale, les types principaux étant :
  • readconnroute qui ce contente d'équilibrer les connections entre les serveurs sans se préoccuper du type de requêtes, son utilisation principale étant de fournir un port pour les opérations d'écritures et un port pour les connections de lectures.
  • readwritesplit qui sépare les opérations de lectures et d'écritures de manière automatique.
• servers définissant la liste des serveurs sur lesquelles faire du routage
• cluster (incompatible avec servers) le nom du moniteur surveillant les serveurs sur lesquels faire du routage
• user l'utilisateur MySQL que MaxScale utilise pour récupérer la liste des utilisateurs, table, bases de donnés, …
• password mot de passe de cet utilisateur MySQL.

D'autres clés de configurations sont disponibles pour chaque type de routage.

Exemple de configuration de service:

[MariaDB-Service]
type = service
router = readwritesplit
servers = dbserver1, dbserver2
user = maxscale
password = PASSWORD2

Note: Il est possible de choisir un nom quelconque pour le bloc, il s'agira du nom que MaxScale donnera au moniteur.

Enfin, MaxScale doit être configuré pour attendre des connections MySQL et les passer à un service, pour ce faire il faut configurer un bloc ayant la clé type à la valeur listener, la clé service au nom du service vers lequel passer la connection, la clé protocol à MariaDBClient et la clé port au port utilisé.

Exemple de configuration de listener:

[Splitter-Listener]
type = listener
service = MariaDB-Service
protocol = MariaDBClient
port = 3306

⚠ : Les utilisateurs ont besoins de pouvoir se connecter au serveurs MySQL depuis le serveur MaxScale, c'est à dire qu'il existe un utilisateur mysql USER@<ip de MaxScale> ou USER@*.

Routers

MariaDB MaxScale à plusieurs types de routages possibles, les principaux sont:

• Readconnroute qui permet de faire du routage par connections, avec toutes les requêtes allant vers un même serveur de backend, un des principaux cas d'usage de ce type de routage est un version légère de routage avec deux ports différents pour les commandes d'écritures et de lecture.
• Readwritesplit qui permet une séparation automatique des requêtes de lecture et d'écriture, ce routeur est plus lourd en ressources pour le serveur MaxScale mais est compatible avec la plupart des clients mysql sans modification majeure de configuration.
• Binlogrouter qui permet à MaxScale de récupérer les binlog d'un serveur MySQL ou MariaDB et d'être utilisé comme proxy au niveau de la réplication (MaxScale apparaissant comme étant le serveur maître).
• Avrorouter qui permet de transformer les binlog récupérés par un Binlogrouter en fichier Avro pour utilisation avec le protocol CDC (eg. Kafka)

Il y a d'autres router mais ils sont soit en béta soit très instables si non configurés avec une bonne connaissance du contenu des base de donnés.

Filtres

MaxScale peut faire passer les statements SQL par des filtres avant de les envoyés au routeur et donc au serveurs MySQL, ces filtres permettent de bloquer certaines requêtes, de conseiller au routeur d'envoyer des requêtes sur un certain serveur, ou de modifier le retour des serveurs.

• dbfwfilter: Permet de bloquer des requêtes de manière plus souple que le systême de GRANT traditionnel. Le filtre est considéré comme une solution par le meilleur effort et à pour but principal de protéger contre les erreurs et non les attaques.
• insertstream: (⚠ : Expérimental) Permet de convertir des INSERT en masse en une seul commande LOAD DATA LOCAL INFILE afin de réduire l'utilisation du traffic et augmenter la vitesse des insertions de masse.
• cache: (⚠ : N'est pas au courant des droits utilisateurs) Permet de cacher le retour d'un SELECT tant qu'il n'y a pas eu d'écriture afin d'augmenter la vitesse de retour d'un SELECT identique.
• tee: Permet de copier une requête et de l'envoyée vers un autre service.
• throttle: Permet de limité la fréquence des requêtes.
• binlogfilter: Permet de faire de la réplication partiel avec binlogrouter.

Utilisation

Pour utiliser MariaDB MaxScale il suffit de l'utiliser comme un serveur MySQL normal:

$ mysql --host <adresse du serveur maxscale> --user=USER --password base_de_donnée

Configuration avancée

Limiter le retard visible

Cela se fait au niveau du routeur et n'est possible que pour le routeur Readwritesplit, readconnroute étant trop léger pour permettre ce genre de configurations.

Pour que le routage ne se fasse pas du tout sur un serveur secondaire ayant un trop grand retard il faut préciser la valeur de l'option max_slave_replication_lag avec le nombre de secondes de lags autorisées. Pour que le routeur "attende" que le serveur secondaire puisse retourner une valeur consistente lors d'une lecture suivant des modifications de données, il faut définir l'option causal_reads à true et que les serveurs ai le paramètre session_track_system_variables défini à last_gtid.