MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Nouveautés de MariaDB MaxScale 2.4

MaxScale 2.4 est sorti le 21 décembre 2019 et ClusterControl 1.7.6 prend en charge la surveillance et la gestion jusqu'à cette version. Cependant, pour le déploiement, ClusterControl ne prend en charge que jusqu'à la version 2.3. Il faut mettre à niveau manuellement l'instance manuellement, et heureusement, les étapes de mise à niveau sont très simples. Téléchargez simplement la dernière version à partir de la page de téléchargement de MariaDB MaxScale et exécutez la commande d'installation du package.

Les commandes suivantes montrent comment mettre à niveau d'un MaxScale 2.3 existant vers MaxScale 2.4 sur une boîte 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.10

Dans cet article de blog, nous allons mettre en évidence certaines des améliorations notables et des nouvelles fonctionnalités de cette version et à quoi elle ressemble en action. Pour une liste complète des modifications apportées à MariaDB MaxScale 2.4, consultez son journal des modifications.

Historique des commandes du mode interactif

Il s'agit essentiellement d'une petite amélioration avec un impact majeur sur l'administration de MaxScale et l'efficacité des tâches de surveillance. Le mode interactif pour MaxCtrl a maintenant son historique de commandes. L'historique des commandes vous permet de répéter facilement la commande exécutée en appuyant sur la touche fléchée vers le haut ou vers le bas. Cependant, la fonctionnalité Ctrl+R (rappeler la dernière commande correspondant aux caractères que vous fournissez) n'est toujours pas là.

Dans les versions précédentes, il fallait utiliser le mode shell standard pour s'assurer que les commandes sont capturées par le fichier .bash_history.

Surveillance GTID pour galeramon

Il s'agit d'une bonne amélioration pour ceux qui exécutent Galera Cluster avec une redondance géographique via une réplication asynchrone, également appelée réplication cluster à cluster, ou réplication MariaDB Galera Cluster sur MariaDB Replication.

Dans MaxScale 2.3 et versions antérieures, voici à quoi cela ressemble si vous avez activé la réplication maître-esclave entre les clusters MariaDB :

Pour MaxScale 2.4, il ressemble maintenant à ceci (faites attention à Galera1 rangée):

Il est désormais plus facile de voir l'état de réplication de tous les nœuds à partir de MaxScale, sans la nécessité de vérifier plusieurs nœuds individuels à plusieurs reprises.

SmartRouter

C'est l'une des nouvelles fonctionnalités majeures de MaxScale 2.4, où MaxScale est maintenant assez intelligent pour savoir quel serveur backend MariaDB est le meilleur pour traiter la requête. SmartRouter assure le suivi des performances, ou du temps d'exécution, des requêtes adressées aux clusters. Les mesures sont stockées avec le canonique d'une requête comme clé. Le canonique d'une requête est le SQL avec toutes les constantes définies par l'utilisateur remplacées par des points d'interrogation, par exemple :

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

Il s'agit d'une fonctionnalité très utile si vous exécutez MariaDB sur une réplication géographique multisite ou un mélange de moteurs de stockage MariaDB dans une chaîne de réplication, par exemple, un esclave dédié pour gérer les charges de travail de transaction (OLTP ) avec le moteur de stockage InnoDB et un autre esclave dédié pour gérer les charges de travail analytiques (OLAP) avec le moteur de stockage Columnstore.

Supposons que nous ayons deux sites :Sydney et Singapour, comme illustré dans le schéma suivant :

Le site principal est situé à Singapour et possède un maître MariaDB et un esclave , tandis qu'un autre esclave en lecture seule est situé à Sydney. L'application se connecte à l'instance MaxScale située dans son pays respectif avec les paramètres de port suivants :

  • Répartition lecture-écriture :3306
  • Tourniquet :3307
  • Routeur intelligent :3308

Nos définitions de service et d'écoute SmarRouter sont :

[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 = 3308

Redémarrez MaxScale et commencez à envoyer une requête en lecture seule aux deux nœuds MaxScale situés à Singapour et à Sydney. Si la requête est traitée par le routeur round-robin (port 3307), nous verrions que la requête est acheminée en fonction de l'algorithme round-robin :

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

D'après ce qui précède, nous pouvons dire que MaxScale de Sydney a transmis la requête ci-dessus à notre esclave de Singapour, ce qui n'est pas la meilleure option de routage en soi.

Avec SmartRouter écoutant sur le port 3308, nous verrions que la requête est acheminée vers l'esclave le plus proche à Sydney :

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

Et si la même requête est exécutée sur notre site de Singapour, elle sera routée vers l'esclave MariaDB situé à Singapour :

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Il y a cependant un hic. Lorsque SmartRouter voit une requête de lecture dont le canonique n'a pas été vu auparavant, il enverra la requête à tous les clusters. La première réponse d'un cluster désignera ce cluster comme le meilleur pour ce canonique. Aussi, lorsque la première réponse est reçue, les autres requêtes sont annulées. La réponse est envoyée au client une fois que tous les clusters ont répondu à la requête ou à l'annulation.

Cela signifie que pour garder une trace de la requête canonique (requête normalisée) et mesurer ses performances, vous verrez probablement que la toute première requête échoue lors de sa première exécution, par exemple :

(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 query

D'après le journal général de MariaDB Sydney, nous pouvons dire que la première requête (ID 74) a été exécutée avec succès (connexion, requête et quit), malgré l'erreur "Connexion perdue" de MaxScale :

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Alors que la requête suivante identique a été correctement traitée et renvoyée avec la bonne réponse :

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

En regardant à nouveau le journal général dans MariaDB Sydney (ID 75), les mêmes événements de traitement se sont produits comme pour la première requête :

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

De cette observation, nous pouvons conclure que MaxScale doit parfois échouer à la première requête afin de mesurer les performances et devenir plus intelligent pour les requêtes identiques suivantes. Votre application doit être capable de gérer correctement cette "première erreur" avant de retourner au client ou de réessayer la transaction une fois de plus.

Socket UNIX pour serveur

Il existe plusieurs façons de se connecter à un serveur MySQL ou MariaDB en cours d'exécution. Vous pouvez utiliser le réseau TCP/IP standard avec l'adresse IP et le port de l'hôte (connexion à distance), les canaux nommés/mémoire partagée sous Windows ou les fichiers de socket Unix sur les systèmes basés sur Unix. Le fichier de socket UNIX est un type spécial de fichier qui facilite les communications entre différents processus, qui dans ce cas sont le client MySQL et le serveur. Le fichier socket est une communication basée sur des fichiers et vous ne pouvez pas accéder au socket depuis une autre machine. Il fournit une connexion plus rapide que TCP/IP (pas de surcharge réseau) et une approche de connexion plus sécurisée, car il ne peut être utilisé que lors de la connexion à un service ou à un processus sur le même ordinateur.

Supposons que le serveur MaxScale soit également installé sur le serveur MariaDB lui-même, nous pouvons utiliser le fichier socket socket UNIX à la place. Sous la section Serveur, supprimez ou commentez la ligne "adresse" et ajoutez le paramètre socket avec l'emplacement du fichier socket :

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Avant d'appliquer les modifications ci-dessus, nous devons créer un utilisateur MaxScale axscale à partir de localhost. Sur le serveur maître :

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';

Après un redémarrage, MaxScale affichera le chemin du socket UNIX au lieu de l'adresse réelle, et la liste des serveurs sera affichée comme ceci :

Comme vous pouvez le voir, les informations d'état et GTID sont récupérées correctement via une connexion socket. Notez que ce DB_2 écoute toujours le port 3306 pour les connexions distantes. Cela montre simplement que MaxScale utilise un socket pour se connecter à ce serveur à des fins de surveillance.

L'utilisation de socket est toujours meilleure car elle n'autorise que les connexions locales et est plus sécurisée. Vous pouvez également fermer votre serveur MariaDB à partir du réseau (par exemple, --skip-networking) et laisser MaxScale gérer les connexions "externes" et les transmettre au serveur MariaDB via le fichier socket UNIX.

Vidange du serveur

Dans MaxScale 2.4, les serveurs principaux peuvent être drainés, ce qui signifie que les connexions existantes peuvent continuer à être utilisées, mais aucune nouvelle connexion ne sera créée sur le serveur. Avec la fonction de vidange, nous pouvons effectuer une activité de maintenance gracieuse sans affecter l'expérience utilisateur du côté de l'application. Notez que le drainage d'un serveur peut prendre plus de temps, selon les requêtes en cours d'exécution qui doivent être fermées avec élégance.

Pour vider un serveur, utilisez la commande suivante :

L'effet secondaire peut être l'un des états suivants :

  • Drainage :le serveur est en cours de drainage.
  • Drained - Le serveur a été vidé. Le serveur était en train d'être vidé et maintenant le nombre de connexions au serveur est tombé à 0.
  • Maintenance :le serveur est en cours de maintenance.

Après qu'un serveur a été vidé, l'état du serveur MariaDB du point de vue de MaxScale est "Maintenance":

Lorsqu'un serveur est en mode maintenance, aucune connexion ne sera créée et les connexions existantes seront fermées.

Conclusion

MaxScale 2.4 apporte de nombreuses améliorations et modifications par rapport à la version précédente et c'est le meilleur proxy de base de données pour gérer les serveurs MariaDB et tous ses composants.