{"id":18769,"date":"2026-04-06T11:49:56","date_gmt":"2026-04-06T09:49:56","guid":{"rendered":"https:\/\/webhosting.de\/mysql-replication-lag-hosting-optimierung-serverlag\/"},"modified":"2026-04-06T11:49:56","modified_gmt":"2026-04-06T09:49:56","slug":"mysql-replication-lag-hebergement-optimisation-du-decalage-du-serveur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/mysql-replication-lag-hosting-optimierung-serverlag\/","title":{"rendered":"Minimiser le d\u00e9calage de r\u00e9plication MySQL en mode d'h\u00e9bergement"},"content":{"rendered":"<p>MySQL Replication Lag co\u00fbte en disponibilit\u00e9 dans l'h\u00e9bergement, car les n\u0153uds de lecture fournissent des donn\u00e9es obsol\u00e8tes et un <strong>base de donn\u00e9es<\/strong> sync delay retarde les d\u00e9cisions. Je te montre comment identifier les causes, rendre le d\u00e9calage mesurable et, gr\u00e2ce \u00e0 des modifications cibl\u00e9es des r\u00e9glages et de l'architecture <strong>minimise<\/strong>.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Avant d'aller plus loin, je vais r\u00e9sumer l'essentiel afin que tu puisses mieux cerner l'impact de tes prochaines actions. Le retard de r\u00e9plication est le r\u00e9sultat d'une interaction entre le r\u00e9seau, les E\/S, les plans de requ\u00eate et la configuration. Le diagnostic n'est possible que si tu gardes un \u0153il sur les m\u00e9triques du serveur ainsi que sur les chemins du binlog et du log relais. Les contre-mesures sont plus efficaces si tu les mets en \u0153uvre par petites \u00e9tapes mesurables et si tu surveilles en permanence l'impact sur la latence. Les questions d'architecture telles que la r\u00e9partition des lectures et la planification des capacit\u00e9s d\u00e9terminent si les optimisations suffisent ou si une mise \u00e0 l'\u00e9chelle est n\u00e9cessaire. C'est pourquoi j'associe la technique, le monitoring et les processus d'exploitation en un tout. <strong>clair<\/strong> Plan d'action fiable dans les environnements d'h\u00e9bergement <strong>porte<\/strong>.<\/p>\n<ul>\n  <li><strong>Causes<\/strong> comprendre : R\u00e9seau, grandes transactions, cl\u00e9s primaires manquantes<\/li>\n  <li><strong>Diagnostic<\/strong> aiguiser les comp\u00e9tences : Seconds_Behind_Master, IO-\/SQL-Thread, Slow Query Log<\/li>\n  <li><strong>Optimiser<\/strong> au lieu d'attendre : r\u00e9plication parall\u00e8le, cl\u00e9s, petits lots<\/li>\n  <li><strong>mise \u00e0 l'\u00e9chelle<\/strong> si n\u00e9cessaire : plus de CPU\/RAM, routage des lecteurs, r\u00e9plicas suppl\u00e9mentaires<\/li>\n  <li><strong>Surveiller<\/strong> et agir en cons\u00e9quence : Alertes, fen\u00eatres de maintenance, analyses r\u00e9guli\u00e8res<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/serverraum-optimierung-4892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Qu'est-ce qui provoque des retards de r\u00e9plication dans l'h\u00e9bergement ?<\/h2>\n\n<p>Je commence par les ralentisseurs typiques, car la plupart des retards peuvent \u00eatre consid\u00e9rablement r\u00e9duits en \u00e9liminant un petit nombre de causes. <strong>abaisser<\/strong> ne sont pas pris en compte. Une latence \u00e9lev\u00e9e du r\u00e9seau ralentit le thread IO, qui r\u00e9cup\u00e8re les \u00e9v\u00e9nements binlog du serveur primaire, et provoque des sauts dans le temps. <strong>R\u00e9sidus<\/strong>. Les plus grands retards surviennent toutefois dans le thread SQL lorsqu'il doit appliquer des modifications ligne par ligne sans cl\u00e9 primaire ou unique correspondante. En l'absence de ces cl\u00e9s, les mises \u00e0 jour et les suppressions forcent des analyses de table co\u00fbteuses, ce qui bloque les logs de relais. Les longues transactions avec de nombreuses lignes bloquent l'application d'autres \u00e9v\u00e9nements jusqu'\u00e0 ce que le commit soit termin\u00e9. Les op\u00e9rations DDL telles que ALTER TABLE arr\u00eatent en outre d'autres processus de r\u00e9plication afin de maintenir la coh\u00e9rence et g\u00e9n\u00e8rent des pics dans le lag.<\/p>\n\n<p>Le mat\u00e9riel et la configuration jouent \u00e9galement un r\u00f4le, c'est pourquoi je v\u00e9rifie toujours le CPU, la m\u00e9moire et le sous-syst\u00e8me d'E\/S en premier. Des SSD lents ou utilis\u00e9s \u00e0 pleine capacit\u00e9, un pool de tampons InnoDB trop petit et une synchronisation agressive (p. ex. sync_binlog=1 sur le serveur primaire) augmentent sensiblement les co\u00fbts I\/O. <strong>\u00e9lev\u00e9<\/strong>. Les r\u00e9pliques sous-dimensionn\u00e9es se retrouvent <strong>h\u00e9bergement<\/strong> scaling lorsqu'il y a plus de demandes de lecture ou des pics d'\u00e9criture parall\u00e8les. Les charges de travail avec de nombreuses \u00e9critures al\u00e9atoires affectent davantage le pool de tampons et g\u00e9n\u00e8rent plus de travail au niveau des points de contr\u00f4le. Ajoutez \u00e0 cela des requ\u00eates concurrentes sur le r\u00e9plicat et le thread SQL perd encore en vitesse.<\/p>\n\n<h2>Diagnostiquer le lag : M\u00e9triques, logs et signaux<\/h2>\n\n<p>Pour le diagnostic, je ne me fie pas \u00e0 un seul signal, car Seconds_Behind_Master est parfois trompeur ou retard\u00e9. <strong>affiche<\/strong>. Je commence par SHOW SLAVE STATUS et je regarde Seconds_Behind_Master, Relay_Log_Space, Master_Log_File versus Read_Master_Log_Pos ainsi que les drapeaux Slave_IO_Running et Slave_SQL_Running afin de clarifier les threads IO et SQL. <strong>s\u00e9parent<\/strong>. De grandes diff\u00e9rences entre le fichier Master_Log_File et le fichier Relay_Log indiquent des freins au niveau du r\u00e9seau ou de la persistance. Si le thread SQL boite, le Slow Query Log sur le r\u00e9plicat fournit des indications sur les requ\u00eates qui bloquent l'application. En outre, je v\u00e9rifie les m\u00e9triques InnoDB telles que row_lock_waits, history list length et le taux d'occupation du buffer pool afin de mettre en \u00e9vidence la pression de la m\u00e9moire et du verrouillage.<\/p>\n\n<p>Au niveau op\u00e9rationnel, les s\u00e9ries temporelles comptent : Je corr\u00e8le le lag de r\u00e9plication, le CPU, les IOPS, la latence du r\u00e9seau et le nombre de DDL en cours. Si tu vois des pics de lag en parall\u00e8le avec des sauvegardes, des jobs batch ou des importations importantes, tu identifies clairement le coupable. <strong>plus rapide<\/strong>. Des outils comme Percona Toolkit ou les m\u00e9triques de plateforme des clouds populaires facilitent l'observation des balises IO\/SQL et des bourrages de logs de relais. Je v\u00e9rifie \u00e9galement si les applications ex\u00e9cutent de longues requ\u00eates de lecture sur le r\u00e9plicat, ce qui rend le thread SQL malheureux. <strong>bloquer<\/strong>. Ce n'est que lorsque la direction est claire - IO ou SQL - qu'il vaut la peine de se lancer dans des mesures cibl\u00e9es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mysql_repl_verz_opt_8492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mesures imm\u00e9diates contre le MySQL Replication Lag<\/h2>\n\n<p>Lorsque les secondes s'acc\u00e9l\u00e8rent, j'agis par petites \u00e9tapes efficaces afin de contr\u00f4ler le retard. <strong>tombe<\/strong>. Je mets en pause les longues requ\u00eates sur le r\u00e9plicat, je d\u00e9finis des fen\u00eatres de maintenance pour les DDL et j'arr\u00eate les grosses mises \u00e0 jour par lots jusqu'\u00e0 ce que le lag ait rattrap\u00e9 son retard. Je divise les op\u00e9rations en vrac en paquets plus petits, par exemple 1 000 \u00e0 5 000 lignes par commit, afin que le thread SQL soit toujours en mouvement. <strong>passe par<\/strong>. En l'absence de cl\u00e9s primaires, je donne la priorit\u00e9 aux tables ayant le plus d'\u00e9critures et je cr\u00e9e des cl\u00e9s ; cela r\u00e9duit imm\u00e9diatement l'effort par op\u00e9ration de ligne. En cas de goulots d'\u00e9tranglement IO, j'augmente le pool de tampons InnoDB, je nettoie les fichiers journaux et je m'assure que les SSD ont suffisamment de blocs libres pour fournir des taux d'\u00e9criture constants.<\/p>\n\n<p>En cas de frein r\u00e9seau \u00e9vident, je rapproche les n\u0153uds les uns des autres ou j'optimise la connexion avec une latence plus faible. La compression du trafic de r\u00e9plication via slave_compressed_protocol r\u00e9duit la bande passante et aide en cas de lignes limit\u00e9es. <strong>sensible<\/strong>. Si la journalisation binaire est ex\u00e9cut\u00e9e sur des r\u00e9plicas sans n\u00e9cessit\u00e9, je la d\u00e9sactive temporairement afin de r\u00e9duire le travail d'\u00e9criture (exigences PITR auparavant). <strong>v\u00e9rifier<\/strong>). Dans les phases critiques, je fais passer le trafic de lecture de mani\u00e8re cibl\u00e9e sur des r\u00e9plicas moins sollicit\u00e9s ou je le route temporairement sur le serveur primaire, dans la mesure o\u00f9 la logique commerciale le permet. L'objectif reste toujours de faire travailler le thread SQL en continu et de r\u00e9duire rapidement les goulots d'\u00e9tranglement.<\/p>\n\n<h2>Comparaison des principaux param\u00e8tres MySQL<\/h2>\n\n<p>Pour les configurations r\u00e9currentes, j'ai un petit playbook de param\u00e8tres que j'adapte \u00e0 la charge de travail et au mat\u00e9riel. <strong>rapprocher<\/strong>. Les valeurs suivantes servent de point de d\u00e9part, et non d'objectif fixe ; je mesure l'impact sur le lag et le d\u00e9bit apr\u00e8s chaque modification. Notez les diff\u00e9rences entre le serveur principal et la r\u00e9plique, car la s\u00e9curit\u00e9 et la r\u00e9cup\u00e9ration en cas de crash sont diff\u00e9rentes. <strong>Priorit\u00e9s<\/strong> peuvent mettre en place. C'est justement dans le cas de la strat\u00e9gie Binlog-Sync et InnoDB-Flush que les objectifs diff\u00e8rent. En outre, le choix du regroupement des commits doit \u00eatre adapt\u00e9 \u00e0 la coh\u00e9rence de l'application.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Objectif<\/th>\n      <th>Valeur typique Primaire<\/th>\n      <th>Valeur typique R\u00e9plique<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>innodb_buffer_pool_size<\/strong><\/td>\n      <td>Conserve les donn\u00e9es \u00e0 chaud dans la RAM<\/td>\n      <td>60-75% RAM<\/td>\n      <td>60-80% RAM<\/td>\n      <td>Plus grand pour les r\u00e9pliques \u00e0 forte teneur en lecture<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>sync_binlog<\/strong><\/td>\n      <td>Binlog-Durabilit\u00e9<\/td>\n      <td>1-100<\/td>\n      <td>D\u00e9sactiv\u00e9 (si pas de binlog) ou 100<\/td>\n      <td>1 = s\u00e9curit\u00e9 maximale, plus lent<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>innodb_flush_log_at_trx_commit<\/strong><\/td>\n      <td>Redo-Log-Flushing<\/td>\n      <td>1<\/td>\n      <td>2<\/td>\n      <td>2 acc\u00e9l\u00e8re nettement la r\u00e9plique<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>replica_parallel_workers<\/strong><\/td>\n      <td>Application parall\u00e8le<\/td>\n      <td>-<\/td>\n      <td>= nombre de vCPU<\/td>\n      <td>Tester si la charge de travail peut \u00eatre parall\u00e9lis\u00e9e<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>binlog_group_commit_sync_delay<\/strong><\/td>\n      <td>Commit-Batching<\/td>\n      <td>0-5000 \u00b5s<\/td>\n      <td>0<\/td>\n      <td>Uniquement utile avec latence\/batch<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>slave_compressed_protocol<\/strong><\/td>\n      <td>R\u00e9duire la charge du r\u00e9seau<\/td>\n      <td>-<\/td>\n      <td>ON<\/td>\n      <td>Aide en cas de bande passante limit\u00e9e<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Apr\u00e8s avoir d\u00e9fini ces param\u00e8tres, je regarde imm\u00e9diatement les valeurs en secondes, le taux de commit et les IOPS afin de d\u00e9terminer la direction \u00e0 prendre. <strong>valider<\/strong>. Si la performance de lecture augmente sans nouveau d\u00e9calage, la modification est maintenue. Si les adaptations entra\u00eenent des commits ou des timeouts plus longs, je fais un pas en arri\u00e8re et j'am\u00e9liore la qualit\u00e9. <strong>ajuste<\/strong> les valeurs de d\u00e9lai ou de flush. La configuration ne reste pas un acte unique, mais un processus it\u00e9ratif avec t\u00e9l\u00e9m\u00e9trie. Cette discipline s'av\u00e8re durablement payante lorsque les volumes de donn\u00e9es augmentent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mysql-replication-lag-hosting-4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Format binlog, taille des \u00e9v\u00e9nements et ordre des commits<\/h2>\n\n<p>Un levier important contre le lag r\u00e9side dans le format binlog. J'\u00e9value volontairement ROW, STATEMENT et MIXED : ROW est d\u00e9terministe et r\u00e9plique de mani\u00e8re fiable, mais g\u00e9n\u00e8re plus d'\u00e9v\u00e9nements. Pour r\u00e9duire le volume, je r\u00e8gle binlog_row_image sur MINIMAL, de sorte que seules les colonnes modifi\u00e9es se retrouvent dans l'\u00e9v\u00e9nement. Si l'application modifie souvent de grandes colonnes de texte\/blob, je v\u00e9rifie si chaque colonne doit vraiment \u00eatre \u00e9crite. De plus, binlog_transaction_compression aide \u00e0 d\u00e9charger le r\u00e9seau et les E\/S dans les configurations 8.0 - le prix du CPU doit \u00eatre \u00e9valu\u00e9 dans des tests de charge.<\/p>\n\n<p>Pour le rapport d\u00e9bit\/consistance, j'utilise les param\u00e8tres de commit avec pr\u00e9caution. Avec binlog_order_commits, je maintiens l'ordre de commit stable ; sur les r\u00e9plicas, je n'active replica_preserve_commit_order que si l'application en a besoin - l'option r\u00e9duit le parall\u00e9lisme et peut augmenter le lag. Pour maximiser l'application parall\u00e8le, j'active transaction_dependency_tracking=WRITESET et une transaction_write_set_extraction appropri\u00e9e (p.ex. XXHASH64). En combinaison avec replica_parallel_type=LOGICAL_CLOCK, cela augmente les chances que des transactions ind\u00e9pendantes soient appliqu\u00e9es simultan\u00e9ment.<\/p>\n\n<h2>Utiliser correctement la r\u00e9plication parall\u00e8le et les GTIDs<\/h2>\n\n<p>La r\u00e9plication parall\u00e8le est l'un de mes leviers les plus efficaces lorsque la charge de travail comporte suffisamment de transactions ind\u00e9pendantes. <strong>offre<\/strong>. Je d\u00e9finis replica_parallel_workers sur le nombre de vCPUs du r\u00e9plica et je v\u00e9rifie si la distribution des \u00e9v\u00e9nements peut vraiment \u00eatre trait\u00e9e en parall\u00e8le. Sur les sch\u00e9mas avec mise \u00e0 jour \u00e0 chaud d'une seule table, l'effet s'\u00e9vanouit, sur de nombreuses tables ou sch\u00e9mas ind\u00e9pendants, il agit visiblement <strong>par<\/strong>. Les GTID me facilitent le basculement et r\u00e9duisent le risque de divergence, surtout lorsque plusieurs r\u00e9plicas sont en jeu. Pour les questions d'architecture autour du master\/replica et du multi-source, j'utilise volontiers les guides d'approfondissement de <a href=\"https:\/\/webhosting.de\/fr\/replication-de-base-de-donnees-hebergement-master-slave-multi-master-syncio\/\">R\u00e9plication ma\u00eetre-esclave<\/a>, pour comparer proprement les options.<\/p>\n\n<p>Avec la r\u00e9plication semi-synchrone, je r\u00e9duis la fen\u00eatre de perte de donn\u00e9es, mais j'accepte plus de latence sur le serveur primaire. Je ne l'active que si les objectifs commerciaux exigent clairement cette s\u00e9curit\u00e9. <strong>demandent<\/strong>. Il est important d'observer le backpressure : Si les r\u00e9pliques ne suivent pas, les temps de validation augmentent, ce qui accro\u00eet la latence des applications. C'est pourquoi je teste dans des environnements de staging et ne prends le relais qu'apr\u00e8s un effet positif mesurable. Ainsi, le chemin des donn\u00e9es et l'exp\u00e9rience utilisateur restent \u00e9quilibr\u00e9s, sans cr\u00e9er de nouveaux goulets d'\u00e9tranglement.<\/p>\n\n<h2>Mise en page des tableaux, cl\u00e9s et optimisation des requ\u00eates<\/h2>\n\n<p>Sans cl\u00e9s primaires ou uniques, toute modification se paie au prix fort, c'est pourquoi je commence par des cl\u00e9s propres. <strong>Cl\u00e9s<\/strong>. Pour chaque table fortement modifi\u00e9e, je choisis une cl\u00e9 primaire pertinente et je place les index secondaires n\u00e9cessaires sur les colonnes fr\u00e9quemment filtr\u00e9es. Ainsi, le thread SQL r\u00e9duit les analyses planifiables et l'application d'\u00e9v\u00e9nements binlog est acc\u00e9l\u00e9r\u00e9e. <strong>sensible<\/strong>. Je divise les grandes mises \u00e0 jour en petites \u00e9tapes atomiques que je contr\u00f4le avec LIMIT et ORDER BY PK. J'encapsule les longs SELECT sur les r\u00e9plicas afin qu'ils ne retardent pas constamment le thread SQL.<\/p>\n\n<p>Je v\u00e9rifie r\u00e9guli\u00e8rement le journal des requ\u00eates lentes de la r\u00e9plique, car une charge r\u00e9elle y est visible, qui passe inaper\u00e7ue sur le serveur primaire. Les requ\u00eates avec File-Sort, Using Temporary ou sans index trouvent rapidement le chemin vers des optimisations. En parall\u00e8le, je contr\u00f4le les statistiques InnoDB et m'assure que le Buffer Pool Hit Ratio reste sup\u00e9rieur \u00e0 95%. En dessous de 90%, il risque d'y avoir plus d'E\/S, ce qui rendrait chaque \u00e9tape de r\u00e9plication plus difficile. <strong>rench\u00e9rit<\/strong>. Ainsi, un simple r\u00e9glage des requ\u00eates permet d\u00e9j\u00e0 d'obtenir des effets significatifs sur le lag.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mysql_replication_lag_8123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strat\u00e9gies DDL sans choc de r\u00e9plication<\/h2>\n\n<p>Le DDL peut ralentir la r\u00e9plication de mani\u00e8re importante, c'est pourquoi je planifie les modifications de mani\u00e8re \u00e0 ce qu'elles forment de petites \u00e9tapes compr\u00e9hensibles. Lorsque c'est possible, j'utilise ALGORITHM=INPLACE ou INSTANT pour que les tables restent lisibles pendant la modification et que le thread SQL ne reste pas bloqu\u00e9 longtemps. Si je dois modifier de grandes tables, je mise sur des approches en ligne et je throttle le taux afin de ne pas accumuler les logs de relais. Les DDL qui n\u00e9cessitent de longs verrous exclusifs ou qui r\u00e9\u00e9crivent enti\u00e8rement des colonnes sont particuli\u00e8rement critiques - elles migrent chez moi dans des fen\u00eatres hors pointe strictement surveill\u00e9es avec un monitoring \u00e9troit.<\/p>\n\n<h2>Optimiser le chemin d'acc\u00e8s au r\u00e9seau et au stockage<\/h2>\n\n<p>Les liaisons r\u00e9seau avec un RTT \u00e9lev\u00e9 g\u00e9n\u00e8rent des temps morts entre les threads IO et SQL, c'est pourquoi je minimise la distance et le nombre de sauts entre les n\u0153uds. <strong>cons\u00e9quent<\/strong>. Les liens d\u00e9di\u00e9s ou les chemins de peering de haute qualit\u00e9 aident, surtout lorsque plusieurs r\u00e9plicas tirent en m\u00eame temps. Sur le chemin de stockage, je mise sur des SSD avec des performances d'\u00e9criture stables et j'active les caches Write-Back si le contr\u00f4leur prot\u00e8ge la batterie. <strong>offre<\/strong>. Je v\u00e9rifie r\u00e9guli\u00e8rement si TRIM est actif et s'il y a suffisamment de blocs de r\u00e9serve libres pour \u00e9viter les baisses soudaines. Des options de syst\u00e8me de fichiers et de montage comme noatime et des planificateurs d'E\/S adapt\u00e9s compl\u00e8tent la cha\u00eene de r\u00e9glage.<\/p>\n\n<p>Je ne charge pas les sauvegardes sur le m\u00eame disque que celui qui contient les journaux de relais, car les mod\u00e8les d'E\/S concurrents augmentent la latence. <strong>pousser vers le haut<\/strong>. Si possible, je d\u00e9place les sauvegardes sur une r\u00e9plique personnelle ou j'utilise des snapshots en dehors du chemin chaud. C\u00f4t\u00e9 r\u00e9seau, il vaut la peine de jeter un coup d'\u0153il sur les tailles MTU et les fonctions de d\u00e9chargement des cartes r\u00e9seau, qui influencent la latence selon le pilote. Finalement, je v\u00e9rifie l'effet avec des benchmarks r\u00e9p\u00e9tables et des mesures de production r\u00e9elles. C'est la seule fa\u00e7on de s\u00e9parer les gains per\u00e7us des gains mesurables dans le chemin de r\u00e9plication. <strong>clair<\/strong>.<\/p>\n\n<h2>Isolation des ressources et contr\u00f4le Noisy-Neighbor<\/h2>\n\n<p>Dans l'h\u00e9bergement, plusieurs charges de travail sont souvent en concurrence pour les m\u00eames ressources. Je fixe des limites claires : Au niveau du syst\u00e8me d'exploitation, j'encapsule les processus de sauvegarde et de traitement par lots avec des cgroups, des nice\/ionice et des quotas d'E\/S afin que le thread SQL de la r\u00e9plique conserve la priorit\u00e9. Dans MySQL 8, j'utilise des groupes de ressources pour lier les lecteurs co\u00fbteux \u00e0 certains noyaux de l'unit\u00e9 centrale et pour placer les workers de r\u00e9plication sur des noyaux \u00e0 r\u00e9action rapide. En outre, je limite les longues requ\u00eates analytiques par des d\u00e9lais d'attente et je planifie d\u00e9lib\u00e9r\u00e9ment leur ex\u00e9cution afin qu'elles ne ralentissent pas le chemin d'acc\u00e8s Apply.<\/p>\n\n<h2>Strat\u00e9gies de mise \u00e0 l'\u00e9chelle en mati\u00e8re d'h\u00e9bergement<\/h2>\n\n<p>Il arrive un moment o\u00f9 les optimisations ne suffisent plus, alors je planifie \u00e0 nouveau la capacit\u00e9 et la topologie et je fixe des objectifs clairs. <strong>Rouleaux<\/strong>. Plus de CPU et de RAM sur les r\u00e9plicas augmentent la vitesse du thread SQL et donnent plus d'espace au buffer pool. J'achemine activement les demandes de lecture sur les r\u00e9plicas et laisse la charge d'\u00e9criture sur le serveur principal, afin que les r\u00f4les soient propres. <strong>saisissent<\/strong>. Les r\u00e9pliques suppl\u00e9mentaires r\u00e9partissent les pics de charge de lecture, mais ne r\u00e9duisent pas automatiquement le d\u00e9calage si les m\u00eames goulets d'\u00e9tranglement existent. Si le mod\u00e8le de donn\u00e9es a besoin d'une vraie division, je pr\u00e9f\u00e8re <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-partitionnement-replication-hebergement-web-infrastructure-evolutive\/\">Sharding et r\u00e9plication<\/a> car les chemins d'\u00e9criture s\u00e9par\u00e9s s\u00e9parent proprement la charge.<\/p>\n\n<p>Lorsque le nombre d'utilisateurs augmente, l'optimum se d\u00e9place souvent : j'augmente les workers parall\u00e8les, j'agrandis les buffer, je d\u00e9structure les batches et je d\u00e9place les long runners dans des fen\u00eatres de temps off-peak. Il est important de ne pas adopter aveugl\u00e9ment les r\u00e8gles de dimensionnement courantes, mais de les adapter en fonction de ses propres courbes de latence et de d\u00e9bit. <strong>valider<\/strong>. Un petit runbook de performance avec des valeurs seuils acc\u00e9l\u00e8re les d\u00e9cisions dans l'entreprise. Il en r\u00e9sulte un chemin reproductible de la mesure \u00e0 l'adaptation. Ainsi, tu conserves le MySQL Replication Lag m\u00eame en cas de croissance dans le domaine de l'informatique. <strong>Poign\u00e9e<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/MYSQL_Replikation_Optimierung_7892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Replicabuilds, catch-up et topologies<\/h2>\n\n<p>Un r\u00e9plicabuild propre d\u00e9termine si tu peux rapidement revenir dans le vert apr\u00e8s des pannes. J'ensemence les nouvelles r\u00e9pliques avec un snapshot coh\u00e9rent et j'active les workers parall\u00e8les d\u00e8s le catch-up. Pendant la phase de rattrapage, j'\u00e9trangle les lecteurs concurrents sur le r\u00e9plicat afin que les SQL workers progressent de mani\u00e8re constante. Dans les grands environnements, j'opte pour un fan-out plut\u00f4t que pour des cha\u00eenes : plusieurs r\u00e9plicats sont directement rattach\u00e9s au serveur primaire ou \u00e0 un petit nombre de niveaux interm\u00e9diaires puissants. Les longues cha\u00eenes de r\u00e9plication ajoutent de la latence et augmentent le risque que certains maillons soient \u00e0 la tra\u00eene.<\/p>\n\n<p>Lors du red\u00e9marrage apr\u00e8s une maintenance ou un crash, j'utilise des options anti-crash : master_info_repository=TABLE et relay_log_info_repository=TABLE s\u00e9curisent les m\u00e9tadonn\u00e9es de mani\u00e8re robuste ; relay_log_recovery veille \u00e0 ce que seuls les logs de relais valides soient trait\u00e9s. relay_log_purge reste actif afin que Relay_Log_Space reste dans les limites - sur des disques pleins, le lag se cr\u00e9e plus rapidement que n'importe quelle optimisation ne peut le r\u00e9duire.<\/p>\n\n<h2>Mod\u00e8les de coh\u00e9rence et routage des lecteurs dans les applications<\/h2>\n\n<p>Le r\u00e9glage technique ne suffit pas \u00e0 lui seul - je s\u00e9curise la coh\u00e9rence per\u00e7ue par le biais de mod\u00e8les d'application. Pour les garanties de lecture apr\u00e8s \u00e9criture, je route les sessions apr\u00e8s une \u00e9criture sur le serveur primaire pendant une dur\u00e9e d\u00e9finie ou j'utilise la staleness limit\u00e9e : le routeur ne lit que les r\u00e9pliques dont le lag est inf\u00e9rieur \u00e0 une valeur seuil. Pour les processus de lecture particuli\u00e8rement sensibles, j'utilise WAIT_FOR_EXECUTED_GTID_SET sur le r\u00e9plicat pour m'assurer qu'un certain ensemble de transactions a d\u00e9j\u00e0 \u00e9t\u00e9 appliqu\u00e9. Cela augmente de mani\u00e8re contr\u00f4l\u00e9e les latences individuelles, mais maintient le chemin des donn\u00e9es et les attentes de l'utilisateur en harmonie.<\/p>\n\n<h2>Gestion des erreurs et stabilit\u00e9 de la r\u00e9plication<\/h2>\n\n<p>Les erreurs de r\u00e9plication sont in\u00e9vitables dans l'entreprise - il est d\u00e9cisif de les traiter de mani\u00e8re cibl\u00e9e et reproductible. En cas d'erreurs de duplicate key ou de not found, j'arr\u00eate le thread SQL, j'analyse l'\u00e9v\u00e9nement concern\u00e9 et je d\u00e9cide si je l'ignore de mani\u00e8re cibl\u00e9e ou si je nettoie les donn\u00e9es. Dans les configurations GTID, je renonce \u00e0 un saut global et, si n\u00e9cessaire, j'injecte une transaction vide avec le GTID concern\u00e9 afin que la configuration reste coh\u00e9rente. Les listes d'erreurs et les runbooks avec des \u00e9tapes claires permettent de gagner des minutes lorsque l'horloge tourne. Je surveille \u00e9galement les erreurs r\u00e9p\u00e9titives persistantes - elles indiquent souvent des filtres de r\u00e9plication inadapt\u00e9s ou des corrections \u00e0 chaud manuelles qui g\u00e9n\u00e8rent des divergences \u00e0 moyen terme.<\/p>\n\n<p>Pour la durabilit\u00e9 de la r\u00e9plication, j'\u00e9quilibre les param\u00e8tres de durabilit\u00e9 : je r\u00e8gle sync_relay_log et sync_relay_log_info de mani\u00e8re \u00e0 ce qu'un crash n'entra\u00eene pas de perte de donn\u00e9es, mais que le chemin IO ne soit pas trop ralenti. J'int\u00e8gre le cryptage TLS pour les liens de r\u00e9plication dans mes calculs : il augmente la charge CPU, mais r\u00e9duit le risque ; en cas de taux \u00e9lev\u00e9s, j'\u00e9value si la compression et TLS sont encore utiles ensemble ou si je pr\u00e9vois un profil avec un crypto-d\u00e9chargement plus important.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/mysql-replication-tech-8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance, alarmes et SLO<\/h2>\n\n<p>Sans alarmes fiables, tout r\u00e9glage est vain, c'est pourquoi je d\u00e9finis des alarmes claires. <strong>Seuils<\/strong>. Un exemple : alarme \u00e0 Seconds_Behind_Master pendant plus de 300 secondes, encore plus s\u00e9v\u00e8re pendant les campagnes actives. J'observe en outre la diff\u00e9rence entre Read_Master_Log_Pos et Exec_Master_Log_Pos pour les backlogs IO et SQL. <strong>distinguent<\/strong>. Pour chaque alarme, il existe un carnet de notes avec des mesures standard : Ralentir les requ\u00eates, mettre les lots en pause, d\u00e9placer les DDL, rel\u00e2cher temporairement les param\u00e8tres. Apr\u00e8s l'intervention, j'enregistre les effets et je mets \u00e0 jour les SLO afin que l'entreprise puisse tirer des enseignements de chaque incident.<\/p>\n\n<p>Je r\u00e9sume clairement les tableaux de bord : latence de r\u00e9plication, taux de commit, IOPS, CPU, taux d'utilisation du pool de tampons, swap et RTT r\u00e9seau. J'ajoute des contr\u00f4les de processus pour Slave_IO_Running et Slave_SQL_Running, afin que les pannes soient d\u00e9tect\u00e9es rapidement. Le journal des requ\u00eates lentes reste actif en permanence, mais avec des seuils bien pens\u00e9s afin d'\u00e9viter un afflux de journaux. <strong>\u00e9viter<\/strong>. Des rapports hebdomadaires indiquent les tendances dont je d\u00e9duis le budget pour le mat\u00e9riel ou les transformations. Ainsi, la fiabilit\u00e9 de la r\u00e9plication s'accro\u00eet pas \u00e0 pas et s'am\u00e9liore au quotidien avec <strong>chiffres<\/strong> occup\u00e9s.<\/p>\n\n<h2>Haute disponibilit\u00e9 et basculement sans surprise<\/h2>\n\n<p>Le retard et la disponibilit\u00e9 sont li\u00e9s, car les pannes en cha\u00eene se produisent souvent lorsque le syst\u00e8me est d\u00e9j\u00e0 stress\u00e9. <strong>R\u00e9plication<\/strong> commencer \u00e0 travailler. Je tiens \u00e0 disposition des chemins de basculement avec des GTID et je m'entra\u00eene \u00e0 effectuer des commutations dans un environnement de test afin que les changements de r\u00f4les soient rapides et propres. <strong>expire<\/strong>. Un commutateur IP virtuel ou un routeur intelligent pour le trafic de lecture\/\u00e9criture \u00e9vite les erreurs de lecture apr\u00e8s le changement. Des outils de gestion pour les contr\u00f4les de cluster et de sant\u00e9 permettent de gagner des minutes lorsque chaque seconde compte. Tu trouveras ici des concepts approfondis sur la redondance et la commutation : <a href=\"https:\/\/webhosting.de\/fr\/haute-disponibilite-hebergement-ha-hebergement-web-cluster-redondant\/\">H\u00e9bergement haute disponibilit\u00e9<\/a>.<\/p>\n\n<p>Il est important de ne pas traiter les r\u00e9pliques comme des corbeilles de rechange. Vous avez besoin de profils mat\u00e9riels identiques ou meilleurs si le routage des lecteurs y atterrit et si les utilisateurs ont besoin de r\u00e9ponses rapides. <strong>attendent<\/strong>. Je teste r\u00e9guli\u00e8rement : est-ce qu'un n\u0153ud tombe, est-ce que la latence reste en dessous des objectifs professionnels ? Si ce n'est pas le cas, j'augmente la capacit\u00e9 ou je d\u00e9sencombre les charges de travail. Ainsi, tu prot\u00e8ges \u00e0 la fois l'exp\u00e9rience utilisateur et l'homog\u00e9n\u00e9it\u00e9 des donn\u00e9es - sans mauvaises surprises. <strong>Surprises<\/strong>.<\/p>\n\n<h2>R\u00e9sum\u00e9 pour un d\u00e9marrage rapide<\/h2>\n\n<p>Je r\u00e9sume ce qui fonctionne imm\u00e9diatement pour que vous puissiez cibler votre d\u00e9calage de r\u00e9plication MySQL. <strong>abaisse<\/strong>. D\u00e9termine d'abord si c'est le thread IO ou SQL qui freine et surveille les positions Seconds_Behind_Master et Log. Cr\u00e9ez des cl\u00e9s primaires manquantes, fractionnez les mises \u00e0 jour importantes, d\u00e9placez les DDL et gardez un \u0153il sur le journal des requ\u00eates lentes sur le r\u00e9plicat. Augmente le buffer pool, active les parallel workers et d\u00e9finit innodb_flush_log_at_trx_commit=2 sur les r\u00e9plicas pour \u00e9viter les chemins d'\u00e9criture. <strong>soulagent<\/strong>. Si cela ne suffit pas, redimensionnez les r\u00e9pliques, r\u00e9partissez les charges de lecture et planifiez proprement les basculements - un coup d'\u0153il sur les instructions compl\u00e9mentaires relatives \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/replication-de-base-de-donnees-hebergement-master-slave-multi-master-syncio\/\">Architectures de r\u00e9plication<\/a> t'aide \u00e0 choisir le bon niveau. Ainsi, tu maintiens une disponibilit\u00e9 \u00e9lev\u00e9e, des temps de latence faibles et une coh\u00e9rence des donn\u00e9es fiable - mesurable et <strong>durable<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Minimiser le d\u00e9calage de r\u00e9plication MySQL : Causes, diagnostics et conseils contre le d\u00e9calage de synchronisation de la base de donn\u00e9es dans le scaling de l'h\u00e9bergement.<\/p>","protected":false},"author":1,"featured_media":18762,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-18769","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"479","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MySQL Replication Lag","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18762","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=18769"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18762"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}