Préparer un serveur MySQL ou MariaDB pour la production - Deuxième partie

Dans le blog précédent, nous avons couvert quelques trucs et astuces pour préparer un serveur MySQL pour une utilisation en production du point de vue de l'administrateur système. Cet article de blog est la suite... 

Utiliser un outil de sauvegarde de base de données

Chaque outil de sauvegarde a ses propres avantages et inconvénients. Par exemple, Percona Xtrabackup (ou MariaDB Backup pour MariaDB) peut effectuer une sauvegarde physique à chaud sans verrouiller les bases de données, mais elle ne peut être restaurée qu'à la même version sur une autre instance. Alors que pour mysqldump, il est compatible avec les autres versions majeures de MySQL et beaucoup plus simple pour la sauvegarde partielle, bien qu'il soit relativement plus lent lors de la restauration par rapport à Percona Xtrabackup sur de grandes bases de données. MySQL 5.7 introduit également mysqlpump, similaire à mysqldump avec des capacités de traitement parallèle pour accélérer le processus de vidage.

Ne manquez pas de configurer tous ces outils de sauvegarde sur votre serveur MySQL car ils sont disponibles gratuitement et très critiques pour la récupération de données. Étant donné que mysqldump et mysqlpump sont déjà inclus dans MySQL 5.7 et versions ultérieures, nous avons juste besoin d'installer Percona Xtrabackup (ou MariaDB Backup pour MariaDB) mais cela nécessite quelques préparations, comme indiqué dans les étapes suivantes :

Première étape

Assurez-vous que l'outil de sauvegarde et ses dépendances sont installés :

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

Pour les serveurs MariaDB, utilisez plutôt MariaDB Backup :

$ yum install -y socat pv MariaDB-Backup

Étape 2

Créez l'utilisateur 'xtrabackup' sur le maître s'il n'existe pas :

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Étape 3

Créez un autre utilisateur appelé 'mysqldump' sur master s'il n'existe pas. Cet utilisateur sera utilisé pour 'mysqldump' et 'mysqlpump' :

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

Étape 4

Ajoutez les informations d'identification des utilisateurs de sauvegarde dans le fichier de configuration MySQL sous les directives [xtrabackup], [mysqldump] et [mysqlpump] :

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

En spécifiant les lignes ci-dessus, nous n'avons pas besoin de spécifier le nom d'utilisateur et le mot de passe dans la commande de sauvegarde puisque l'outil de sauvegarde chargera automatiquement ces options de configuration à partir du fichier de configuration principal.

Assurez-vous que les outils de sauvegarde sont correctement testés au préalable. Pour Xtrabackup qui prend en charge le streaming de sauvegarde via le réseau, cela doit d'abord être testé pour s'assurer que la liaison de communication peut être établie correctement entre le serveur source et le serveur de destination. Sur le serveur de destination, exécutez la commande suivante pour que socat écoute le port 9999 et soit prêt à accepter le streaming entrant :

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Ensuite, créez une sauvegarde sur le serveur source et diffusez-la sur le port 9999 sur le serveur de destination :

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Vous devriez obtenir un flux continu de sortie après avoir exécuté la commande de sauvegarde. Attendez de voir la ligne "Completed OK" indiquant une sauvegarde réussie.

Avec pv, nous pouvons limiter l'utilisation de la bande passante ou voir la progression comme un processus qui le traverse. Généralement, le processus de diffusion en continu saturera le réseau si aucune limitation n'est activée, ce qui pourrait entraîner des problèmes avec d'autres serveurs pour interagir avec un autre dans le même segment. En utilisant pv, nous pouvons limiter le processus de streaming avant de le transmettre à l'outil de streaming comme socat ou netcat. L'exemple suivant montre que le streaming de sauvegarde sera limité à environ 80 Mo/s pour les connexions entrantes et sortantes :

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

Le streaming d'une sauvegarde est couramment utilisé pour organiser un esclave ou stocker la sauvegarde à distance sur un autre serveur.

Pour mysqldump et mysqlpump, nous pouvons tester avec les commandes suivantes :

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Assurez-vous que des lignes sans erreur apparaissent dans la sortie.

Testez le serveur sous contrainte

Les tests de résistance du serveur de base de données sont importants pour comprendre la capacité maximale que nous pouvons anticiper pour le serveur en question. Cela deviendra utile lorsque vous approcherez des seuils ou des goulots d'étranglement à un stade ultérieur. Vous pouvez utiliser de nombreux outils de benchmarking disponibles sur le marché comme mysqlslap, DBT2 et sysbench.

Dans cet exemple, nous utilisons sysbench pour mesurer les performances de pointe du serveur, le niveau de saturation ainsi que la température des composants lors de l'exécution dans un environnement à forte charge de travail de base de données. Cela vous donnera une idée de la qualité du serveur et vous permettra d'anticiper la charge de travail que le serveur peut traiter pour notre application en production.

Pour installer et configurer sysbench, vous pouvez le compiler à partir de la source ou installer le package à partir du référentiel Percona :

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Créez le schéma et l'utilisateur de la base de données sur le serveur MySQL :

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Générez les données de test :

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Ensuite, exécutez le benchmark pendant 1 heure (3 600 secondes) :

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

Pendant que le test est en cours d'exécution, utilisez iostat (disponible dans le package sysstat) dans un autre terminal pour surveiller l'utilisation du disque, la bande passante, les IOPS et l'attente d'E/S :

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

Le résultat ci-dessus sera imprimé toutes les 60 secondes. Attendez la fin du test et prenez la moyenne de r/s (lectures/seconde), w/s (écritures/seconde), %iowait, %util, rkB/s et wkB/s (bande passante). Si vous constatez une utilisation relativement faible du disque, du processeur, de la RAM ou du réseau, vous devez probablement augmenter la valeur "--threads" à un nombre encore plus élevé afin d'utiliser toutes les ressources jusqu'à la limite.

Considérez les aspects suivants à mesurer :

• Requêtes par seconde =Résumé Sysbench une fois le test terminé sous Statistiques SQL -> Requêtes -> Par seconde
• Latence de la requête =résumé Sysbench une fois le test terminé sous Latence (ms) -> 95e centile.
• IOPS de disque =Moyenne de r/s + w/s
• Utilisation du disque =Moyenne de %util
• Bande passante disque R/W =Moyenne de rkB/s / Moyenne de wkB/s
• Attente E/S disque =Moyenne de %iattente
• Charge moyenne du serveur =charge moyenne moyenne telle que rapportée par la commande top.
• Utilisation du processeur MySQL =Utilisation moyenne du processeur telle que rapportée par la commande top.

Avec ClusterControl, vous pouvez facilement observer et obtenir les informations ci-dessus via le panneau de présentation des nœuds, comme illustré dans la capture d'écran suivante :

En outre, les informations recueillies lors du test de résistance peuvent être utilisées pour régler MySQL et les variables InnoDB en conséquence comme innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads et aussi max_connections.

Pour en savoir plus sur l'analyse comparative des performances de MySQL à l'aide de sysbench, consultez cet article de blog, Comment comparer les performances de MySQL et MariaDB à l'aide de SysBench.

Utiliser un outil de changement de schéma en ligne

Le changement de schéma est quelque chose d'inévitable dans les bases de données relationnelles. Au fur et à mesure que l'application grandit et devient plus exigeante, elle nécessite certainement une modification de la structure de la base de données. Certaines opérations DDL reconstruiront la table, bloquant ainsi l'exécution d'autres instructions DML, ce qui pourrait avoir un impact sur la disponibilité de votre base de données si vous effectuez des modifications structurelles sur une table énorme. Pour voir la liste des opérations DDL bloquantes, consultez cette page de documentation MySQL et recherchez les opérations qui ont "Permits Concurrent DML" =No.

Si vous ne pouvez pas vous permettre de temps d'arrêt sur les serveurs de production lors de la modification du schéma, il est probablement judicieux de configurer l'outil de modification de schéma en ligne dès le début. Dans cet exemple, nous installons et configurons gh-ost, un changement de schéma en ligne construit par Github. Gh-ost utilise le flux de journal binaire pour capturer les modifications de table et les applique de manière asynchrone sur la table fantôme.

Pour installer gh-ost sur un boîtier CentOS, suivez simplement les étapes suivantes : 

Première étape

 Téléchargez le dernier fantôme ici : 

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Étape 2

Installez le paquet :

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm 

Étape 3

Créez un utilisateur de base de données pour gh-ost s'il n'existe pas, et accordez-lui les privilèges appropriés :

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** Remplacez {host} et {db_name} par leurs valeurs appropriées. Idéalement, l'{hôte} est l'un des hôtes esclaves qui effectuera le changement de schéma en ligne. Reportez-vous à la documentation de gh-ost pour plus de détails.

Étape 4

Créez un fichier de configuration gh-ost pour stocker le nom d'utilisateur et le mot de passe sous /root/.gh-ost.cnf :

[client]
user=gh-ost
password=ghostP455

De même, vous pouvez configurer Percona Toolkit Online Schema Change (pt-osc) sur le serveur de base de données. L'idée est de vous assurer que vous êtes d'abord préparé avec cet outil sur le serveur de base de données susceptible d'exécuter cette opération à l'avenir.

Utiliser la boîte à outils Percona

Percona Toolkit est une collection d'outils de ligne de commande open source avancés, développés par Percona, qui sont conçus pour effectuer une variété de tâches serveur et système MySQL, MongoDB et PostgreSQL qui sont trop difficiles ou complexes pour effectuer manuellement. Ces outils sont devenus le sauveur ultime, utilisés par les DBA du monde entier pour traiter ou résoudre les problèmes techniques rencontrés dans les serveurs MySQL et MariaDB.

Pour installer Percona Toolkit, exécutez simplement la commande suivante :

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

Il y a plus de 30 outils disponibles dans ce package. Certains d'entre eux sont spécifiquement conçus pour MongoDB et PostgreSQL. Certains des outils les plus populaires pour le dépannage et le réglage des performances de MySQL sont pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync et pt-archiver. Cette boîte à outils peut aider les DBA à vérifier l'intégrité de la réplication MySQL en vérifiant la cohérence des données maître et réplique, à archiver efficacement les lignes, à trouver les index en double, à analyser les requêtes MySQL à partir des journaux et tcpdump et bien plus encore.

L'exemple suivant montre l'une des sorties d'outils (pt-table-checksum) où il peut effectuer une vérification de cohérence de la réplication en ligne en exécutant des requêtes de somme de contrôle sur le maître, ce qui produit des résultats différents sur les répliques qui sont incohérentes avec le maître :

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

La sortie ci-dessus montre qu'il y a 3 tables sur l'esclave (mysql2.local) qui sont incohérentes avec le maître. Nous pouvons ensuite utiliser l'outil pt-table-sync pour corriger les données manquantes du maître, ou simplement resynchroniser l'esclave une fois de plus.

Verrouiller le serveur

Enfin, une fois l'étape de configuration et de préparation terminée, nous pouvons isoler le nœud de la base de données du réseau public et restreindre l'accès au serveur aux hôtes et réseaux connus. Vous pouvez utiliser un pare-feu (iptables, firewalld, ufw), des groupes de sécurité, hosts.allow et/ou hosts.deny ou simplement désactiver l'interface réseau qui fait face à Internet si vous avez plusieurs interfaces réseau.

Pour iptables, il est important de spécifier un commentaire pour chaque règle en utilisant le drapeau '-m comment --comment' :

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

De même pour le pare-feu d'Ubuntu (ufw), nous devons d'abord définir la règle par défaut, puis créer des règles similaires pour MySQL/MariaDB similaires à ceci :

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

Activer le pare-feu :

$ ufw enable

Ensuite, vérifiez que les règles sont correctement chargées :

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

Encore une fois, il est très important de spécifier des commentaires sur chaque règle pour nous aider à mieux comprendre la règle.

Pour la restriction d'accès à la base de données à distance, nous pouvons également utiliser un serveur VPN, comme indiqué dans cet article de blog, Utilisation d'OpenVPN pour sécuriser l'accès à votre cluster de bases de données dans le cloud.

Conclusion

Préparer un serveur de production n'est évidemment pas une tâche facile, comme nous l'avons montré dans cette série de blogs. Si vous craignez de vous tromper, pourquoi n'utilisez-vous pas ClusterControl pour déployer votre cluster de bases de données ? ClusterControl a une très bonne expérience dans le déploiement de bases de données et a permis plus de 70 000 déploiements MySQL et MariaDB pour tous les environnements à ce jour.