Un cluster MySQL en lecture seule pour absorber les rapports lourds sans ralentir la production

Trois minutes : c’est le temps qu’une requête d’agrégation sur douze mois de commandes WooCommerce a fini par prendre sur le serveur de production, un vendredi en fin d’après-midi, verrouillant au passage plusieurs tables le temps de son exécution. Pendant ces trois minutes, les visiteurs du site ont subi des temps de réponse dégradés, sans lien apparent avec leur propre navigation.

Ce type de requête, typique d’un rapport de gestion consulté une fois par semaine par une direction commerciale, n’a pourtant rien d’anormal en soi : c’est sa cohabitation directe avec le trafic de production qui pose problème. Une réplique MySQL dédiée à la lecture, alimentée en continu par réplication, permet de dérouter ces requêtes lourdes sans jamais toucher au serveur qui sert les visiteurs.

Le principe : séparer la charge, pas la donnée

Une réplique de lecture ne stocke pas une donnée différente de celle du serveur principal : elle en reçoit une copie tenue à jour en quasi temps réel via le mécanisme de réplication natif de MySQL, basé sur le journal binaire du serveur principal. La donnée reste identique ; seule la destination des requêtes change selon leur nature.

Toutes les écritures, qu’il s’agisse d’une commande passée, d’un article publié ou d’un commentaire enregistré, continuent d’être adressées exclusivement au serveur principal. Seules les requêtes de lecture volumineuses, typiquement des rapports d’analyse ou des exports, sont redirigées vers la réplique, qui peut supporter une charge de lecture intensive sans jamais interférer avec les écritures de production.

Configuration de la réplication asynchrone entre les deux serveurs

La mise en place s’appuie sur la réplication native de MySQL, activée côté serveur principal par l’activation du journal binaire dans sa configuration :

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW

La réplique, configurée avec un identifiant de serveur distinct, se connecte ensuite au serveur principal pour recevoir en continu le flux de modifications :

CHANGE MASTER TO
  MASTER_HOST='10.0.0.10',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='mot_de_passe_dedie',
  MASTER_LOG_FILE='mysql-bin.000042',
  MASTER_LOG_POS=1547;
START SLAVE;

Un compte MySQL dédié, disposant uniquement du privilège REPLICATION SLAVE et d’aucun droit d’écriture applicatif, sécurise cette connexion sans exposer d’accès superflu entre les deux machines.

Router les requêtes de rapports vers la réplique côté WordPress

Côté application, un plugin de répartition lecture/écriture ou une extension d’abstraction de base de données permet de définir explicitement quelles requêtes partent vers la réplique. Un exemple de configuration, dans un fichier db-config.php compatible avec l’extension HyperDB maintenue par la fondation WordPress, illustre ce principe :

$wpdb->add_database( array(
    'host'     => '10.0.0.20',
    'user'     => 'lecture_rapports',
    'password' => 'mot_de_passe_lecture',
    'name'     => 'wordpress',
    'write'    => 0,
    'read'     => 1,
    'dataset'  => 'rapports',
) );

Seul le module interne qui génère les rapports d’analyse pointe explicitement vers ce jeu de connexions ; le reste de l’application continue à interroger le serveur principal comme auparavant, sans modification de son code existant.

Surveiller le décalage de réplication, jamais un acquis définitif

La réplication asynchrone introduit, par construction, un léger décalage entre l’écriture sur le serveur principal et sa disponibilité sur la réplique. Ce décalage, mesurable via la commande SHOW SLAVE STATUS et son champ Seconds_Behind_Master, reste généralement inférieur à la seconde en fonctionnement normal, mais peut s’allonger fortement lors d’un pic d’écritures massif sur le serveur principal.

SHOW SLAVE STATUS\G

Un rapport de gestion consulté immédiatement après une importation massive de commandes peut donc, dans de rares cas, afficher des chiffres légèrement en retard par rapport à l’état réel du serveur principal, un compromis assumé face au gain obtenu sur la stabilité de la production.

Ce que cette architecture ne résout pas

Une réplique de lecture ne constitue pas, à elle seule, une solution de haute disponibilité en écriture : en cas de panne du serveur principal, aucune bascule automatique des écritures ne se produit vers la réplique sans un mécanisme de promotion et de basculement distinct, qui répond à un besoin différent de continuité de service plutôt que d’isolation de charge.

Isoler la charge de lecture n’est pas un luxe réservé aux gros volumes : c’est souvent le correctif le plus simple face à une requête de rapport devenue trop gourmande pour cohabiter avec la production.

En résumé

Une réplique MySQL dédiée à la lecture absorbe les rapports lourds sans jamais ralentir les écritures de production, moyennant un décalage de réplication généralement limité à la seconde et une surveillance continue de ce décalage. Ce dispositif traite une charge de lecture excessive ; il ne remplace pas une architecture de haute disponibilité en écriture, qui répond à un besoin distinct.