Il est extrêmement important d'installer et de configurer un serveur MySQL de production avec les packages et les outils nécessaires pour faciliter les opérations à long terme. Nous avons vu de nombreux cas où le dépannage ou le réglage d'un serveur de production (en particulier un sans accès public à Internet) est généralement difficile en raison du manque d'outils nécessaires installés sur le serveur pour aider à identifier et résoudre le problème.
Dans cette série de blogs en deux parties, nous allons vous montrer 9 trucs et astuces sur la façon de préparer un serveur MySQL pour une utilisation en production du point de vue de l'administrateur système. Tous les exemples de cet article de blog sont basés sur notre configuration de réplication MySQL maître-esclave à deux nœuds exécutée sur CentOS 7.
Installer les packages essentiels
Après l'installation des packages client et serveur MySQL ou MariaDB, nous devons préparer le serveur MySQL/MariaDB avec tous les outils nécessaires pour faire face à toutes les opérations d'administration, de gestion et de surveillance qui vont se produire sur le serveur. Si vous envisagez de verrouiller le serveur MySQL en production, il sera un peu plus difficile de tous les installer manuellement sans connexion Internet.
Certains des packages importants qui doivent être installés sur le serveur MySQL/MariaDB pour Linux :
- Percona Xtrabackup/MariaDB Backup - Sauvegarde physique non bloquante du serveur de base de données.
- ntp/ntpdate - Synchroniser l'heure du serveur.
- pv - Surveiller les données via un pipeline, peut également être utilisé pour la limitation.
- socat ou netcat- Outil de streaming de données, bon pour la sauvegarde en continu.
- net-tools - Une collection d'outils de débogage réseau pour Linux.
- bind-utils :une collection d'outils de débogage DNS pour Linux.
- sysstat - Une collection d'outils de surveillance des performances pour Linux.
- telnet - Client Telnet pour vérifier l'accessibilité du service.
- mailx/mailutils - Client MTA.
- openssl - Boîte à outils pour les protocoles Transport Layer Security (TLS) et Secure Sockets Layer (SSL).
- unzip - Outil de décompression.
- htop - Outil de surveillance de l'hôte.
- innotop - Outil de surveillance MySQL.
- vim - Éditeur de texte avec coloration syntaxique (ou tout éditeur de texte préféré).
- python-setuptools - Gestionnaire de packages Python.
- lm_sensors/ipmitool - Pour vérifier la température des composants du serveur. Serveur bare metal uniquement.
Notez que certains des packages suggérés ne sont disponibles que dans des référentiels de packages autres que ceux par défaut, tels que EPEL pour CentOS. Par conséquent, pour une installation basée sur YUM :
$ yum install epel-release
$ yum install -y wget ntp pv socat htop innotop vim mailx bind-utils net-tools telnet sysstat openssl python-setuptools lm_sensors ipmitoolAlors que pour une installation basée sur APT :
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitoolPour l'interface de ligne de commande MySQL, nous pouvons utiliser un autre outil que le client de ligne de commande "mysql" standard comme mycli, avec auto-complétion et coloration syntaxique. Pour installer le package, nous pouvons utiliser pip (gestionnaire de packages Python) :
$ pip install mycliAvec mycli, on peut réduire le vecteur d'erreur humaine avec une meilleure visualisation lorsqu'il s'agit d'un serveur de production, comme le montre la capture d'écran suivante :
Invite Shell significative
Cette partie semble inutile en premier lieu, mais elle vous évitera probablement de faire des erreurs stupides en production. En tant qu'humain, nous sommes enclins à faire des erreurs, en particulier lors de l'exécution de commandes destructrices pendant un moment intense, par exemple lorsque le serveur de production est en panne.
Regardez la capture d'écran suivante. Par défaut, l'invite bash PS1 (invite principale) semble assez terne :
Une bonne invite PS1 doit fournir des informations distinctes pour rendre les administrateurs système plus conscients de la l'environnement, le serveur et le chemin actuel auxquels ils sont actuellement confrontés. Du coup, on serait plus prudent et on saurait toujours si c'est dans le bon chemin/serveur/utilisateur pour exécuter la commande.
Pour y parvenir, recherchez la ligne décrivant la configuration PS1 (invite principale), généralement dans /etc/bashrc ligne 41 :
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "Et remplacez-le par cette ligne :
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[\e[36m\]\u\[\e[m\]@\[\e[32m\]\h\[\e[m\]\[\e[31;47m\]Production\[\e[m\]: \[\e[33m\]\w\[\e[m\]]$ "Déconnectez-vous du terminal et reconnectez-vous. Vous devriez maintenant voir quelque chose comme ceci dans le terminal :
Comme indiqué dans la capture d'écran ci-dessus, l'utilisateur actuel (bleu), le serveur le nom d'hôte (vert), le niveau de production (gras en rouge sur fond blanc), ainsi que le chemin complet du répertoire actuel (jaune) fournissent un meilleur résumé de la session en cours où les informations importantes se distinguent facilement avec différentes couleurs.
Vous pouvez utiliser cet outil en ligne gratuit pour personnaliser votre invite bash, selon vos goûts.
MOTD
Si vous gérez un cluster de bases de données avec plusieurs rôles comme la réplication MySQL ou MariaDB, il est courant d'avoir toujours ce sentiment d'anxiété lors de l'administration directe de l'un des hôtes car nous devons effectuer des vérifications supplémentaires pour vérifier que le nœud dans lequel nous nous trouvons est celui que nous voulons vraiment administrer. La topologie de réplication a tendance à devenir plus complexe à mesure que votre cluster de base de données évolue et il peut y avoir de nombreux rôles dans un cluster comme le maître intermédiaire, le serveur binlog, le maître de sauvegarde avec réplication semi-synchrone, les esclaves en lecture seule et également le serveur de vérification de sauvegarde.
Ce sera bien mieux si nous pouvons obtenir un résumé de l'état de la base de données chaque fois que nous sommes sur ce serveur particulier, juste pour nous donner une idée de ce que nous allons traiter. Nous pouvons utiliser le message du jour de Linux (MOTD) pour automatiser ce comportement chaque fois que nous nous connectons au serveur. L'utilisation de /etc/motd par défaut n'est bonne que pour le contenu statique, ce qui n'est pas ce que nous voulons vraiment si nous voulons signaler l'état actuel d'un serveur MySQL.
Pour obtenir un résultat similaire, nous pouvons utiliser un simple script Bash pour produire une sortie MOTD significative pour résumer notre serveur MySQL/MariaDB, par exemple :
$ vim ~/.motd.sh
#!/bin/bash
# Auto-generate MOTD for MySQL/MariaDB Replication
# .motd.sh, to be executed under ~/.bash_profile
#####
# Preferred role of the node, pick one
#PREFER_ROLE='Slave'
PREFER_ROLE='Master'
#####
HOSTNAME=$(hostname)
UPTIME=$(uptime -p)
MYSQL_COMMAND='mysql --connect-timeout=2 -A -Bse'
MYSQL_READONLY=$(${MYSQL_COMMAND} 'SHOW GLOBAL VARIABLES LIKE "read_only"' | awk {'print $2'})
TIER='Production'
MAIN_IP=$(hostname -I | awk {'print $1'})
CHECK_MYSQL_REPLICATION=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$')
MYSQL_MASTER=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | grep Master_Host | awk {'print $2'})
# The following requires show_compatibility_56=1 for MySQL 5.7 and later
MYSQL_UPTIME=$(${MYSQL_COMMAND} 'SELECT TIME_FORMAT(SEC_TO_TIME(VARIABLE_VALUE ),"%Hh %im") AS Uptime FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME="Uptime"')
# coloring
bold=$(tput bold)
red=$(tput setaf 1)
green=$(tput setaf 2)
normal=$(tput sgr0)
MYSQL_SHOW=1
if [ $MYSQL_READONLY == 'ON' ]; then
CURRENT_MYSQL_ROLE='Slave'
if ${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$' &>/dev/null ; then
lag=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Seconds_Behind_Master:' | awk {'print $2'})
if [ $lag -eq 0 ]; then
REPLICATION_STATUS="${green}Healthy "
else
if [ $lag == 'NULL' ]; then
REPLICATION_STATUS=${red}Unhealthy
else
REPLICATION_STATUS="${red}Lagging ${lag}s"
fi
fi
else
REPLICATION_STATUS=${red}Unhealthy
fi
elif [ $MYSQL_READONLY == 'OFF' ]; then
CURRENT_MYSQL_ROLE='Master'
SLAVE_HOSTS=$(${MYSQL_COMMAND} 'SHOW SLAVE HOSTS' | awk {'print $1'})
else
MYSQL_SHOW=0
fi
if [ $TIER == 'Production' ]; then
TIER=${green}Production
fi
if [ $PREFER_ROLE == $CURRENT_MYSQL_ROLE ]; then
MYSQL_ROLE=${green}$CURRENT_MYSQL_ROLE
else
MYSQL_ROLE=${red}$CURRENT_MYSQL_ROLE
fi
echo
echo "HOST INFO"
echo "========="
echo -e " Hostname : ${bold}$HOSTNAME${normal} \t Server Uptime : ${bold}$UPTIME${normal}"
echo -e " IP Address : ${bold}$MAIN_IP${normal} \t Tier : ${bold}$TIER${normal}"
echo
if [ $MYSQL_SHOW -eq 1 ]; then
echo "MYSQL STATE"
echo "==========="
echo -e " Current role : ${bold}$MYSQL_ROLE${normal} \t\t Read-only : ${bold}$MYSQL_READONLY${normal}"
echo -e " Preferred role : ${bold}$PREFER_ROLE${normal} \t\t DB Uptime : ${bold}$MYSQL_UPTIME${normal}"
if [ $CURRENT_MYSQL_ROLE == 'Slave' ]; then
echo -e " Replication state : ${bold}$REPLICATION_STATUS${normal} \t Current Master : ${bold}$MYSQL_MASTER${normal}"
else
echo -e " Slave Hosts(s) ID : "
for i in $SLAVE_HOSTS; do
echo -e " - ${bold}$i${normal} \t"; done
fi
echo
fiChoisissez l'un des rôles MySQL, soit un maître ou un esclave sur la ligne 8 ou 9 et enregistrez le script. Ce script nécessite le fichier d'options MySQL pour stocker les informations d'identification de l'utilisateur de la base de données, nous devons donc le créer en premier :
$ vim ~/.my.cnfEt ajoutez les lignes suivantes :
[client]
user=root
password='YourRootP4ssw0rd'Remplacez la partie mot de passe par le mot de passe racine MySQL réel. Ensuite, appliquez l'autorisation exécutable au script :
$ chmod 755 ~/.motd.shTestez le script exécutable s'il produit ou non la sortie correcte :
$ ~/.motd.shSi la sortie semble bonne (pas d'erreurs ou d'avertissements), ajoutez le script dans ~/.bash_profile afin qu'il soit automatiquement chargé lorsqu'un utilisateur se connecte :
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profileReconnectez-vous au terminal et vous devriez voir quelque chose comme ceci sur le maître :
Lorsque vous êtes sur l'esclave, vous devriez voir quelque chose comme ceci :
Notez que ce script est spécifiquement écrit pour un simple MySQL/MariaDB one- réplication maître-esclave de niveau. Vous devrez probablement modifier le script si vous avez une configuration plus complexe ou si vous souhaitez utiliser une autre technologie de clustering MySQL comme Galera Cluster, Group Replication ou NDB Cluster. L'idée est de récupérer l'état et les informations du nœud de la base de données dès que nous nous sommes connectés afin que nous soyons au courant de l'état actuel du serveur de base de données sur lequel nous travaillons.
Capteurs et température
Cette partie est généralement ignorée par de nombreux administrateurs système. La surveillance des températures est cruciale car nous ne voulons pas avoir de grosse surprise si le serveur se comporte de manière inattendue en cas de surchauffe. Un serveur physique se compose généralement de centaines de composants électroniques collés ensemble dans un boîtier et sont sensibles aux changements de température. Un ventilateur de refroidissement défaillant peut faire grimper la température du processeur jusqu'à sa limite stricte, ce qui finit par ralentir l'horloge du processeur et affecter les performances de traitement des données dans leur ensemble.
Nous pouvons utiliser le package lm-sensors à cet effet. Pour l'installer, faites simplement :
$ yum install lm-sensors # apt-get install lm-sensors for APTExécutez ensuite le programme sensors-detect pour déterminer automatiquement les modules du noyau que vous devez charger pour utiliser lm_sensors le plus efficacement :
$ sensors-detectRépond à toutes les questions (généralement, il suffit d'accepter toutes les réponses suggérées). Certains hôtes comme les machines virtuelles ou les conteneurs ne prennent pas en charge ce module. Les capteurs doivent vraiment être au niveau des hôtes (bare-metal). Consultez cette liste pour plus d'informations.
Ensuite, lancez la commande capteurs :
$ sensors
i350bb-pci-0203
Adapter: PCI adapter
loc1: +53.0°C (high = +120.0°C, crit = +110.0°C)
power_meter-acpi-0
Adapter: ACPI interface
power1: 4.29 MW (interval = 1.00 s)
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +55.0°C (high = +85.0°C, crit = +95.0°C)
Core 0: +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 1: +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 2: +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3: +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 4: +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 5: +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 8: +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9: +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 10: +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 11: +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 12: +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13: +49.0°C (high = +85.0°C, crit = +95.0°C)
coretemp-isa-0001
Adapter: ISA adapter
Package id 1: +53.0°C (high = +85.0°C, crit = +95.0°C)
Core 0: +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 1: +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 2: +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3: +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 4: +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 5: +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 8: +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9: +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 10: +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 11: +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 12: +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13: +46.0°C (high = +85.0°C, crit = +95.0°C)Le résultat ci-dessus montre la température globale du processeur, ainsi que chaque cœur du processeur. Un autre outil que nous pouvons utiliser pour voir l'état général des composants du serveur est ipmitool. Pour l'installer, faites simplement :
$ yum -y install ipmitoolEn exécutant la commande suivante, nous pouvons connaître l'état général des composants physiques du serveur :
$ ipmitool sdr list full
Inlet_Temp | 20 degrees C | ok
PCIe_Inlet_Temp | 37 degrees C | ok
Outlet_Temp | 20 degrees C | ok
CPU0_VR_Temp | 39 degrees C | ok
CPU1_VR_Temp | 41 degrees C | ok
CPU0_Temp | 55 degrees C | ok
CPU1_Temp | 52 degrees C | ok
PCH_Temp | 58 degrees C | ok
DIMMG0_Temp | 35 degrees C | ok
DIMMG1_Temp | 32 degrees C | ok
PSU0_Temp | 0 degrees C | ok
PSU1_Temp | 0 degrees C | ok
SYS_3.3V | 3.30 Volts | ok
SYS_5V | 5 Volts | ok
SYS_12V | 12.10 Volts | ok
CPU0_VCORE | 1.79 Volts | ok
CPU1_VCORE | 1.79 Volts | ok
CPU0_DDR_VDD | 1.23 Volts | ok
CPU1_DDR_VDD | 1.23 Volts | ok
SYS_FAN1_Speed | 4018 RPM | ok
SYS_FAN2_Speed | 4116 RPM | ok
SYS_FAN3_Speed | 4116 RPM | ok
SYS_FAN4_Speed | 4116 RPM | ok
SYS_FAN5_Speed | 4018 RPM | ok
SYS_FAN6_Speed | 4116 RPM | ok
SYS_FAN7_Speed | 4018 RPM | ok
SYS_FAN8_Speed | 4116 RPM | ok
SYS_FAN9_Speed | 4018 RPM | ok
SYS_FAN10_Speed | 4116 RPM | ok
SYS_FAN11_Speed | 4116 RPM | ok
SYS_FAN12_Speed | 4116 RPM | ok
SYS_FAN13_Speed | 4116 RPM | ok
SYS_FAN14_Speed | 4214 RPM | ok
Airflow_rate | 16 CFM | ok
PSU1_PIN | 0 Watts | ok
PSU2_PIN | 0 Watts | ok
PSU1_POUT | 0 Watts | ok
PSU2_POUT | 0 Watts | ok
PSU1_IIN | 0 Amps | ok
PSU2_IIN | 0 Amps | ok
PSU1_VIN | 0 Volts | ok
PSU2_VIN | 0 Volts | ok
CPU_Power | 63 Watts | ok
MEM_Power | 8 Watts | ok
Total_Power | 0 Watts | ok
BP_Power | 8 Watts | ok
FAN_Power | 6 Watts | ok
MB_Power | 0 Watts | okLa liste est longue mais s'explique d'elle-même et vous devriez être en mesure de surveiller l'état général des composants du serveur. Il peut y avoir des cas où certains des ventilateurs ne fonctionnent pas à pleine vitesse, ce qui augmente alors la température du processeur. Le remplacement du matériel peut être nécessaire pour résoudre le problème.
Notez que le module de noyau IPMI (Intelligent Platform Management Interface) nécessite que le contrôleur de gestion de la carte mère (BMC) soit activé sur la carte mère. Utilisez dmesg pour vérifier s'il est disponible :
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)Sinon, vérifiez les paramètres du BIOS du serveur si ce contrôleur est désactivé.
C'est tout pour le moment. La deuxième partie de cette série de blogs couvrira les 5 sujets restants, tels que la configuration de l'outil de sauvegarde, les tests de résistance et le verrouillage du serveur.
