152 lines
9.1 KiB
Markdown
152 lines
9.1 KiB
Markdown
---
|
||
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](https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/) soit [télécharger le paquet depuis le site officiel](https://mariadb.com/downloads/#mariadb_platform-mariadb_maxscale).
|
||
|
||
## 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
|
||
|
||
~~~{.ini}
|
||
[dbserver1]
|
||
type = server
|
||
address = 192.0.2.100
|
||
port = 3306
|
||
protocol = MariaDBBackend
|
||
~~~
|
||
|
||
~~~{.ini}
|
||
[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, cet utilisateur a besoin du droit `REPLICATION CLIENT on *.*` pour `mariadbmon` (pour `galeramon`, aucun droit particulier n'est nécessaire)
|
||
* `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:
|
||
|
||
~~~{.ini}
|
||
[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:
|
||
|
||
~~~{.ini}
|
||
[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.
|
||
|
||
L'utilisateur utilisé par le service a besoin des droits suivants:
|
||
|
||
~~~{.sql}
|
||
GRANT SELECT ON mysql.user TO 'USER'@'%';
|
||
GRANT SELECT ON mysql.db TO 'USER'@'%';
|
||
GRANT SELECT ON mysql.tables_priv TO 'USER'@'%';
|
||
GRANT SELECT ON mysql.columns_priv TO 'USER'@'%';
|
||
GRANT SELECT ON mysql.proxies_priv TO 'USER'@'%';
|
||
GRANT SELECT ON mysql.roles_mapping TO 'USER'@'%';
|
||
GRANT SHOW DATABASES ON *.* TO 'USER'@'%';
|
||
~~~
|
||
|
||
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:
|
||
|
||
~~~{.ini}
|
||
[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`.
|