{"id":19785,"date":"2026-06-07T18:18:37","date_gmt":"2026-06-07T16:18:37","guid":{"rendered":"https:\/\/webhosting.de\/database-transaction-logs-recovery-prozesse-datenbankschutz-sicher\/"},"modified":"2026-06-07T18:18:37","modified_gmt":"2026-06-07T16:18:37","slug":"database-transaction-logs-recovery-processus-protection-de-la-base-de-donnees-securisee","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/database-transaction-logs-recovery-prozesse-datenbankschutz-sicher\/","title":{"rendered":"Les journaux de transactions des bases de donn\u00e9es et les processus de r\u00e9cup\u00e9ration expliqu\u00e9s de mani\u00e8re compr\u00e9hensible"},"content":{"rendered":"<p><strong>Transaction de base de donn\u00e9es<\/strong> Les logs enregistrent d'abord chaque modification dans le journal et contr\u00f4lent l'\u00e9criture s\u00e9curis\u00e9e sur les pages de donn\u00e9es, ce qui permet d'obtenir des propri\u00e9t\u00e9s telles que <strong>sql durability<\/strong> m\u00eame en cas de crash. J'explique comment ces logs permettent la r\u00e9cup\u00e9ration en cas de crash avec analyse, redo et undo, comment le WAL contr\u00f4le les E\/S et comment la r\u00e9cup\u00e9ration ponctuelle est fiable dans la pratique.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>ACID<\/strong> s\u00e9curiser : les transactions restent atomiques, coh\u00e9rentes, isol\u00e9es et permanentes.<\/li>\n  <li><strong>WAL<\/strong> d'abord : \u00e9crire le log avant la page de donn\u00e9es pour donner des confirmations s\u00fbres.<\/li>\n  <li><strong>Redo\/Undo<\/strong>: Reprendre les modifications confirm\u00e9es apr\u00e8s le crash, annuler les modifications incompl\u00e8tes.<\/li>\n  <li><strong>points de contr\u00f4le<\/strong>R\u00e9duire les d\u00e9lais de r\u00e9cup\u00e9ration et contr\u00f4ler la croissance des logs.<\/li>\n  <li><strong>Sauvegardes<\/strong>: combiner des sauvegardes compl\u00e8tes, diff\u00e9rentielles, de logs pour une r\u00e9cup\u00e9ration ponctuelle.<\/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\/06\/datenbanktransaktionen-erklaerung-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Transactions et ACID en bref<\/h2>\n\n<p>A <strong>Transaction<\/strong> regroupe plusieurs op\u00e9rations de base de donn\u00e9es en une unit\u00e9 logique que je confirme enti\u00e8rement ou que je rejette enti\u00e8rement. Les quatre propri\u00e9t\u00e9s ACID fournissent les garde-fous : l'atomicit\u00e9 emp\u00eache les \u00e9tats semi-finis, la coh\u00e9rence pr\u00e9serve les r\u00e8gles et les contraintes, l'isolation d\u00e9couple les processus simultan\u00e9s et la durabilit\u00e9 prot\u00e8ge les donn\u00e9es confirm\u00e9es. Je veille \u00e0 ce qu'un COMMIT n'intervienne que lorsque les entr\u00e9es de log pertinentes sont \u00e9crites de mani\u00e8re durable, car c'est pr\u00e9cis\u00e9ment ce qui permet d'\u00e9viter les erreurs. <strong>Durabilit\u00e9<\/strong> est garantie. Inversement, un ROLLBACK annule toutes les \u00e9tapes de la transaction et r\u00e9tablit un \u00e9tat coh\u00e9rent. Ainsi, la base de donn\u00e9es reste utilisable de mani\u00e8re fiable m\u00eame en cas d'erreur, de panne de courant ou de red\u00e9marrage.<\/p>\n\n<h2>Write-Ahead Logging (WAL) compr\u00e9hensible<\/h2>\n\n<p>\u00c0 l'adresse suivante : <strong>WAL<\/strong>-J'\u00e9cris d'abord les modifications de mani\u00e8re s\u00e9quentielle dans le journal des transactions et je purge le journal sur le disque pour COMMIT, avant que les pages de donn\u00e9es ne suivent. Cette proc\u00e9dure r\u00e9duit les \u00e9critures al\u00e9atoires, augmente l'efficacit\u00e9 des E\/S et permet des confirmations s\u00fbres sans que chaque page de donn\u00e9es ne soit imm\u00e9diatement persistante. Dans la RAM, je modifie les pages dans la m\u00e9moire tampon, je cr\u00e9e des enregistrements de journal avec des valeurs avant\/apr\u00e8s et je les lie \u00e0 des ID de transaction. Un COMMIT signifie : les enregistrements de log sont permanents, la base de donn\u00e9es peut \u00e9crire ult\u00e9rieurement des pages de donn\u00e9es de mani\u00e8re asynchrone. C'est ainsi que je peux, apr\u00e8s un crash, \u00e0 l'aide des <strong>Log<\/strong>-Il n'y a pas de raison de ne pas comprendre ce qui a \u00e9t\u00e9 r\u00e9ellement confirm\u00e9.<\/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\/06\/datenbankmeeting4529.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Structure du journal : segments, troncature et points de contr\u00f4le<\/h2>\n\n<p>Un journal des transactions se compose souvent de plusieurs <strong>Segments<\/strong>, J'utilise la base de donn\u00e9es en continu pour que les \u00e9critures restent pr\u00e9visibles. Lorsqu'un segment est plein, je passe au suivant et lib\u00e8re les anciennes zones d\u00e9j\u00e0 sauvegard\u00e9es par troncature. Un point de contr\u00f4le marque l'\u00e9tat \u00e0 partir duquel je ne dois plus lire que les entr\u00e9es de journal les plus r\u00e9centes pour une restauration ; je raccourcis ainsi sensiblement le temps de d\u00e9marrage apr\u00e8s un crash. Pour approfondir, mon aper\u00e7u de <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-checkpointing-write-amplification-hosting-guide-scaling\/\">Remarques sur le checkpointing<\/a> et sur le lien avec la Write-Amplification, une classification claire des leviers d'action. En planifiant soigneusement l'intervalle entre les points de contr\u00f4le, la croissance automatique et la taille maximale des logs, on \u00e9vite les goulets d'\u00e9tranglement et on maintient la qualit\u00e9 des donn\u00e9es. <strong>Restauration<\/strong> planifiable.<\/p>\n\n<h2>R\u00e9cup\u00e9ration apr\u00e8s un crash en trois phases<\/h2>\n\n<p>Apr\u00e8s un plantage, la base de donn\u00e9es lit depuis le dernier <strong>Point de contr\u00f4le<\/strong> et commence par l'analyse : quelles transactions ont \u00e9t\u00e9 actives, quelles pages de donn\u00e9es sont concern\u00e9es, quels sont les commits disponibles. Lors de la phase Redo, le syst\u00e8me effectue les modifications confirm\u00e9es si elles ne sont pas encore enti\u00e8rement int\u00e9gr\u00e9es dans les pages de donn\u00e9es. Ensuite, la phase Undo r\u00e9initialise les transactions incompl\u00e8tes afin qu'aucune modification \u00e0 moiti\u00e9 termin\u00e9e ne soit visible. Ce processus est automatique, je vois les progr\u00e8s et les retards potentiels dans le journal et les messages d'\u00e9tat. Le point crucial reste le m\u00eame : Sans donn\u00e9es fiables <strong>Log<\/strong>-Aucun syst\u00e8me ne pourrait reconna\u00eetre ce qui \u00e9tait valable et ce qui ne l'\u00e9tait pas.<\/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\/06\/database-transaction-recovery-2057.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>MySQL\/InnoDB : crash recovery mysql en pratique<\/h2>\n\n<p>Avec InnoDB, MySQL g\u00e8re une <strong>Redo<\/strong>-Un journal des modifications confirm\u00e9es et un journal des annulations de transactions ouvertes. Lors du red\u00e9marrage apr\u00e8s une panne de courant, InnoDB reconna\u00eet \u00e0 l'aide de ces fichiers quelles transactions ont \u00e9t\u00e9 achev\u00e9es proprement. MySQL effectue ensuite des op\u00e9rations de reprogrammation pour les entr\u00e9es confirm\u00e9es et annule les transactions incompl\u00e8tes avec Undo. En cas de red\u00e9marrage impr\u00e9vu, je v\u00e9rifie les messages du serveur pour voir la dur\u00e9e et la progression de la restauration et pour identifier les goulots d'\u00e9tranglement comme les volumes pleins. En r\u00e9glant les fichiers journaux, la taille des tampons et les strat\u00e9gies de flush de mani\u00e8re appropri\u00e9e, on r\u00e9duit le temps de r\u00e9cup\u00e9ration. <strong>R\u00e9cup\u00e9ration<\/strong>-La dur\u00e9e de vie de l'enfant est nettement sup\u00e9rieure \u00e0 celle de l'adulte.<\/p>\n\n<h2>Performance contre durabilit\u00e9 : le compromis viable<\/h2>\n\n<p>Tout <strong>Durabilit\u00e9<\/strong>-garantie co\u00fbte de la latence, car un COMMIT exige l'\u00e9criture permanente du journal. Je r\u00e9duis ce temps d'attente en utilisant des m\u00e9moires plus rapides comme SSD ou NVMe, en regroupant les flushs et en utilisant des mod\u00e8les de lots judicieux. Dans les configurations distribu\u00e9es, la r\u00e9plication asynchrone peut soulager les chemins d'\u00e9criture locaux, mais elle apporte une petite fen\u00eatre de perte potentielle de donn\u00e9es en cas de d\u00e9faillance globale. Des param\u00e8tres tels qu'une politique de d\u00e9bordement plus stricte augmentent la s\u00e9curit\u00e9, mais prolongent les temps de r\u00e9action ; des modes plus souples r\u00e9duisent la latence, mais risquent d'endommager les donn\u00e9es en cas de crash peu apr\u00e8s le COMMIT. Le tableau suivant donne un aper\u00e7u concis des techniques courantes et de leurs effets.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Technique<\/th>\n      <th>Objectif<\/th>\n      <th>Influence sur la latence<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>WAL-Flush<\/strong> vers le COMMIT<\/td>\n      <td>Prot\u00e8ge les transactions confirm\u00e9es<\/td>\n      <td>Plus \u00e9lev\u00e9 en cas de stockage lent<\/td>\n      <td>Un support de donn\u00e9es log rapide s'av\u00e8re payant<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Group\u00e9<\/strong> Flushes<\/td>\n      <td>Moins d'appels d'E\/S<\/td>\n      <td>Plus bas gr\u00e2ce au regroupement<\/td>\n      <td>R\u00e9glage fin par timeout\/taille de lot<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>NVMe<\/strong>-M\u00e9moire<\/td>\n      <td>R\u00e9duit les pics de latence<\/td>\n      <td>Nettement plus bas<\/td>\n      <td>Pr\u00e9f\u00e9rer des volumes de log s\u00e9par\u00e9s<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>asynchrone<\/strong> R\u00e9plication<\/td>\n      <td>D\u00e9charge le commit local<\/td>\n      <td>Localement plus bas<\/td>\n      <td>Respecter la petite fen\u00eatre RPO<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Je mesure ces effets sous la charge de production, je d\u00e9finis des valeurs cibles pour la latence et le d\u00e9bit et je les compare aux exigences en mati\u00e8re de perte de donn\u00e9es. J'adapte ensuite les intervalles de flux, les tampons de logs et les supports de stockage de mani\u00e8re \u00e0 ce que la performance et la fiabilit\u00e9 soient optimales. <strong>S\u00e9curit\u00e9<\/strong> aller ensemble.<\/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\/06\/tech_office_data_logs_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strat\u00e9gie de sauvegarde et restauration ponctuelle<\/h2>\n\n<p>Un log transactionnel d\u00e9ploie tout son potentiel avec une <strong>Sauvegarde<\/strong>-Cha\u00eene de sauvegardes compl\u00e8tes, de sauvegardes diff\u00e9rentielles ou incr\u00e9mentielles et de sauvegardes de logs. En cas d'urgence, je restaure la derni\u00e8re sauvegarde compl\u00e8te, j'effectue ensuite des sauvegardes diff\u00e9rentielles ou incr\u00e9mentielles et j'applique les sauvegardes du journal jusqu'au moment voulu. Ainsi, je fais remonter de mani\u00e8re cibl\u00e9e des modifications en masse erron\u00e9es ou un DELETE sans WHERE. Je r\u00e9sume plus d'informations sur les proc\u00e9dures et les outils dans mon comparatif. <a href=\"https:\/\/webhosting.de\/fr\/sauvegarde-de-base-de-donnees-dump-vs-sauvegarde-de-serveur-snapshot\/\">Sauvegarde vs instantan\u00e9<\/a> ensemble. Tester r\u00e9guli\u00e8rement les restaurations permet de gagner du temps et de se prot\u00e9ger en cas de probl\u00e8me. <strong>Donn\u00e9es<\/strong> de la perte permanente.<\/p>\n\n<h2>Monitoring et probl\u00e8mes de logs typiques<\/h2>\n\n<p>Plein <strong>Log<\/strong>-Les volumes en \u00e9criture s'arr\u00eatent, c'est pourquoi je surveille en permanence leur taille, leur croissance et l'utilisation des E\/S. Un mod\u00e8le de r\u00e9cup\u00e9ration inappropri\u00e9 peut gonfler les journaux ou emp\u00eacher une r\u00e9cup\u00e9ration ponctuelle, c'est pourquoi je v\u00e9rifie le mode en fonction du sc\u00e9nario d'utilisation. Je planifie d\u00e9lib\u00e9r\u00e9ment la fr\u00e9quence des points de contr\u00f4le, les \u00e9tapes de croissance automatique et les moments de troncation afin de r\u00e9duire les temps de d\u00e9marrage apr\u00e8s un crash. En outre, je consigne les codes d'erreur de la base de donn\u00e9es qui indiquent des transactions bloqu\u00e9es, de longues dur\u00e9es de flux ou des goulots d'\u00e9tranglement dans le stockage. Un monitoring appliqu\u00e9 de mani\u00e8re cons\u00e9quente r\u00e9duit les risques et maintient la qualit\u00e9 des donn\u00e9es. <strong>Disponibilit\u00e9<\/strong> haut.<\/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\/06\/devdesk_log_recovery_7521.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tests de r\u00e9cup\u00e9ration, RTO et RPO<\/h2>\n\n<p>Sauvegardes sans <strong>Test<\/strong> restent sans valeur, c'est pourquoi j'effectue r\u00e9guli\u00e8rement des sauvegardes sur des syst\u00e8mes s\u00e9par\u00e9s et je v\u00e9rifie les \u00e9tapes. Pour chaque application, je d\u00e9finis un objectif de temps de r\u00e9cup\u00e9ration, c'est-\u00e0-dire le temps d'arr\u00eat maximal tol\u00e9r\u00e9, et un objectif de point de r\u00e9cup\u00e9ration, c'est-\u00e0-dire la perte maximale de donn\u00e9es accept\u00e9e. Ces objectifs contr\u00f4lent mon m\u00e9lange d'intervalles de sauvegarde, de fr\u00e9quence de sauvegarde des journaux et de strat\u00e9gie de r\u00e9plication. Un plan d'urgence propre d\u00e9signe les responsables, les outils, les mots de passe, les emplacements de stockage et les s\u00e9quences de commandes pr\u00e9cises. Ce n'est qu'avec une pratique document\u00e9e qu'il est possible d'effectuer une sauvegarde rapide. <strong>Restauration<\/strong> sans mauvaises surprises.<\/p>\n\n<h2>Virtualisation, cloud et r\u00e9plication<\/h2>\n\n<p>Dans les VM ou dans le cloud, je combine <strong>Instantan\u00e9s<\/strong> avec des sauvegardes de logs pour cr\u00e9er des points de r\u00e9cup\u00e9ration flexibles. Les configurations multi-n\u0153uds utilisent souvent le journal des transactions comme flux pour les r\u00e9plicas qui suivent presque en temps r\u00e9el. Ce faisant, je regarde les mod\u00e8les de coh\u00e9rence afin d'\u00e9viter les sc\u00e9narios de split brain et de r\u00e9gler clairement le failover. Pour une classification des strat\u00e9gies courantes, je vous renvoie \u00e0 mon aper\u00e7u de <a href=\"https:\/\/webhosting.de\/fr\/replication-de-base-de-donnees-coherence-split-brain-strategies-failover\/\">R\u00e9plication et basculement<\/a>. Celui qui veut \u00e9viter les voies de transport des donn\u00e9es log et <strong>Latence<\/strong> entre les zones, prend des d\u00e9cisions \u00e9clair\u00e9es pour la haute disponibilit\u00e9.<\/p>\n\n<h2>D\u00e9tails des logs internes : LSN, PageLSN et images pleine page<\/h2>\n\n<p>Derri\u00e8re chaque m\u00e9canisme de redo\/ondo se trouvent des num\u00e9ros de s\u00e9quence de journal (LSN). Je relie chaque modification \u00e0 un LSN et j'\u00e9cris en outre un PageLSN sur les pages de donn\u00e9es concern\u00e9es. Lors de la r\u00e9cup\u00e9ration, je v\u00e9rifie : si le PageLSN est plus petit que le LSN de l'entr\u00e9e de log, je dois appliquer Redo, sinon la page est d\u00e9j\u00e0 \u00e0 jour. Pour d\u00e9tecter les \u00e9critures d\u00e9chir\u00e9es, j'utilise des sommes de contr\u00f4le et - selon le moteur <em>Images pleine page<\/em> ou un tampon de double \u00e9criture. Cette proc\u00e9dure prot\u00e8ge contre les Torn Writes et rend les op\u00e9rations de retranscription idempotentes : une nouvelle application de la m\u00eame modification ne nuit pas, car la logique LSN emp\u00eache les ex\u00e9cutions multiples.<\/p>\n\n<h2>Logger physiquement ou logiquement - et pourquoi les deux sont n\u00e9cessaires<\/h2>\n\n<p>Je distingue les logs physiques (deltas sp\u00e9cifiques \u00e0 une page ou pages enti\u00e8res) des logs logiques (op\u00e9rations sp\u00e9cifiques \u00e0 une ligne ou \u00e0 un \u00e9tat). Les logs physiques sont compacts et rapides \u00e0 r\u00e9capituler, les logs logiques sont transportables et conviennent pour la r\u00e9plication ou les audits. Dans les syst\u00e8mes avec des logs \u00e0 plusieurs niveaux (par exemple redo du moteur de stockage plus log de r\u00e9plication s\u00e9par\u00e9), je fais attention \u00e0 la coh\u00e9rence : un COMMIT confirm\u00e9 doit appara\u00eetre proprement aussi bien dans le redo que dans le flux de r\u00e9plication. De cette mani\u00e8re, je peux effectuer des restaurations locales robustes tout en exploitant des r\u00e9pliques d\u00e9terministes et compr\u00e9hensibles.<\/p>\n\n<h2>Isolation, MVCC et Undo au quotidien<\/h2>\n\n<p>Les logs travaillent en \u00e9troite collaboration avec l'isolation choisie. Avec MVCC, je permets aux lecteurs de consulter des instantan\u00e9s coh\u00e9rents, tandis que les scribes cr\u00e9ent de nouvelles versions. L'undo log conserve les anciens \u00e9tats jusqu'\u00e0 ce qu'aucune transaction ne puisse plus les voir. Je planifie donc d\u00e9lib\u00e9r\u00e9ment les processus de purge\/vacuum : les longues transactions de lecture en cours bloquent la lib\u00e9ration des anciennes versions et gonflent les logs. Dans la pratique, je fixe des limites aux dur\u00e9es d'ex\u00e9cution des transactions, je v\u00e9rifie que les sauvegardes instantan\u00e9es r\u00e9guli\u00e8res n'ont pas d'influence sur la conservation des anciennes versions et, dans la mesure du possible, je tiens les charges de lecture qui n\u00e9cessitent un historique \u00e0 l'\u00e9cart des syst\u00e8mes primaires.<\/p>\n\n<h2>Chemins de commit, commit de groupe et influences mat\u00e9rielles<\/h2>\n\n<p>La dur\u00e9e d'un COMMIT est d\u00e9termin\u00e9e par le chemin \u00e0 parcourir pour atteindre un stockage stable. J'utilise Group Commit pour confirmer plusieurs transactions avec un flush commun et je v\u00e9rifie si mon syst\u00e8me <em>fsync\/fdatasync<\/em> et que les barri\u00e8res d'\u00e9criture ne sont pas d\u00e9sactiv\u00e9es. Un contr\u00f4leur avec cache write-back aliment\u00e9 par batterie ou des disques SSD avec protection contre la perte de puissance r\u00e9duisent les risques et la latence. Dans les environnements de type MySQL, je calibre sciemment les param\u00e8tres de flush : les modes stricts garantissent la durabilit\u00e9, les modes plus souples d\u00e9placent les charges dans des cas de crash rares. Ce qui compte, c'est l'\u00e9valuation document\u00e9e des risques - et la capacit\u00e9 \u00e0 la justifier par des valeurs mesur\u00e9es.<\/p>\n\n<h2>Conservation des logs, cryptage et conformit\u00e9<\/h2>\n\n<p>Les journaux de transactions peuvent contenir des informations sensibles. Je les verrouille au repos, je fais tourner les cl\u00e9s conform\u00e9ment aux instructions et je m'assure que les sauvegardes des logs sont \u00e9galement prot\u00e9g\u00e9es. Je d\u00e9termine la dur\u00e9e de conservation en fonction du RPO, des exigences l\u00e9gales et des budgets de stockage. Pour les audits, je consigne l'acc\u00e8s, la rotation et les processus de suppression de mani\u00e8re compr\u00e9hensible. L\u00e0 o\u00f9 des donn\u00e9es personnelles pourraient se retrouver dans des logs, je v\u00e9rifie le masquage \u00e0 un niveau sup\u00e9rieur ou je mise sur des logs logiques qui ne contiennent pas de donn\u00e9es brutes. Je combine ainsi la r\u00e9cup\u00e9rabilit\u00e9 avec la protection des donn\u00e9es et la conformit\u00e9.<\/p>\n\n<h2>Point-in-Time-Recovery \u00e9tape par \u00e9tape<\/h2>\n\n<p>En pratique, je proc\u00e8de comme suit pour une restauration \u00e0 un moment pr\u00e9cis : J'arr\u00eate les clients en \u00e9criture ou j'isole le syst\u00e8me cible, je choisis une sauvegarde compl\u00e8te comme base et je la restaure sur une instance s\u00e9par\u00e9e. J'utilise ensuite des sauvegardes diff\u00e9rentielles\/int\u00e9grales et je d\u00e9roule les sauvegardes des journaux juste avant l'\u00e9v\u00e9nement. Je d\u00e9finis le point d'arriv\u00e9e comme horodatage ou comme LSN\/SCN et je v\u00e9rifie que tous les segments de log sont pr\u00e9sents sans interruption. Apr\u00e8s l'importation, je contr\u00f4le la coh\u00e9rence et les effets secondaires (par exemple les sommes de d\u00e9clenchement, les index secondaires) et je ne recoupe le syst\u00e8me qu'\u00e0 ce moment-l\u00e0. Je documente au pr\u00e9alable les sources de temps, les fuseaux horaires et le skew d'horloge afin que le moment cible puisse \u00eatre d\u00e9termin\u00e9 sans \u00e9quivoque.<\/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\/06\/datenbankserver-protokoll-5321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Images d'erreurs fr\u00e9quentes et rem\u00e8des rapides<\/h2>\n\n<p>Je reconnais les dysfonctionnements typiques au mod\u00e8le : s'il manque un segment de log, l'importation s'interrompt - dans ce cas, seule une restauration ant\u00e9rieure ou un \u00e9tat de r\u00e9plique existant peut aider. Des messages tels que \u201eLog-LSN se trouve dans le futur\u201c indiquent un d\u00e9s\u00e9quilibre entre les fichiers de donn\u00e9es et l'historique des logs, souvent provoqu\u00e9 par un ordre de copie incorrect. La corruption dans le Redo me force \u00e0 d\u00e9marrer avec des modes de r\u00e9cup\u00e9ration conservateurs, \u00e0 lire uniquement et \u00e0 cr\u00e9er imm\u00e9diatement de nouvelles sauvegardes propres. Si un point de contr\u00f4le ne fonctionne jamais \u201e\u00e0 la tra\u00eene\u201c, je redimensionne la taille des logs, je diminue la proportion de pages sales ou je r\u00e9partis les E\/S afin que Redo ne devienne pas un probl\u00e8me permanent. Lorsque la partition de logs est pleine, il faut faire de la place, r\u00e9activer l'archivage, puis red\u00e9marrer les services avec pr\u00e9caution.<\/p>\n\n<h2>Planification de la capacit\u00e9 et benchmarks<\/h2>\n\n<p>Je dimensionne les logs en fonction du taux de changement r\u00e9el. Pour cela, je mesure les MB\/s dans le chemin d'\u00e9criture du log via des profils journaliers et hebdomadaires, je tiens compte des pics (batch, ETL, cl\u00f4ture mensuelle) et je garde au moins le multiple de ce pic comme tampon. La m\u00e9moire tampon du journal dans la RAM ne doit pas devenir un goulot d'\u00e9tranglement, sinon les latences augmentent en raison des rin\u00e7ages fr\u00e9quents. Pour les checkpoints, je d\u00e9finis clairement la dur\u00e9e maximale d'une reprise sur incident et j'en d\u00e9duis des valeurs cibles pour les dirty pages et les fen\u00eatres de log. J'utilise des benchmarks de mani\u00e8re cibl\u00e9e : des outils synth\u00e9tiques montrent des tendances, mais la validation s'effectue sous une charge r\u00e9aliste, y compris la r\u00e9plication, le cryptage et les m\u00e9canismes de protection de la m\u00e9moire. Ce n'est qu'ainsi que le RTO\/RPO correspond aux latences de commit mesur\u00e9es.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>Les journaux des transactions fournissent les <strong>Assurance<\/strong> contre la perte de donn\u00e9es : ils documentent les modifications, sauvegardent les commits et ram\u00e8nent les syst\u00e8mes \u00e0 des \u00e9tats coh\u00e9rents apr\u00e8s un crash. WAL rend le processus suffisamment rapide pour le quotidien et les pics de charge, les points de contr\u00f4le et la troncature permettent de ma\u00eetriser les temps de d\u00e9marrage et la taille des logs. Avec des sauvegardes compl\u00e8tes, diff\u00e9rentielles et de logs, j'obtiens une r\u00e9cup\u00e9ration ponctuelle et je peux inverser les erreurs avec pr\u00e9cision. En combinant la surveillance, les tests de r\u00e9cup\u00e9ration, un RTO\/RPO clair et une technique de stockage adapt\u00e9e, on obtient une fiabilit\u00e9 sans latence inutile. En fin de compte, ce qui compte, c'est que je comprenne les logs, que je les entretienne et que je m'y exerce r\u00e9guli\u00e8rement - c'est ainsi que l'efficacit\u00e9 de la sauvegarde reste intacte. <strong>Base de donn\u00e9es<\/strong> ma\u00eetrisable, m\u00eame en cas d'urgence.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprends comment fonctionne un journal des transactions de la base de donn\u00e9es, pourquoi il est essentiel pour la durabilit\u00e9 sql et comment les processus de r\u00e9cup\u00e9ration en cas de crash comme crash recovery mysql prot\u00e8gent tes donn\u00e9es de mani\u00e8re fiable.<\/p>","protected":false},"author":1,"featured_media":19778,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-19785","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":"86","_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":"Database Transaction","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":"19778","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19785","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=19785"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19778"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}