typos
This commit is contained in:
jlecour
parent
9cc719f6a1
commit
87449815d4
|
|
@ -13,16 +13,16 @@ Pour installer MariaDB MaxScale il faut soit ajouter le [dépot officiel](https:
|
|||
|
||||
## 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.
|
||||
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 clientes 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 :
|
||||
Puisque MaxScale sert d'intermédiaire entre les applications clientes 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,
|
||||
* `port` ayant pour valeur le port sur lequel le serveur MySQL attend des connexions,
|
||||
* `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.
|
||||
* `protocol` qui est le protocole 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
|
||||
|
||||
|
|
@ -42,14 +42,14 @@ 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:
|
||||
Afin de pouvoir surveiller 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` ou `SUPER, SLAVE MONITOR ON *.*` a partir de MariaDB 10.5 (pour `galeramon`, aucun droit particulier n'est nécessaire)
|
||||
* `user` configurant l'utilisateur MySQL utiliser pour surveiller le cluster, cet utilisateur a besoin du droit `REPLICATION CLIENT on *.*` pour `mariadbmon` ou `SUPER, SLAVE MONITOR ON *.*` à partir de MariaDB 10.5 (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.
|
||||
D'autres clés de configurations sont disponibles pour chaques type de moniteur permettant de contrôler comment le moniteur interagi avec le cluster qu'il surveille.
|
||||
|
||||
Exemple de configuration de moniteur:
|
||||
|
||||
|
|
@ -62,14 +62,14 @@ 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 :
|
||||
MaxScale a ensuite besoin de savoir comment répartir la charge entre les serveurs, pour cela il faut configurer 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.
|
||||
* `readconnroute` qui se contente d'équilibrer les connexions 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 connexions 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, …
|
||||
* `user` l'utilisateur MySQL que MaxScale utilise pour récupérer la liste des utilisateurs, table, bases de données…
|
||||
* `password` mot de passe de cet utilisateur MySQL.
|
||||
|
||||
D'autres clés de configurations sont disponibles pour chaque type de routage.
|
||||
|
|
@ -99,7 +99,7 @@ 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é.
|
||||
Enfin, MaxScale doit être configuré pour attendre des connexions 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:
|
||||
|
||||
|
|
@ -111,29 +111,29 @@ 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@'%'`.
|
||||
> ⚠ : Les utilisateurs ont besoins de pouvoir se connecter aux 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.
|
||||
* Readconnroute qui permet de faire du routage par connexions, 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 une 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.
|
||||
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 bases de données.
|
||||
|
||||
### 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.
|
||||
MaxScale peut faire passer les statements SQL par des filtres avant de les envoyer au routeur et donc aux 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.
|
||||
* `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 a 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 seule commande `LOAD DATA LOCAL INFILE` afin de réduire l'utilisation du trafic 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`.
|
||||
* `throttle`: Permet de limiter la fréquence des requêtes.
|
||||
* `binlogfilter`: Permet de faire de la réplication partielle avec `binlogrouter`.
|
||||
|
||||
### Validation
|
||||
|
||||
|
|
@ -158,29 +158,29 @@ $ mysql --host <adresse du serveur maxscale> --user=USER --password base_de_donn
|
|||
|
||||
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`.
|
||||
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 aient le paramètre `session_track_system_variables` défini à `last_gtid`.
|
||||
|
||||
### Configuration du mode proxy_protocol
|
||||
|
||||
Si on a plusieurs serveurs qui doivent se connecter vers plusieurs serveurs SQL, on peux activé le mode `proxy_protocol` pour deux raisons :
|
||||
Si on a plusieurs serveurs qui doivent se connecter vers plusieurs serveurs SQL, on peut activer le mode `proxy_protocol` pour deux raisons :
|
||||
|
||||
* De pouvoir se connecter avec un utilisateur SQL, sans devoir recréer des utilisateurs `user@ip_server_maxscale`
|
||||
* De savoir quels hôtes est a l'origine d'une requête
|
||||
|
||||
Côté serveur MariaDB, on doit autorisé l'ip du serveur Maxscale, dans la variable `proxy_protocol_networks` :
|
||||
Côté serveur MariaDB, on doit autoriser l'ip du serveur Maxscale, dans la variable `proxy_protocol_networks` :
|
||||
|
||||
~~~
|
||||
proxy-protocol-networks=::1, 192.168.2.90, localhost
|
||||
~~~
|
||||
|
||||
La variable `proxy_protocol_networks` peut prendre des ips séparé par des virgules, ou alors on peux autorisé tout un sous-réseau par exemple `192.168.0.0/16`
|
||||
A partir de MariaDB 10.3.6, la variable est dynamique, on peux la modifié comme ceci :
|
||||
La variable `proxy_protocol_networks` peut prendre des ips séparé par des virgules, ou alors on peut autoriser tout un sous-réseau par exemple `192.168.0.0/16`
|
||||
A partir de MariaDB 10.3.6, la variable est dynamique, on peut la modifier comme ceci :
|
||||
|
||||
~~~
|
||||
MariaDB [(none)]> SET GLOBAL proxy_protocol_networks='::1, 192.168.2.90, localhost';
|
||||
~~~
|
||||
|
||||
Côté Maxscale, on doit rajouter l'option `proxy_protocol=true` dans la définition de chaque serveurs, dans `/etc/maxscale.cnf` :
|
||||
Côté Maxscale, on doit rajouter l'option `proxy_protocol=true` dans la définition de chaque serveur, dans `/etc/maxscale.cnf` :
|
||||
|
||||
~~~
|
||||
[dbserver1]
|
||||
|
|
@ -212,19 +212,19 @@ MariaDB [dbtest]> select user(), current_user();
|
|||
|
||||
### Création d'un utilisateur pour l'API REST Maxscale
|
||||
|
||||
Si on veux créer un utilisateur "simple" dans maxscale on jouera la commande suivante :
|
||||
Si on veut créer un utilisateur "simple" dans maxscale on jouera la commande suivante :
|
||||
|
||||
~~~
|
||||
# maxctrl create user maxscale_user maxscale_password
|
||||
~~~
|
||||
|
||||
Si on veux créer un utilisateur de type admin :
|
||||
Si on veut créer un utilisateur de type admin :
|
||||
|
||||
~~~
|
||||
# maxctrl create user maxscale_user maxscale_password --type=admin
|
||||
~~~
|
||||
|
||||
Si on veux supprimer un utilisateur :
|
||||
Si on veut supprimer un utilisateur :
|
||||
|
||||
~~~
|
||||
# maxctrl destroy user maxscale_user
|
||||
|
|
|
|||
Loading…
Reference in a new issue