Meilleures pratiques pour l’équilibrage de charge TiDB

L’équilibrage de charge distribue les connexions des applications aux instances du serveur TiDB. Cela permet de répartir la charge sur plusieurs machines et, selon l’option d’équilibrage de charge, peut automatiquement réacheminer les connexions si une instance TiDB devient indisponible.

Types d’équilibrage de charge

Il existe de nombreuses façons d’implémenter un équilibreur de charge. Cette section décrit les types les plus courants.

Le premier type d’équilibrage de charge disponible est équilibrage de charge basé sur le connecteur. De nombreux connecteurs MySQL comme MySQL Connector/J et MySQL Connector/C++. Les avantages de cette approche sont qu’il n’y a pas de saut de réseau supplémentaire et que l’application dispose de plus d’informations sur le serveur auquel elle est connectée. Les inconvénients sont qu’il n’y a pas d’administration centrale, et, lorsque vous modifiez la configuration, vous devez la modifier sur tous vos hôtes d’application. Selon le langage de programmation que vous utilisez, l’équilibrage de charge peut ne pas être disponible ou ne pas offrir d’options plus avancées. L’équilibrage de charge basé sur le connecteur peut fonctionner avec la plupart des applications tierces car il est souvent configuré dans la chaîne de connexion, par exemple, l’URL JDBC (Java Database Connectivity).

Vous pouvez également utiliser DNS à tour de rôle. Cependant, cela n’est pas conseillé car cela n’empêche pas les connexions d’aller vers une machine indisponible. Cela signifie que si tous les serveurs ne sont pas disponibles, votre application devra peut-être réessayer les connexions plus souvent. Certains des nouveaux connecteurs MySQL prennent en charge DNS SRV. Ceci est quelque peu similaire au DNS à tour de rôle, mais vous permet de définir des priorités. L’avantage de DNS SRV est qu’il s’agit d’une norme de l’industrie, ce qui facilite la configuration côté client.

Si vous utilisez Kubernetes, vous souhaiterez probablement utiliser le type de service LoadBalancer qui fonctionne avec Amazon ELB et des services similaires d’autres fournisseurs de cloud. Pour Kubernetes sur site, vous pouvez utiliser quelque chose comme metallb.

Même si vous n’utilisez pas Kubernetes pour déployer sur un service cloud, vous pouvez toujours utiliser le service d’équilibrage de charge de votre fournisseur de cloud.

Une autre option courante consiste à utiliser un basé sur un logiciel équilibreur de charge, tel que ProxySQL, HAProxy ou MySQL Router.

Le dernier type d’équilibrage de charge utilise basé sur le matériel équilibreurs de charge. Ce sont des machines physiques sur lesquelles vous branchez un câble réseau. Ceux-ci sont souvent coûteux mais offrent également un débit élevé.

Exigences générales d’équilibrage de charge pour TiDB

Les exigences que TiDB impose aux équilibreurs de charge sont à certains égards différentes de celles requises par une configuration MySQL typique.

Là où les équilibreurs de charge peuvent offrir des fonctionnalités avancées telles que la division lecture/écriture pour MySQL, TiDB n’en a pas besoin. L’équilibreur de charge n’a pas à inspecter le protocole MySQL. Un équilibreur de charge au niveau TCP fonctionne bien pour TiDB.

L’équilibreur de charge n’a besoin d’accéder qu’aux serveurs TiDB (par défaut sur le port TCP 4000) et n’a pas besoin d’accéder aux serveurs Placement Driver (PD) ou TiKV. Lorsque vous utilisez l’API de statut (port TCP 10080 par défaut), l’accès à ce port est également requis.

Nous vous recommandons d’utiliser http://<ip_of_tidb>:10080/status que le bilan de santé car il prend en charge la arrêt gracieux caractéristique. Cette fonctionnalité vous permet de drainer les connexions client avant d’arrêter un serveur TiDB et réduit l’impact sur les applications. Pour bénéficier de cette fonctionnalité, vous devez définir le graceful-wait-before-shutdown variable à une valeur non nulle.

Vous devez éviter les bilans de santé qui vérifient read_only ou d’autres variables spécifiques à MySQL ou InnoDB. Ces variables sont souvent implémentées en tant que « noop » sur TiDB.

Où placer votre équilibreur de charge

Pour les équilibreurs de charge logiciels, vous pouvez placer votre équilibreur de charge sur le même hôte que votre application ou sur des hôtes distincts. Les deux ont leurs avantages.

Installation de l’équilibreur de charge sur le même hôte qu’un side-car à votre application est bon pour les performances car il n’a pas besoin d’un saut réseau supplémentaire. Cependant, vous devrez administrer de nombreuses instances de votre logiciel d’équilibrage de charge, ce qui complique légèrement les choses.

L’installation de l’équilibreur de charge sur des hôtes distincts augmente généralement la latence car vous avez besoin d’un tronçon de réseau supplémentaire. Selon votre réseau, il existe également un risque que la connectivité vers et depuis l’équilibreur de charge soit saturée. Cependant, par rapport à l’approche side-car, cette méthode est moins compliquée à administrer.

Lorsque vous choisissez entre ces options, la haute disponibilité est également un facteur important. Avec la première configuration, un équilibreur de charge indisponible n’affecte qu’un seul hôte d’application. Avec la deuxième solution, vous devrez probablement prendre des mesures pour rendre votre logiciel d’équilibrage de charge hautement disponible, ce qui complique la configuration.

Tester l’équilibrage de charge

Avant de déployer l’équilibrage de charge en production, vous devez d’abord tester la configuration pour vous assurer que tout fonctionne comme prévu. Vous devez également tester des modifications de configuration plus importantes, des mises à niveau et d’autres tâches de maintenance avant de les effectuer sur une configuration de production.

Vous pouvez effectuer des tests locaux avec tiup playground --db 2. Cela vous donne deux instances TiDB, qui vous permettent de voir comment les connexions passent de l’une à l’autre pendant le test.

Lorsque vous vous connectez via un équilibreur de charge, vous pouvez utiliser cette requête pour vérifier sur quelle instance vous avez atterri :

SELECT @@hostname, @@port

Lorsque vous utilisez mysql -h localhost..., mysql essaiera de se connecter via un socket UNIX même si un port TCP est fourni. Selon votre configuration, cela peut ne pas fonctionner. Au lieu de cela, utilisez mysql -h 127.0.0.1... pour s’assurer que la connexion utilise TCP.

Exemples de configuration

Cette section comprend des exemples de configuration pour certaines des solutions d’équilibrage de charge les plus populaires avec TiDB.

ProxySQL

ProxySQL est un proxy open source hautes performances pour le protocole MySQL. ProxySQL connaît le protocole MySQL ; cela apporte de nombreuses fonctionnalités spécifiques à MySQL, telles que la mise en cache et la réécriture des requêtes.

La première étape consiste à installer ProxySQL. Pour plus de détails et d’instructions pour d’autres plates-formes, consultez Télécharger et installer ProxySQL.

sudo dnf install proxysql

Pour configurer ProxySQL, vous pouvez soit utiliser le fichier de configuration (/etc/proxysql.cnf) ou l’interface d’administration. L’interface d’administration utilise le protocole MySQL et est disponible sur le port 6032. Les identifiants par défaut sont 'admin"https://dzone.com/"admin'.

mysql -h 127.0.0.1 -P 6032 -u admin -padmin --prompt 'admin> '

L’étape suivante consiste à informer ProxySQL des serveurs TiDB :

admin> INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (1, '127.0.0.1', 4000);
Query OK, 1 row affected (0.00 sec)

admin> INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (1, '127.0.0.1', 4001);
Query OK, 1 row affected (0.00 sec)

admin> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.00 sec)

admin> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.04 sec)

Par défaut, ProxySQL utilise un compte appelé « moniteur » pour tester la connectivité aux serveurs principaux. Alors maintenant, créez cet utilisateur. Le nom d’utilisateur et le mot de passe de cet utilisateur sont définis dans ProxySQL via le mysql-monitor_username et mysql-monitor_password variables, vous pouvez donc les modifier si vous le souhaitez.

tidb> CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
Query OK, 0 rows affected (0.06 sec)

Ajoutez maintenant un utilisateur à ProxySQL qui correspond à l’utilisateur ‘root’ par défaut qui est disponible dans un tiup playground.

admin> INSERT INTO mysql_users(username,password,default_hostgroup) VALUES ('root','',1);
Query OK, 1 row affected (0.00 sec)

admin> LOAD MYSQL USERS TO RUNTIME;
Query OK, 0 rows affected (0.00 sec)

admin> SAVE MYSQL USERS TO DISK;
Query OK, 0 rows affected (0.04 sec)

Essayez maintenant de vous connecter :

$ mysql -h 127.0.0.1 -P 6033 -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 8
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.7.25-TiDB-v5.0.0 |
+--------------------+
1 row in set (0.00 sec)

Le port par défaut pour le trafic applicatif pour ProxySQL est 6033 (3306 à l’envers !).

Si vous ne souhaitez pas utiliser le routage des requêtes ou la mise en cache des requêtes, vous pouvez activer fast_forward qui est défini dans le mysql_users table. Cela réduit la quantité de travail que le proxy doit effectuer pour chaque connexion, ce qui réduit légèrement la latence.

HAProxy

HAProxy est un équilibreur de charge hautes performances qui est principalement connu pour l’équilibrage de charge HTTP. Cependant, vous pouvez également l’utiliser comme équilibreur de charge TCP. Outre un contrôle de santé de base, il ne connaît pas le protocole MySQL.

Commencez par installer HAProxy :

Configurez ensuite HAProxy en éditant /etc/haproxy/haproxy.cfg et en ajoutant :

listen tidb
    mode tcp
    bind 127.0.0.1:3306
    balance leastconn
    option mysql-check user root
    server tidb1 127.0.0.1:4000 check
    server tidb2 127.0.0.1:4001 check
frontend stats
    bind 127.0.0.1:8080
    stats enable
    stats uri /
    stats refresh 10s
    stats admin if LOCALHOST

Cela ajoute un service tidb avec deux serveurs principaux. Cela acheminera les connexions vers le serveur avec le moins de connexions. Cela permet une vérification spécifique au protocole MySQL pour voir si les serveurs principaux sont sains.

Les stats La partie est facultative et permet à une interface Web de voir les statistiques et de gérer les serveurs.

Ici 127.0.0.1 a été utilisé pour se lier à localhost uniquement. Si vous souhaitez autoriser les connexions externes, utilisez bind ::3306.

Sur les systèmes avec SELinux activé, le port TCP 3306 est étiqueté comme mysqld_port_t. Autoriser

HAProxy to use this port, do the following. If SELinux is not enabled, you can skip this step.

sudo setsebool -P haproxy_connect_any 1

Démarrez maintenant HAProxy :

sudo systemctl enable haproxy --now

Routeur MySQL

MySQL Router est une solution d’équilibrage de charge open source pour le protocole MySQL de l’équipe MySQL d’Oracle.

Tout d’abord, installez MySQL Router. Suivez les instructions de la documentation de la plate-forme de votre choix. Pour cet exemple, j’utilise Linux.

sudo rpm -ivh https://dev.mysql.com/get/mysql80-community-release-fc34-1.noarch.rpm
sudo dnf install mysql-router

Configurez maintenant le routeur en ajoutant ce qui suit à /etc/mysqlrouter/mysqlrouter.conf:

[routing:tidb]
bind_address = 127.0.0.1:6446
routing_strategy =...