WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key photo

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key

Chez Codeable, j’ai travaillé sur l’optimisation d’un site e-commerce propulsé par WooCommerce récemment, qui connaissait quelques problèmes de lenteur.

Sous phpMyAdmin, on trouvait également cette erreur:

Current selection does not contain a unique column

Si vous obtenez cette erreur, c’est que la structure de la table wp_options n’est pas à jour donc nous la vérifions avec wp-cli:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-root

Le résultat obtenu nous montre qu’il n’y a pas de clé primaire (primary key) qui est normalement option_id et qu’il n’y a pas de restriction unique imposée sur la colonne option_name:

+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| option_id    | bigint(20) unsigned | NO   |     | NULL    |       |
| option_name  | varchar(191)        | YES  |     | NULL    |       |
| option_value | longtext            | NO   |     | NULL    |       |
| autoload     | varchar(20)         | NO   |     | yes     |       |
+--------------+---------------------+------+-----+---------+-------+

Et c’est là que le bât blesse – voici à quoi ressemble la structure standard de la table wp-options:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   | MUL | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+

Ajouter la Primary Key manquante à wp_options

On ajoute à la colonne option_id la clé primaire qui lui manque:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options MODIFY option_id INT AUTO_INCREMENT PRIMARY KEY;" --allow-root

Et on vérifie le résultat:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-root

Ajouter la contrainte Unique qui manque à wp_options

Pour ajouter la contrainte UNIQUE à la colonne option_name, on lance:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-root

Là, il est possible que cela bloque, suivant ce qui se trouve dans votre table wp_options.

Résoudre le problème des doublons

Si vous obtenez une erreur comme :

ERROR 1062 (23000) at line 1: Duplicate entry 'jetpack_available_modules' for key 'option_name'

alors cela signifie qu’il existe des enregistrements option_name dupliqués, des doublons qui portent le même nom alors que chaque nom option_name devrait être unique.

On peut obtenir la liste des enregistrements option_name doublons avec cette requête:

wp db query "SELECT option_name, COUNT(*) optioncount FROM $(wp db prefix --allow-root)options GROUP BY option_name HAVING optioncount > 1 ORDER BY optioncount DESC;" --allow-root

Par ordre ascendant, voici la liste des doublons:

+---------------------------------------------+-------------+
| option_name                                 | optioncount |
+---------------------------------------------+-------------+
| jetpack_callables_sync_checksum             |       47123 |
| jetpack_sync_full_config                    |          50 |
| jetpack_sync_full_enqueue_status            |          43 |
| jpsq_sync_checkout                          |          10 |
| jetpack_sync_full__params                   |           5 |
| jetpack_sync_settings_sync_via_cron         |           4 |
| jetpack_sync_full__started                  |           4 |
+---------------------------------------------+-------------+

On peut supprimer automatiquement tous les doublons option_name de deux manières différentes, soit en utilisant la plus vieille valeuroption_id(donc la plus petite valeur d’ID), soit en utilisant la valeuroption_id la plus récente (plus grande valeur d’ID).

Garder le doublon option_name le plus ancien

Voici la requête SQL qui montre uniquement le plus ancien enregistrement (MIN) option_id pour chaque doublon de valeur option_name:

SELECT *
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options
        GROUP BY n.option_name) x)

Une fois que vous avez vérifié le résultat, on peut passer à la suppression.

Cette requête SQL garde l’enregistrement (MIN) option_id le plus ancien de tous les doublonsoption_name et supprime tous les enregistrements plus récents que la valeur trouvée:

DELETE
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)

Voici l’équivalent wp-cli:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MIN(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-root

Garder le doublon option_name le plus récent

Cette requête SQL ne montre que les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name :

SELECT *
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)

Et voici la requête qui permet de garder les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name en supprimant tous les doublons les plus anciens:

DELETE
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)

Voici l’équivalent wp-cli pour garder l’enregistrement option_name le plus récent:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MAX(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-root

Vérifier les clés et contraintes de la table wp_options

Ajoutons de nouveau la contrainte UNIQUE sur la colonne option_name :

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-root

Si vous n’obtenez pas d’erreur, vérifiez la table une nouvelle fois pour constater les changements:

wp db query "DESCRIBE $(wp db prefix --allow-root)options;" --allow-root

Kaboom! Votre table wp_options possède maintenant une PRIMARY KEY sur la colonne option_id et la contrainte UNIQUE sur la colonne option_name:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI |         |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+

Je vous conseille de vérifier la structure de la table de temps à autre, notamment si vous constatez une prise de poids anormale en très peu de temps

Ajouter un lien avec le nombre d'articles et le total du panier WooCommerce photo

Mettre à jour la base de données de WooCommerce avec wp-cli

Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.

Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.

La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.

Mise à jour de la base WooCommerce en ligne de commande

Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.

1. Connectez-vous au serveur en SSH.

2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:

wp wc update

Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :

wp wc update

Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0

3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.

Et voilà votre base de données WooCommerce à jour!

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

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

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.

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

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.

Lire la suite

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

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\G

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)

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

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)

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

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

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)

Et on redémarre notre slave :

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

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

MariaDB [(none)]> SHOW SLAVE STATUS\G

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)

Nous avons bien :

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

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

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

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

Ce tutoriel aborde la réplication des données d’un VPS ou serveur dédié : les bases de données seront répliquées d’un serveur principal (master) sur un autre serveur auxiliaire (backup).

En cas de défaillance du serveur principal, le serveur auxiliaire prendra le relais automatiquement.

Ce guide considère que vous avez :

  • deux VPS ou Droplets chez Digital Ocean dans le même datacenter;
  • une IP flottante qui peut être assignée à l’un ou l’autre des serveurs, à la demande;
  • le même système d’exploitation sur les deux serveurs, pour des raisons de compatibilité.

Créer une image du VPS principal pour le VPS de sauvegarde

Commençons par la base du système : le système d’exploitation (OS). Lorsque j’ai pris le projet en main, le site était déjà en production et tournait sur la dernière version d’Ubuntu Server, avec NginX, MariaDB et SSL activé.

On aurait pu tout réinstaller sur le nouveau VPS mais autant gagner du temps : Digital Ocean permet de faire une image du VPS existant et de l’installer sur un nouveau droplet. C’est quelques heures d’installation et de configuration d’économisées.

Voici les données de mes deux VPS :

MASTER

ipv4: 104.xxx.xxx.133
Private IP:  10.134.23.164

BACKUP

ipv4: 104.xxx.xxx.186
Private IP:  10.134.4.220

Floating IP

Floating IP:  138.xxx.xxx.177

Je masque les IP publiques puisque mes serveurs sont en production mais ces IP serviront pour le tuto : l’IP qui se termine en .133 est le Master, l’IP qui se termine en .186 est le Backup, et l’IP qui se termine en .177 est l’IP flottante.

Réplication de la base de données

Les deux serveurs LEMP sont maintenant identiques, même les fichiers et bases de données. Mais nous avons besoin d’avoir une base de données synchronisée en temps réel, dans les deux sens, master-master.

Si un serveur tombe, l’autre prend le relais. Lorsque le serveur Master revient à lui, le serveur Backup lui redonne les données SQL manquantes.

1. Configuration du serveur MASTER

On édite la configuration MariaDB:

nano /etc/mysql/my.cnf

On édite et remplace/ajoute :

# MATT - skyminds.net : MariaDB replication instructions.
# https://www.skyminds.net/?p=28739

# 1. bind-adress : replace 127.0.0.1 with Internal IP.
# bind-address          = 127.0.0.1
bind-address            = 10.134.23.164

# 2. enable log_bin
log_bin                 = /var/log/mysql/mariadb-bin
log_bin_index           = /var/log/mysql/mariadb-bin.index

# 3. add server-id AND binlog_do_db
# NOTE : server-id is a way to identify this server in MariaDB configs.
# NOTE : binlog_do_db contains the names of the databases to replicate
server-id               = 1
binlog_format=mixed
# first DB
binlog_do_db            = first_wpdb
# second DB
binlog_do_db            = second_wp

# /MATT

Nous allons maintenant lancer quelques commandes sur le serveur SQL:

mysql -u root -p

Lire la suite

Serveur dédié : résoudre le problème

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

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.

Serveur dédié : résoudre le problème

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 pid

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 autoremove

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% /home

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é.

Serveur dédié : résoudre le problème
Descripteurs de fichiers, table des fichiers et table des inodes sous Linux

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

Lire la suite

MySQL : convertir les tables MyISAM au format InnoDB photo

MySQL : convertir les tables MyISAM au format InnoDB

MySQL : MyISAM et InnoDB

A ses débuts, MySQL utilisait le moteur de stockage MyISAM.

C’est la raison pour laquelle on retrouve beaucoup d’exemples de création de tables sur Internet avec l’instruction engine=MyISAM (ce qui, au passage, peut faire planter pas mal de créations de bases/tables).

Aujourd’hui, le moteur de stockage par défaut de MySQL est InnoDB.

MyISAM n’est plus activement développé, à l’inverse d’InnoDB. Il est donc recommandé de convertir les tables MyISAM au format InnoDB, afin de bénéficier des dernières optimisations de performance du nouveau moteur.

innodb-myisam-mysql

Le moteur InnoDB

InnoDB est un moteur de stockage inclus d’origine dans toutes les distributions fournies par MySQL AB. Son principal avantage par rapport aux autres moteurs de stockage de MySQL est qu’il permet des transactions ACID (Atomiques, Cohérentes, Isolées et Durables), ainsi que la gestion des clés étrangères (avec vérification de la cohérence).

Toutes les bases de données sont stockées au même endroit. Par défaut dans le fichier ibdata1 qui, sous les systèmes de type unix, se trouve généralement dans /var/lib/mysql. Il est également possible d’utiliser plusieurs fichiers ou même d’utiliser directement une ou plusieurs partitions sur le disque en mode RAW.

Ce moteur de base de données utilise aussi deux fichiers de logs, d’habitude ib_logfile0 et ib_logfile1. Les fichiers de définitions de table .frm sont également dans un dossier au nom de la base comme pour MyISAM.

Depuis sa version 5.5, MySQL utilise InnoDB comme moteur par défaut.

Comment connaitre le format actuel de vos tables ?

Pour faire un petit état des lieux du format actuel des tables de votre base de données, il suffit de vous identifier sur le serveur SQL et de lancer cette requête :

SHOW TABLE STATUS FROM `database`;

Il vous suffit de remplacer database par le nom de votre base de données et de regarder la valeur de la colonne Engine.

Convertir les tables MyISAM au format InnoDB

Pour convertir des tables MyISAM au format InnoDB, il suffit de lancer une requête SQL va grandement nous simplifier la vie:

SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')
FROM information_schema.tables
WHERE 1=1
    AND engine = 'MyISAM'
    AND table_schema NOT IN ('information_schema', 'mysql', 'performance_schema');

Le résultat de cette requête est une liste bien formatée de requêtes à lancer pour que toutes nos tables soient converties au format InnoDB.

Voici le résultat de cette requête sur le serveur :

+-----------------------------------------------------------+
| CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')   |
+-----------------------------------------------------------+
| ALTER TABLE blog.blog_wc_comments_subscription ENGINE=InnoDB;
| ALTER TABLE blog.blog_wc_phrases ENGINE=InnoDB;
| ALTER TABLE blog.blog_wc_users_voted ENGINE=InnoDB;
+-----------------------------------------------------------+

Toutes les tables des bases de données qui sont au format MyISAM au format InnoDB sont listées, à l’exception des tables utilisées dans la gestion de MySQL (‘information_schema’, ‘mysql’, ‘performance_schema’) qui doivent rester en MyISAM.

Etape de Conversion

Il vous suffit ensuite de lancer cette liste de requêtes ALTER TABLE sous MySQL, Adminer ou PHPMyAdmin pour convertir vos tables. Lancez la liste de commandes que vous venez de trouver :

ALTER TABLE blog.blog_wc_comments_subscription ENGINE=InnoDB;
ALTER TABLE blog.blog_wc_phrases ENGINE=InnoDB;
ALTER TABLE blog.blog_wc_users_voted ENGINE=InnoDB;

Et voilà, vos tables MyISAM sont maintenant devenues des tables InnoDB.

Lire la suite

WordPress : récupérer la liste emails des membres et commentateurs photo

WordPress : nettoyage de la base de données

wordpress_icon_blue Avec le temps, les mises à jour successives et l’installation de différents plugins, la base de données de WordPress a tendance à prendre du poids, ce qui nuit aux performances. Voici donc comment lui faire bénéficier d’un petit régime.

N’oubliez pas de faire une sauvegarde de votre base de données avant de lancer ces requêtes. Backup now.

Nettoyage de wp_postmeta

Avant optimisation, ma table wp-postmeta faisait 12 403 enregistrements.

DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';
DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';

Maintenant : 12 240.

Nettoyage de wp_commentmeta

On supprime tout ce qu’Akismet nous a mis dans la table wp_commentmeta :

DELETE FROM wp_commentmeta WHERE meta_key LIKE '%akismet%';

et on supprime toutes les entrées qui n’ont aucune relation avec wp_comments :

DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

Nettoyage de wp_options

Passage de 880 enregistrements à 476. WordPress crée ces entrées automatiquement et les purge occasionnellement, autant l’aider un peu.

DELETE FROM wp_options WHERE option_name LIKE '_site_transient_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_site_transient_timeout_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';

Lire la suite

WordPress : récupérer la liste emails des membres et commentateurs photo

WordPress : retrouver le bouton “Publier”

Problème : plus de bouton “Publier” sous WordPress

wordpress_icon_blue Juste après la migration des bases MySQL, alors que je pensais que tout était bon, je vais sous WordPress pour raconter mes aventures et… plus de bouton “publier” mais un bouton “Soumettre à relecture” comme pour les guests ! Tout cela alors que je suis loggué comme admin, il y a un truc qui cloche.

Après avoir cherché un peu, il s’avère que j’ai copié directement les fichiers de bases de données mais que MySQL n’a pas les droits dessus. Du coup, toutes les tables sont en lecture seule, comme me l’a indiqué une petite requête simple :

Failed to save field : SQL alter table `wp_posts` modify `ID` bigint(20) unsigned not null default NULL auto_increment failed : Table 'wp_posts' is read only

Solution : attribuer les bases de données à mysql

Vous avez besoin de modifier les droits d’accès et d’écriture des fichiers de bases de données. Il faut soit se connecter à distance en SSH sur votre serveur ou en local sur votre machine et lancer la commande chown.

On se met donc dans le répertoire de travail de MySQL :

cd /var/lib/mysql/

et on attribue à l’utilisateur mysql les droits à nos bases de données :

chown -R mysql:mysql *

Lire la suite

MySQL: résoudre l'erreur

MySQL : résoudre l’erreur “Access denied for user debian-sys-maint@localhost”

Problème : l’erreur “Access denied for user debian-sys-maint@localhost” au lancement de MySQL

Lors de la migration de mes bases de données d’un serveur à l’autre, j’ai aussi déplacé la base mysql qui contient tous les utilisateurs, droits… pour ne pas avoir à tout refaire.

Le problème, c’est que chaque installation de MySQL crée un utilisateur de maintenance – debian-sys-maint sur notre serveur Debian – avec un mot de passe unique.

Solution : penser à copier /etc/mysql/debian.cnf

En copiant les bases de données, il faut également penser à copier le fichier /etc/mysql/debian.cnf dans lequel se trouve, entre autres, le mot de passe SQL de l’utilisateur spécial maintenance de Debian.

Lire la suite

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH photo 1

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH

Aujourd’hui, nous abordons la sauvegarde des fichiers essentiels du serveur.

Backup Manager permet d’effectuer des sauvegardes quotidiennes du système : il crée des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et peut les exporter vers un serveur FTP.

Dans notre cas, nous allons l’installer et le configurer pour envoyer tout ce qui est important sur notre serveur sur le serveur FTP externe de sauvegarde fourni gratuitement par OVH (100 Go).

Etape 1 : installation de Backup Manager

C’est classique :

apt-get install backup-manager

A la fin de l’installation, un assistant se lance et vous permet de configurer des options par défaut. Ou vous pouvez configurer à la main, comme indiqué dans l’étape suivante.

Lire la suite

MySQL : résoudre l'erreur

Serveur dédié : créer la base de données MySQL et importer WordPress

icon mysql

Dans ce tutoriel, nous allons voir comment créer la base de données MySQL et importer notre base WordPress existante.

Ce tutoriel prend environ 15 minutes à réaliser. Tout se fait dans le terminal via une session SSH.

Création d’une base de données

On se connecte au serveur MySQL :

mysql -p -h localhost 

Entrez votre mot de passe du compte root pour MySQL. Vous obtenez un prompt.

On crée une base de données UTF-8, avec une collation utf8_unicode_ci :

CREATE DATABASE skyminds_wp CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Je vous recommande très fortement d’utiliser l’UTF-8 dès le départ. Cela évite bien des soucis qui pourraient survenir ultérieurement avec les caractères accentués.

Lire la suite