Tag: MariaDB

Réinitialiser le mot de passe root de MySQL ou MariaDB sous Debian

30 September 202128 décembre 2019 by Matt Biscay · Lecture: 2 minutes

Chez l’un de mes clients, nous avons eu besoin de réinitialiser le mot de passe MySQL de l’utilisateur root, qui a été oublié.

Je vous avais déjà décrit comment réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB sous Ubuntu.

Comme le serveur tourne sous Debian, nous avons un moyen très simple d’avoir accès à la base mysql pour modifier le mot de passe root. Cela ne prend que quelques secondes.

L’utilisateur debian-maintenance à la rescousse

Sous les systèmes à base Debian, il existe par défaut un utilisateur nommé debian-sys-maint, qui se charge de routines de maintenance sur la base SQL et qui possède tous les droits d’administration sur toutes les bases de données.

Il se trouve que le mot de passe de l’utilisateur debian-sys-maint est visible, en clair dans ce fichier:

nano /etc/mysql/debian.cnf

Copiez le mot de passe. Ensuite, connectez-vous avec debian-sys-maint au serveur de base de données:

mysql -u debian-sys-maint -p

Vous êtes maintenant connecté au serveur de base de données, en tant qu’administrateur, sous l’utilisateur debian-sys-maint.

Tous les utilisateurs de la base de données sont stockés dans la base mysqldonc on commence par la sélectionner:

use mysql;Code language: PHP (php)

Et on peut maintenant changer le mot de passe de l’utilisateur root avec une simple mise à jour du mot de passe:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('^*p4!_BHLn6Q&xuft*^5tjyby7^_$)d7_fgf&zec8#ExV@xY');
flush privileges;Code language: JavaScript (javascript)

Il ne reste plus qu’à quitter MySQL monitor:

quit;

Voilà, le mot de passe de l’utilisateur rootest désormais changé. Vous pouvez vous identifier normalement avec le nouveau mot de passe que vous venez de définir plus haut:

mysql -u root -p
Enter password:

Une astuce toujours utile à garder sous le coude!

Serveur dédié : installation de MariaDB 10.3 photo

MariaDB : résoudre l’erreur “Column count of mysql.proc is wrong”

3 October 202127 avril 2019 by Matt Biscay · Lecture: 1 minute

Sur l’un des serveurs de mes clients Codeable, j’ai mis à jour MariaDB de la version 10.1 à la version 10.3 et voici ce que retournait MariaDB lors du lancement de procédures:

ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20. 
Created with MariaDB 100212, now running 100303. 
Please use mysql_upgrade to fix this errorCode language: JavaScript (javascript)

Si cela arrive, pas de panique: MariaDB fonctionne et le site s’affiche mais la base de données mysql n’a pas été mise à jour par apt, il faut lancer la procédure d’installation manuellement, depuis le terminal.

On met donc la base mysql à jour avec mysql-upgrade:

mysql_upgrade -u root -p

et on relance MariaDB:

service mysql restart

La routine de mise à jour mysql_upgrade permet de mettre à jour la base interne de MariaDB, qui évolue au fil des mises à jour.

Au redémarrage du service, plus de problème avec les procédures SQL.

MariaDB ne veut plus redémarrer : quelques solutions

3 October 202122 avril 2019 by Matt Biscay · Lecture: 4 minutes

MariaDB ne veut plus se lancer

Sur le serveur chinois que j’ai monté pour un de mes clients sur Codeable, le site a commencé à afficher des erreurs étranges : erreur 502 pour nginx sur certaines pages et des nombres étranges en lieu et place des données de la base de données.

Après un redémarrage des services PHP, nginx et mysql, je constate que MariaDB veut bien s’arrêter mais ne veut plus de lancer.

Voici ce que donne:

systemctl status mariadb.serviceCode language: CSS (css)

Résultat:

● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-04-22 18:14:22 CST; 59s ago
  Process: 721 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 718 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12274 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
  Process: 12179 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12176 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12173 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12274 (code=exited, status=1/FAILURE)
   Status: "MariaDB server is down"
systemd[1]: Starting MariaDB database server…
mysqld[12274]: 2019-04-22 18:14:19 140194687476288 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12274 …
systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start MariaDB database server.
systemd[1]: mariadb.service: Unit entered failed state.
systemd[1]: mariadb.service: Failed with result 'exit-code'.Code language: PHP (php)

Bon, chou blanc. Cela ne nous donne aucune information exploitable quand à l’erreur qui empêche le démarrage du service de base de données.

Solution: vérifier l’espace disponible sur le disque du serveur

On regarde ensuite ce que nous donnent les logs de MariaDB:

tail -f /var/log/mysql/error.logCode language: JavaScript (javascript)

Résultat:

2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Completed initialization of buffer pool
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Highest supported file format is Barracuda.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: 128 rollback segment(s) are active.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Waiting for purge to start
2019-04-22 18:14:19 140194687476288 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 11397472969
2019-04-22 18:14:19 140194687476288 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-22 18:14:19 140194687476288 [ERROR] mysqld: Can't change size of file (Errcode: 28 "No space left on device")
2019-04-22 18:14:19 140194687476288 [ERROR] Can't init tc log
2019-04-22 18:14:19 140194687476288 [ERROR] AbortingCode language: PHP (php)

Là, c’est beaucoup plus intéressant. Visiblement, deux erreurs majeures sont à l’origine du non-démarrage du service:

il n’y a plus d’espace disponible sur le disque dur du serveur,
le fichier /var/lib/mysql/tc.log ne peut pas être initialisé.

Après un petit df, il s’avère que le client a installé un plugin de sauvegarde qui a littéralement saturé tout l’espace disponible.

Après un petit ménage, il ne reste plus qu’à gérer la seconde erreur, Can’t init tc log.

Le fichier /var/lib/mysql/tc.log peut parfois souffrir d’un problème de permission.

Dans le cas du client, on l’archive par précaution:

mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bakup.logCode language: JavaScript (javascript)

Puis on relance le serveur MariaDB:

service mysql start

On vérifie le statut du service:

service mysql status

qui nous retourne:

service mysql status
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-04-22 18:17:22 CST; 1h 37min ago
  Process: 12467 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12464 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12340 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12337 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12334 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12437 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 29 (limit: 4915)
   CGroup: /system.slice/mariadb.service
           └─12437 /usr/sbin/mysqld

Apr 22 18:17:20 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Starting MariaDB database server...
Apr 22 18:17:21 iZuf6aj6jz83uxa0jgbgcrZ mysqld[12437]: 2019-04-22 18:17:21 139940495544896 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12437 ...
Apr 22 18:17:22 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Started MariaDB database server.Code language: PHP (php)

A noter que l’erreur 502 de nginx n’était pas due à une mauvaise configuration du server block mais bien d’un manque d’espace disque.

C’est important à vérifier, avant de se lancer dans la dissection du fichier de configuration d’nginx (qui n’aurait pas réglé le problème dans ce cas précis).

Cron : résoudre l’erreur logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operator

24 March 202224 décembre 2018 by Matt Biscay · Lecture: 1 minute

Depuis que j’ai déplacé les bases de données SQL sur une autre partition, logrotate semble avoir quelques soucis avec l’archivage des logs de MariaDB. Voici le message d’erreur complet :

/etc/cron.daily/logrotate: logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operatorCode language: JavaScript (javascript)

C’est en fait un problème de regex connu et la solution est très simple.

1. On édite le fichier /etc/logrotate.d/mysql-server:

nano /etc/logrotate.d/mysql-server

2. on recherche la ligne avec la regex de grep:

if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; thenCode language: CSS (css)

3. on ajoute m1 aux arguments de grep, ce qui nous donne:

if [ -f `my_print_defaults --mysqld | grep -oPm1 "pid-file=\K[^$]+"` ]; thenCode language: CSS (css)

Sauvegardez le fichier. Vous ne recevrez plus de message d’erreur lors du lancement de la tâche cron et les fichiers logs de MySQL/MariaDB seront bien archivés.

Serveur dédié : installation de MariaDB 10.3

23 December 201823 décembre 2018 by Matt Biscay · Lecture: 1 minute

Debian Stretch possède MariaDB 10.1 mais au vu des améliorations récentes de MariaDB, il est intéressant de passer à la version 10.3 pour des raisons de performance.

Ajout du nouveau dépôt

On installe les dépendances et on ajoute le dépôt de MariaDB 10.3 à notre fichier de configuration apt, ainsi que la clé du dépôt:

apt install software-properties-common dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.3/debian stretch main'Code language: JavaScript (javascript)

Mise à jour de MariaDB

Une fois que la clé du dépôt est ajoutée au trousseau, on installe la nouvelle mouture de MariaDB:

apt update
apt install mariadb-server

Notez que vous pouvez choisir la version de MariaDB à installer très facilement depuis le site officiel.

Et voilà, serveur de base de données mis à jour.

MariaDB : changer le répertoire des bases de données sous Debian photo

Serveur dédié : déplacer les bases de données MariaDB ou MySQL sur une autre partition

24 March 202220 décembre 2018 by Matt Biscay · Lecture: 4 minutes

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes.

Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;Code language: CSS (css)

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)Code language: JavaScript (javascript)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home.

Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = falseCode language: JavaScript (javascript)

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

Serveur dédié : réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB

3 October 202109 octobre 2017 by Matt Biscay · Lecture: 3 minutes

Pour les besoins d’un de mes clients préférés, j’ai eu la grande joie de paramétrer un VPS aux petits oignons avec réplication des données à la volée.

C’est un projet fascinant que j’ai déjà abordé dans la série réplication de données.

Au moment de la réalisation des bases de données, je demande à mon client le mot de passe root du serveur de base de données pour y créer de nouveaux utilisateurs. La réponse ne se fait pas attendre : “je n’ai pas ce mot de passe mais j’ai confiance en toi Matt, tu pourras aisément contourner le problème!”.

Challenge accepted.

Voici donc un mini-tutoriel pour réinitialiser le mot de passe root quand vous ne ~~l’avez jamais eu~~ vous en souvenez plus.

Vous aurez besoin de deux fenêtres de terminal, que je nomme ici terminal1 et terminal2.

Etape 1 : lancer mysqld_safe

Voici le principe de la manipulation : nous allons “occuper” le serveur MySQL ou MariaDB en lançant le daemon mysqld_safe dans un terminal et nous allons lancer un second terminal qui nous permettre de réinitialiser le mot de passe root.

C’est parti : dans le terminal1, nous commençons par arrêter le serveur SQL:

service mysql stop

puis lançons mysqld_safe :

mysqld_safe --skip-grant-tables --skip-syslog --skip-networking

Le terminal semble arrêté ou attendre quelque chose : c’est bon signe, laissez-le comme ça pour le moment.

WordPress : changer le mot de passe d’un utilisateur depuis le serveur SQL

30 September 202128 septembre 2017 by Matt Biscay · Lecture: 2 minutes

Il peut être nécessaire de changer le mot de passe d’un utilisateur WordPress par exemple lorsque l’on migre un compte, lorsque l’on repart de zéro avec une base de données vierge ou lorsque le mot de passe du site de développement diffère de celui du site de production.

Ou tout simplement pour en mettre un plus facile à retenir.

Voici donc comment changer le mot de passe d’un utilisateur WordPress directement depuis un terminal connecté sur le serveur de la base de données.

Changer le mot de passe d’un utilisateur WordPress depuis MariaDB

1. Connectez-vous au serveur de base de données :

mysql -u root -p

puis entrez votre mot de passe :

Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.Code language: JavaScript (javascript)

2. Sélectionnez la base de données qui contient l’installation WordPress concernée :

USE wordpress_wpdb;Code language: PHP (php)

Résultat :

Database changed

3. Vérifiez que votre utilisateur (ici : matt) est bien présent dans la base :

SELECT ID, user_login, user_pass FROM wp_users WHERE user_login LIKE '%matt%';Code language: JavaScript (javascript)

Résultat:

+----+-------------+------------------------------------+
| ID | user_login  | user_pass                          |
+----+-------------+------------------------------------+
| 78 | matt                | $P$BUZ6Uvu8aie2tBEWqwTu07qfzlKXc80 |
+----+-------------+------------------------------------+
1 row in set (0.00 sec)Code language: PHP (php)

4. Choisissez un mot de passe (ici: q8U@jM5uNMa*R66R), qui sera automatiquement chiffré en MD5 :

UPDATE wp_users SET user_pass = MD5('q8U@jM5uNMa*R66R') WHERE ID=78 LIMIT 1;Code language: JavaScript (javascript)

Résultat:

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0Code language: CSS (css)

Créer un serveur High Availability : la réplication des bases de données photo

MariaDB : résoudre l’erreur 1062 (duplicate entry for key PRIMARY) lors de la réplication des bases de données

30 September 202107 juillet 2017 by Matt Biscay · Lecture: 4 minutes

Si vous utilisez les fonctions de réplication de MySQL ou MariaDB, il peut arriver que votre slave bloque sur une instruction qui devrait avoir un identifiant unique mais que le serveur tente d’insérer deux fois.

Et quand c’est le cas, la réplication des données prend fin donc c’est un problème à corriger rapidement si vous voulez que votre système haute disponibilité perdure et soit vraiment efficace en cas de coup dur.

Identification du problème

Je me suis rendu compte du problème lorsque j’ai ajouté de nouvelles bases à répliquer : j’ai relancé la procédure d’installation, relancé les serveurs, ajouté les nouvelles positions, démarré les slaves.

On regarde le status du slave :

MariaDB [(none)]> SHOW SLAVE STATUS\GCode language: CSS (css)

Résultat :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.134.23.164
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000210
          Read_Master_Log_Pos: 2753885
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 103794
        Relay_Master_Log_File: mariadb-bin.000210
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1062
                   Last_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1563407
              Relay_Log_Space: 1296874
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1062
               Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
      Replicate_Do_Domain_Ids:
  Replicate_Ignore_Domain_Ids:
                Parallel_Mode: conservative
1 row in set (0.00 sec)Code language: JavaScript (javascript)

Comme on peut le constater, plusieurs choses ne tournent pas rond et empêchent la synchronisation des données entre nos deux serveurs :

Slave_SQL_Running: No
Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '56-724' for key 'PRIMARY'' on query. Default database: 'frenchy'. Query: 'INSERT INTO `wp_term_relationships` (`object_id`, `term_taxonomy_id`) VALUES (56, 724)'Code language: JavaScript (javascript)

Solution : un RESET sur le slave

En me documentant sur le problème, j’ai lu pas mal de choses sur le net. Certains préfèrent cacher l’erreur, au risque de perdre des données. D’autres préfèrent tout effacer pour recommencer la réplication.

Aucune de ces “solutions” ne me conviennent donc nous allons procéder autrement. Comme l’erreur n’apparaît que sur le serveur BACKUP et non sur le serveur principal, c’est sur lui que nous travaillerons.

Sur le serveur BACKUP, dans MariaDB, on arrête notre slave :

MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected (0.01 sec)Code language: CSS (css)

On flush les privilèges et donc les utilisateurs connectés :

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Code language: CSS (css)

On efface les fichiers logs de notre slave. C’est comme effacer une ardoise pour repartir sur des bases saines. Cela ne supprime aucune donnée – cf le manuel sur RESET :

MariaDB [(none)]> RESET SLAVE;
Query OK, 0 rows affected (0.00 sec)Code language: CSS (css)

Et on redémarre notre slave :

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.00 sec)Code language: CSS (css)

On vérifie de nouveau le status de notre slave :

MariaDB [(none)]> SHOW SLAVE STATUS\GCode language: CSS (css)

Résultat :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.134.23.164
                  Master_User: replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000196
          Read_Master_Log_Pos: 77900062
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 6318821
        Relay_Master_Log_File: mariadb-bin.000192
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 6318531
              Relay_Log_Space: 344030331
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 833890
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
      Replicate_Do_Domain_Ids:
  Replicate_Ignore_Domain_Ids:
                Parallel_Mode: conservative
1 row in set (0.00 sec)Code language: CSS (css)

Nous avons bien :

Slave_IO_Running: Yes
Slave_SQL_Running: YesCode language: HTTP (http)

Et voilà, plus d’erreur et une réplication active dans les deux sens.

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

22 August 202105 mai 2017 by Matt Biscay · Lecture: 10 minutes

Aujourd’hui, nous sautons le pas et passons du serveur Apache au serveur NginX (à prononcer “engine X”) pour booster les performances générales du site.

Cela fait quelques serveurs que je monte pour d’autres en utilisant nginx et force est de constater que c’est beaucoup plus réactif qu’Apache et cela prend moins de temps à configurer pour optimiser les réglages.

Je pars du principe que c’est une nouvelle installation mais si vous aviez déjà votre site qui tournait sous Apache, certaines étapes seront juste optionnelles.

Ce tutoriel vise un serveur Debian mais est adaptable sans problème à ses dérivés comme Ubuntu ou Mint.

Etape 1 : NginX

Nous allons installer la dernière version du serveur nginx, avec le support pour HTTP2, depuis les dépôts Sury :

nano /etc/apt/sources.listCode language: PHP (php)

et nous ajoutons :

# SURY, post-Dotdeb
deb https://packages.sury.org/php/ stretch main
deb https://packages.sury.org/nginx-mainline/ stretch main
deb https://packages.sury.org/mariadb/ stretch mainCode language: PHP (php)

On rafraîchit les dépôts :

apt update

et on installe nginx et openssl :

apt install nginx openssl libssl1.0.2 libssl1.0.1 libssl-devCode language: CSS (css)

Etape 2 : MariaDB

Si vous ne l’avez pas déjà – cela remplace MySQL sans que vous n’ayez rien à changer au niveau du code ou de la configuration du serveur :

apt install mariadb-server

Etape 3 : PHP

Je vous conseille de suivre mon dernier guide pour installer PHP 7.1.

Etape 4 : configurer NginX

Nous allons d’abord configurer toutes les options qui nous sont primordiales : compression des fichiers statiques, implémentation SSL, types mime… afin de gagner du temps (et éviter les erreurs) dans l’étape suivante.

1. Nous voulons un site rapide donc nous allons compresser tout ce qui peut l’être. On crée un nouveau fichier :

nano /etc/nginx/snippets/gzip-config.conf

et on y met :

# MATT : add more mime-types to compress
types {
	application/x-font-ttf           ttf;
	font/opentype                    ott;
}

# MATT : gzip all the things!
 gzip on;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_proxied any;
 gzip_comp_level 6;
 gzip_min_length 256;
 gzip_buffers 16 8k;
 gzip_http_version 1.1;
 #gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  # Compress all output labeled with one of the following MIME-types.
 gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/ld+json
    application/manifest+json
    application/rss+xml
    application/vnd.geo+json
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/bmp
    image/svg+xml
    image/x-icon
    text/cache-manifest
    text/css
    text/plain
    text/vcard
    text/vnd.rim.location.xloc
    text/vtt
    text/x-component
    text/x-cross-domain-policy;
# text/html is always compressed by gzip module
# don't compress woff/woff2 as they're compressed alreadyCode language: PHP (php)

J’ai ajouté deux types mime qui ne sont pas dans la configuration de base d’NginX et étendu la liste des types de fichiers à compresser. Certains types le sont déjà donc c’est inutile de gaspiller des ressources en essayant de les compresser.

Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”

24 March 202204 avril 2016 by Matt Biscay · Lecture: 6 minutes

Les inodes perdues ! Cette semaine, j’ai eu droit à un problème particulier sur le serveur : alors que rien dans la configuration des services n’a été changé, je me suis rendu compte que WordPress ne réagissait pas comme d’habitude.

Les symptômes les plus visibles sont la lenteur de l’application, l’impossibilité de mettre à jour ou corriger un article ou encore ajouter des tags à un nouvel article.

J’avais déjà connu cet état lors d’un crash de la base SQL il y a maintenant quelques années donc je me suis dit que j’allais commencer par redémarrer Apache puis réparer la base de données.

Suppression des instances Apache et redémarrage du service

Dès le lancement de la session SSH, il est évident que quelque chose ne tourne pas rond. Après le message de bienvenue, un message d’erreur apparaît :

/usr/bin/xauth:  error in locking authority file /root/.Xauthority

Et en voulant arrêter Apache, on obtient:

Restarting web server: apache2. [error]
There are processes named 'apache2' running which do not match your pidCode language: JavaScript (javascript)

On commence donc par régler ce problème et on regarde quels sont les PID utilisés par Apache:

pidof apache2

La commande pidof nous retourne toute une liste de pid:

32691 31385 31154 30917 30663 29150 27368 24820 24563 17531 15227 14235 13559 13064 11028 10906 10256 9156 9144 9042 8855 8542

On met fin à toutes ces instances avec un simple kill -9:

kill -9 32691 31385 31154 30917 30663 29150 27368 24820 24563 17531 15227 14235 13559 13064 11028 10906 10256 9156 9144 9042 8855 8542

Une fois toutes les instances d’Apache supprimées, il nous est de nouveau possible de redémarrer le service normalement:

service apache2 restart

Ménage dans l’espace disque et le nombre d’inodes disponibles

Au moment de réparer les tables de la base de données, rebelote, erreur :

No space left on device (error 28)

On commence par un petit ménage dans les paquets obsolètes, qui ne résoudra pas grand-chose:

apt-get autoclean && apt-get autoremoveCode language: JavaScript (javascript)

Je tente un simple df pour vérifier si les disques sont pleins :

df

mais visiblement, non, il reste bien de la place :

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       9.8G  4.4G  5.0G  47% /
devtmpfs        2.0G     0  2.0G   0% /dev
tmpfs           390M  408K  390M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           780M     0  780M   0% /run/shm
/dev/sda2       683G  531G  118G  82% /homeCode language: PHP (php)

Je tente alors un df -i pour vérifier le nombres d’inodes disponibles :

df -i

Un nœud d’index ou inode (contraction de l’anglais index et node) est une structure de données contenant des informations à propos d’un fichier stocké dans les systèmes de fichiers Linux/Unix.

À chaque fichier correspond un numéro d’inode (i-number) dans le système de fichiers dans lequel il réside, unique au périphérique sur lequel il est situé.

Les inodes contiennent notamment les métadonnées des systèmes de fichiers, et en particulier celles concernant les droits d’accès.

Les inodes sont créés lors de la création du système de fichiers. La quantité d’inodes (généralement déterminée lors du formatage et dépendant de la taille de la partition) indique le nombre maximum de fichiers que le système de fichiers peut contenir.

Dans notre cas, catastrophe, il ne reste quasiment plus d’inodes disponibles !

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/root        640K  640K     6   100% /
devtmpfs         487K  1.5K  486K    1% /dev
tmpfs            488K   864  487K    1% /run
tmpfs            488K    10  488K    1% /run/lock
tmpfs            488K     2  488K    1% /run/shm
/dev/sda2         44M   37K   43M    1% /home

Serveur dédié : migration de MySQL vers MariaDB

30 September 202121 septembre 2015 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, on aborde la migration du serveur de base de données : nous passons de l’historique MySQL à son fork libre MariaDB.

Les raisons de remplacer Oracle MySQL avec MariaDB sont nombreuses.

MySQL vs MariaDB

Tout d’abord, MariaDB assure la compatibilité et la continuité de service avec MySQL. Les librairies sont exactement équivalentes et permettent d’utiliser les APIs et commandes de MySQL.

Les performances de MariaDB sont souvent meilleures que celles de MySQL, notamment grâce à l’amélioration de l’optimiseur de requêtes et l’intégration du moteur XtraDB de Percona, qui vise à remplacer InnoDB.

Un nouveau moteur de stockage, Aria, a été écrit pour devenir un moteur à la fois transactionnel et non-transactionnel pour remplacer MyISAM. Il pourrait même être inclus dans de prochaines versions de MySQL.

Dans un autre registre, Oracle semble ne pas vouloir garder le modèle libre de MySQL : pas mal de choses (rapports de bugs, scénarios de test) sont maintenant disponibles uniquement pour les grands comptes payants.

Michael “Monty” Widenius, le fondateur de MySQL AB, a quitté Sun Microsystems lors de son rachat par Oracle pour créer Monty Program AB puis la Fondation MariaDB. Il est rapidement rejoint par de nombreux développeurs originaux de MySQL.

Ces développeurs maîtrisent donc parfaitement le code source du système de gestion de base de données, cela promet encore de nombreuses nouveautés et optimisations pour les versions suivantes.

Installation de MariaDB

Avant toute chose, faîtes une sauvegarde de vos bases de données. On ne sait jamais.

Notre serveur dédié tourne toujours sur Debian stable et les paquets de MariaDB sont disponibles dans les dépôts officiels.

MariaDB est un “drop-in replacement” pour MySQL, c’est -à-dire qu’il suffit de désinstaller MySQL et d’installer MariaDB : rien ne change, pas de pertes de données, pas de lignes de code à changer, tout est compatible.

L’installation est donc très simple :

apt-get install mariadb-serverCode language: JavaScript (javascript)

Résultat:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common
  mariadb-server-10.0 mariadb-server-core-10.0
Suggested packages:
  mariadb-test tinyca
The following packages will be REMOVED:
  mysql-client-5.6 mysql-client-core-5.6 mysql-server mysql-server-5.6
  mysql-server-core-5.6
The following NEW packages will be installed:
  mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server
  mariadb-server-10.0 mariadb-server-core-10.0
0 upgraded, 6 newly installed, 5 to remove and 0 not upgraded.
Need to get 11.8 MB of archives.
After this operation, 18.4 MB disk space will be freed.Code language: CSS (css)

L’installation vous demandera de donner un mot de passe pour l’utilisateur root. De manière à assurer la continuité avec MySQL, j’ai redonné le même mot de passe que pour mon utilisateur root sous MySQL.