Contexte

Lors de la migration d'une application basée sur MySQL vers TiDB, l'évaluation des performances de synchronisation est un point crucial. Le composant Data Migration (DM) est central dans ce processsu, mais il n'expose pas nativement la latence bout à bout. Cet article présente plusieurs méthodes pratiques pour calculer cette latence avec précision, généralement nécessaire lors des phases de transition où TiDB agit comme réplique de MySQL.

L'approche consiste à mesurer l'écart temporel entre deux événements clés : une opération sur la source MySQL et sa réplication complète sur la cible TiDB. Trois tcehniques sont explorées : l'analyse des positions dans les binlogs MySQL, l'examen des journaux généraux de TiDB, et l'ajout d'un horodatage automatique côté cible.

Méthode basée sur les positions Binlog

Cette méthode repose sur le suivi du fichier binlog de MySQL. Une table de test est utilisée pour l'illustration :

CREATE TABLE `evenements` (
  `identifiant` int(11) NOT NULL,
  `heure_creation_mysql` timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  PRIMARY KEY (`identifiant`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Après insertion d'une ligne dans MySQL, la position correspondante dans le fichier binlog est identifiée. L'analyse du contenu binaire autour de cette position révèle l'horodatage exact du début de la transaction, par exemple 21:45:38.572.

En parallèle, les journaux du processus dm-worker sont consultés pour cette même position binlog. L'entrée de type « flushed checkpoint » indique le moment où le traitement de cette position est terminé, par exemple 21:45:38.603. La différence donne une estimation de la latence, ici 31 ms. Il est important de noter que cette mesure couvre le cycle complet, incluant la notification de fin au dm-worker après l'écriture dans TiDB.

Méthode basée sur les journaux généraux de TiDB

Pour mesurer précisément le moment où la transaction est engagée côté TiDB, le journal général (GENERAL_LOG) est activé :

SET tidb_general_log = 1;

La même transaction source est localisée dans le binlog MySQL (horodatage de début). Les journaux TiDB sont ensuite filtrés pour trouver l'entrée correspondante, identifiée par son numéro de transaction (TSO). L'horodatage de commit dans TiDB, par exemple 22:08:55.434, est comparé à celui du binlog source (22:08:55.419) pour obtenir une latence de 15 ms. Cette méthode fournit une mesure plus directe du délai d'insertion dans la base cible.

Méthode par ajout d'un horodatage automatique

Cette technique exploite la capacité de DM à gérer des schémas hétérogènes entre source et cible. L'idée est de créer un champ supplémentaire dans la table TiDB qui sera automatiquement rempli avec l'heure courante lors de la synchronisation, sans affecter la table source.

Sur le nœud TiDB, un nouveau champ est ajouté à la table existante :

ALTER TABLE evenements ADD COLUMN heure_creation_tidb timestamp(3) NOT NULL DEFAULT current_timestamp(3);

Lorsqu'une nouvelle insertion est effectuée dans MySQL, le champ heure_creation_mysql prend la valeur courante côté source. Dans TiDB, le champ heure_creation_tidb se remplit automatiquement au moment de l'insertion répliquée. Une simple requête de lecture sur la table TiDB permet de comparer directement les deux valeurs et de calculer la latence en une seule étape. Cette méthode est particulièrement pratique pour un suivi continu sans manipulation de journaux.

Chaque approche offre une perspective différente : la première se concentre sur le traitement des binlogs par DM, la seconde sur l'exécution dans TiDB, et la troisième fournit une donnée intégrée aux données métier pour une monitoring simplifié.