Bases relationnelles : lire la brique qui garde les données critiques

45 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 8 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Une base relationnelle range les données en tables liées entre elles et garantit, par ses transactions, qu'une opération est enregistrée entièrement ou pas du tout. C'est la brique qui porte presque toujours l'état le plus critique d'une architecture : commandes, comptes, factures. Cette leçon la lit avec la grille de la formation : ce qu'elle garantit, ce qu'il faut sauvegarder et comment, ce que la réplication apporte et ne remplace pas, pourquoi elle monte en charge autrement qu'une application, et ce qui la fait tomber.

Ce que vous allez apprendre

Dire ce qu'une base relationnelle garantit avec les transactions
Distinguer sauvegarde complète, journal de transactions et réplique
Expliquer pourquoi une base monte d'abord en charge verticalement
Reconnaître les modes de panne courants d'une base relationnelle

Qu'est-ce qu'une base relationnelle ?

Une base relationnelle organise les données en tables de lignes et de colonnes, reliées par des clés, et on l'interroge avec le langage SQL. PostgreSQL, MySQL, MariaDB ou SQLite en sont des exemples. Son schéma fixe la forme des données à l'avance : une commande a un numéro, un client, une date, et la base refuse une ligne qui ne respecte pas ces règles.

Sur un schéma d'architecture, elle se reconnaît à un cylindre appelé par l'application, souvent sur le port 5432 pour PostgreSQL ou 3306 pour MySQL. Elle est appelée, elle n'appelle personne : elle est au bout des flèches, et c'est là que remontent les pannes quand elle ralentit.

Que garantit une transaction ?

Une transaction regroupe plusieurs écritures qui réussissent toutes ou échouent toutes, et la base garantit ce comportement même en cas de panne. Valider une commande, c'est créer la commande, décrémenter le stock et enregistrer le paiement : si la machine s'arrête au milieu, aucune de ces trois écritures ne doit rester seule. Les quatre garanties se résument par l'acronyme ACID.

Lettre	Garantie	Ce qu'elle évite dans la boutique
Atomicité	tout ou rien	une commande enregistrée sans son paiement
Cohérence	les règles du schéma restent vraies	un stock négatif si une contrainte l'interdit
Isolation	les transactions simultanées ne se voient pas à moitié	deux clients qui achètent le dernier article
Durabilité	une transaction validée survit à une panne	une commande confirmée puis perdue au redémarrage

Ces garanties sont la raison d'être de la famille. Une architecture qui confie ses commandes à une brique sans transactions doit reconstruire ces garanties elle-même, ce qui est difficile et rarement fait correctement.

Que faut-il sauvegarder, et comment ?

Une base relationnelle se sauvegarde de deux façons complémentaires : une copie complète à intervalles réguliers, et l'archivage continu de son journal de transactions. Le journal (le WAL de PostgreSQL, le binlog de MySQL) enregistre chaque modification avant qu'elle soit appliquée. Rejouer ce journal par-dessus la dernière copie complète permet de revenir à n'importe quel instant : c'est la restauration à un point dans le temps.

Le choix décide directement du RPO vu dans le premier module. Une copie complète chaque nuit seule donne un RPO de 24 heures ; avec l'archivage continu du journal, il tombe à quelques minutes. Le schéma montre les trois flux qui partent d'une base de production bien tenue.

Trois copies, trois rôles : la réplique pour la disponibilité, le journal et la sauvegarde pour revenir en arrière. Source · SVG

Les trois flux ne protègent pas de la même chose. La réplique prend le relais si la primaire tombe, mais elle reçoit aussi une suppression par erreur. La sauvegarde complète et le journal archivé, eux, permettent de revenir avant l'erreur. Le guide Sauvegarde et restauration PostgreSQL montre les commandes de chaque méthode.

Que change la réplication ?

Une réplique reçoit en continu les modifications de la primaire, et peut servir les lectures ou prendre le relais si la primaire tombe. Elle améliore la disponibilité et peut soulager la primaire des lectures. Elle ne remplace jamais la sauvegarde, puisqu'elle recopie aussi les erreurs, et elle n'est pas automatiquement à jour.

La réplication est le plus souvent asynchrone : la primaire valide une transaction sans attendre la réplique, qui a donc un léger retard. Une lecture sur la réplique juste après une écriture peut renvoyer l'ancienne valeur, la cohérence éventuelle vue dans le premier module. Le mode synchrone supprime ce retard, au prix d'écritures plus lentes et d'une primaire qui attend sa réplique.

Comment une base monte-t-elle en charge ?

Une base relationnelle monte d'abord en charge verticalement, parce que ses transactions supposent que toutes les écritures passent par un seul endroit. Ajouter de la mémoire et des disques plus rapides à la primaire est le premier geste. Les répliques de lecture viennent ensuite, pour absorber les requêtes qui ne modifient rien.

Deux autres leviers se lisent sur un schéma. Un pool de connexions, comme PgBouncer devant PostgreSQL, partage un petit nombre de connexions entre de nombreuses copies d'application : chaque connexion coûte de la mémoire à la base, et cent copies qui en ouvrent vingt chacune la saturent. Le partitionnement des données entre plusieurs bases, enfin, est un dernier recours : il casse les transactions qui traversent les partitions.

Ce qui fait tomber une base relationnelle

Les pannes d'une base relationnelle viennent plus souvent de son usage que de son matériel. Le tableau rassemble les modes de panne les plus fréquents, avec le signal qui permet de les voir venir. C'est la partie « exploitation » de la grille : ce qu'il faut mesurer pour ne pas apprendre la panne par les clients.

Mode de panne	Ce qui se passe	Signal à surveiller
connexions épuisées	les nouvelles requêtes sont refusées	nombre de connexions ouvertes
disque plein	la base cesse d'écrire, parfois de démarrer	espace libre, croissance du journal
requête lente ou verrou	les transactions s'empilent derrière	requêtes les plus longues, attentes de verrou
réplique en retard	lectures périmées, bascule qui perd des données	retard de réplication
journal non archivé	le disque se remplit, le RPO n'est plus tenu	âge du dernier journal archivé

Ce que la base relationnelle change dans la boutique

Dans la boutique, la base relationnelle porte depuis le début les commandes ; le module Stocker lui retire ce qui n'a pas besoin de ses garanties. Les sessions partent dans un cache, les images dans un stockage objet, et la base ne garde que les données qui exigent des transactions. Elle redevient plus petite, plus simple à sauvegarder et moins sollicitée.

Version 2 du fil rouge : la base ne garde que les commandes, le reste part vers des familles spécialisées. Source · SVG

Une base relationnelle : ce qu'elle apporte, ce qu'elle coûte

Une base relationnelle apporte des garanties fortes sur les données, au prix d'une brique difficile à répartir et exigeante à exploiter. Le tableau pose ce compromis pour les commandes de la boutique.

Ce qu'on gagne	Ce qu'on paie
des transactions ACID : jamais de commande à moitié enregistrée	une montée en charge surtout verticale
un schéma qui refuse les données incohérentes	des migrations de schéma à préparer à chaque évolution
des requêtes SQL riches, jointures comprises	une primaire unique pour les écritures, donc un SPOF à protéger
une restauration à un point dans le temps	des sauvegardes, journaux et répliques à surveiller en continu

Qui prend le relais pour installer et exploiter une base ?

Cette leçon décrit le rôle architectural de la famille ; installer, configurer, sécuriser, sauvegarder et superviser une base relèvent des guides spécialisés. La section Bases de données relationnelles compare SQLite, PostgreSQL et MySQL ; les guides PostgreSQL et MySQL couvrent l'administration de bout en bout ; le guide Données managées traite les offres des fournisseurs cloud.

Pièges de lecture courants

Ces erreurs reviennent devant une base sur un schéma, et elles viennent presque toutes d'une copie prise pour une autre :

Prendre la réplique pour une sauvegarde : elle recopie les erreurs.
Ne sauvegarder que la nuit et promettre un RPO de quelques minutes.
Multiplier les copies d'application sans pool de connexions devant la base.
Lire sur une réplique juste après une écriture et croire à une perte.
Confier des données transactionnelles à une brique sans transactions.

À retenir

Une base relationnelle garantit des transactions ACID : tout ou rien, même en cas de panne.
Elle porte l'état le plus critique de l'architecture, au bout des flèches.
La sauvegarde combine copie complète et journal archivé ; la réplique sert la disponibilité, pas le retour en arrière.
Elle monte d'abord en charge verticalement, puis par répliques de lecture et pool de connexions.
Ses pannes viennent surtout de l'usage : connexions, disque, verrous, retard de réplication.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin