Il y a 10 jours, un article de Naomi Cannon (en français : Naomi Canon) publié sur Reddit, renvoyant vers l’article complet sur Medium, a attiré mon attention.

Enfin de bonnes nouvelles !

Ce qui s’est passé jusqu’à présent

Après avoir racheté Codership OY en mai 2025, et par là même Galera Cluster pour MySQL [ 1 ], puis annoncé la fin du support de Galera Cluster pour MySQL 8.4 à la fin du mois de septembre 2026 [ 2 ], avant d’annoncer qu’elle ne souhaitait plus prendre en charge Galera Cluster (pour MariaDB !) dans l’édition communautaire [ 3 ], un tollé s’est élevé au sein de la communauté. MariaDB Corp. a alors fait demi-tour («We’ve thoroughly considered your feedback and decided that now is not the time for a major change,»). Un engagement clair en faveur de la poursuite du support de Galera Cluster dans l’édition communautaire sonnerait autrement.

Dans le cadre de nos travaux sur le thème « PostgreSQL pour les dauphins et les otaries », j’aime bien suivre les discussions sur les listes de diffusion PostgreSQL pour voir quels problèmes se posent et comment ils sont résolus.

Chez notre dernier client, nous avons vraiment dû résoudre quelques questions passionnantes ! Notamment parce que la base de données n’était pas vraiment petite.

Description du problème

MySQL a introduit le InnoDB buffer pool configurable dynamiquement dans la version 5.7.5 en septembre 2014 (ici et ici) :

Lors de ma dernière intervention chez le client, celui-ci est venu me voir, rayonnant de joie, pour me dire qu’il avait suivi mon conseil et changé toutes les colonnes de clé primaire de BIGINT (8 octets) à INT (4 octets), et que cela avait beaucoup apporté ! Sa base de données MySQL 8.4 avait désormais perdu 750 Go (sur 5,5 To). Super!

Lorsque nous travaillons avec PostgreSQL sous notre myEnv, nous obtenons régulièrement des erreurs de segment de mémoire partagée. Exemple:

Récemment, j’ai voulu représenter sur une carte les lieux de résidence des membres de mon association (membres IGOC) pour un petit projet personnel. Je connaissais les adresses des membres de l’association, mais pas les coordonnées de leurs lieux de résidence.

Introduction

Deux points pour commencer:

1. Un deadlock est un état dans lequel deux transactions différentes ne sont plus en mesure de continuer à travailler, car chaque transaction détient un verrou dont l’autre transaction aurait besoin. Comme les deux transactions attendent que l’autre libère son verrou, aucune des deux transactions ne libérera son verrou. Et cela durerait jusqu’à la saint-glinglin. Pour éviter cela, l’instance MariaDB intervient et tue rapidement la transaction qui a fait le moins de travail. L’application reçoit alors un message d’erreur de type “deadlock”:

   ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
   

2. Dans l’écosystème MariaDB, il est généralement admis qu’un SELECT ne provoque pas de verrouillage (exception : FOR UPDATE ou LOCK IN SHARE MODE) et ne peut donc pas faire partie d’un deadlock.

Sur cette page, vous trouverez les différents blogs des collaborateurs de FromDual ainsi que quelques agrégats de blogs utiles.