Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026

Guide DBA — Exploitation et administration des bases classiques

PostgreSQL standalone, Patroni, pgBouncer, Oracle RMAN/Data Guard, MySQL/MariaDB, Galera, sauvegarde, restauration, PRA/PCA.

1. Vue d’ensemble — DBA classique, mais niveau production

Objectif du guide

Préparer une fiche de poste DBA orientée exploitation traditionnelle ou virtualisée : instances installées sur VM ou serveurs physiques, haute disponibilité, réplication, pool de connexions, sauvegarde, restauration, PRA/PCA et supervision opérationnelle.

Cette thématique correspond au DBA de production historique : le moteur est installé sur un serveur Linux, une VM, un cluster on-prem, ou une infrastructure virtualisée. Le DBA n’est pas seulement responsable du SQL. Il doit garantir la disponibilité, la cohérence, la sauvegarde, la restauration, la sécurité, les performances et la capacité à redémarrer après incident.

PostgreSQL
Standalone, streaming replication, Patroni, HAProxy, pgBouncer, WAL, PITR.
Oracle
Administration courante, RMAN, archivelog, Data Guard, switchover, failover.
MySQL
Binlog, GTID, réplication asynchrone, semi-synchrone, backups et restore.
MariaDB
Réplication, Galera, quorum, SST/IST, MaxScale éventuel, PRA/PCA.

Ce que l’entreprise attend réellement

DomaineCe qu’il faut savoir faireCe qu’il faut démontrer en entretien
ExploitationDémarrage/arrêt, patching, suivi des logs, gestion espace disque, connexions, locks, incidents.Tu sais diagnostiquer vite, sans paniquer, avec une méthode claire.
Haute disponibilitéReplica, standby, cluster manager, failover, switchover, split brain, VIP/proxy.Tu sais que la HA n’existe que si elle a été testée.
SauvegardeBackup full, incrémental, WAL/binlog/archivelog, catalogue, rétention, chiffrement.Tu sais choisir entre dump logique, backup physique et restauration point-in-time.
RestaurationRestore complet, restore partiel, PITR, test régulier, preuve de restauration.Tu répètes : un backup non restauré n’est pas un backup validé.
PRA/PCARPO/RTO, site secours, bascule, retour arrière, procédures de crise.Tu distingues continuité de service, reprise d’activité et simple sauvegarde.
Vision globale d’une plateforme DBA classique
Applications
Proxy / pooler
Primary DB
Replicas / Standby
Backups / PRA

Les 16 blocs du guide

  1. Vue d’ensemble et posture DBA production.
  2. Infrastructure traditionnelle ou virtualisée.
  3. PostgreSQL standalone.
  4. Streaming replication PostgreSQL.
  5. Patroni pour haute disponibilité PostgreSQL.
  6. pgBouncer pour pooling de connexions.
  7. Oracle Database administration courante.
  8. Oracle RMAN backup/recovery.
  9. Oracle Data Guard.
  10. MySQL/MariaDB administration courante.
  11. Réplication asynchrone et semi-synchrone.
  12. MariaDB Galera Cluster.
  13. Stratégie de sauvegarde.
  14. Tests de restauration.
  15. PRA/PCA, RPO/RTO, runbooks.
  16. Check-list entretien et infrastructure de lab.
Positionnement : pour ce poste, il faut se présenter comme un DBA de production capable de gérer des moteurs critiques, pas comme un simple utilisateur SQL. La valeur forte est la maîtrise du cycle incident → diagnostic → restauration → prévention.

2. Infrastructure traditionnelle ou virtualisée

Les bases classiques tournent généralement sur des VM Linux ou serveurs physiques. Le DBA doit connaître l’OS, le stockage, le réseau, les fenêtres de maintenance, les sauvegardes système, les limites CPU/RAM et les mécanismes de fencing ou de bascule.

Architecture de lab recommandée

ComposantMinimum labVersion crédible entretienObjectif
VM PostgreSQL2 VM3 VM + 1 proxyPrimary, standby, Patroni, HAProxy, pgBouncer.
VM Oracle1 VM XE ou Free2 VM pour Data Guard labAdministration, RMAN, archivelog, standby.
VM MySQL/MariaDB2 VM3 VM + proxyRéplication, GTID, semi-sync, Galera.
Backup server1 répertoire NFSServeur dédié + stockage objetRétention, restore, séparation des responsabilités.
MonitoringScripts + logsPrometheus/Grafana ou ZabbixAlerting CPU, RAM, disque, lag, backup failed.

Arborescence serveur recommandée

server-layout.txt
/srv/db-platform/
  postgres/
    data/
    wal_archive/
    backup/
    scripts/
    logs/
  oracle/
    backup/
    archivelog/
    scripts/
    logs/
  mysql/
    data/
    binlog_archive/
    backup/
    scripts/
    logs/
  runbooks/
  monitoring/
  inventory/

Points d’infrastructure à vérifier

Stockage

Type disque, latence, IOPS, cache, RAID, LVM, snapshots, extension volume, rétention.

Réseau

Latence entre nœuds, DNS, VIP, load balancer, firewall, MTU, routage site secours.

Système

Kernel, huge pages Oracle, limites fichiers, systemd, journald, NTP/chrony, timezone.

Sécurité

Comptes OS, sudo, SSH, chiffrement, certificats, rotation mots de passe, audit.

Supervision

Alertes disque, lag réplication, durée backup, locks, sessions, mémoire, erreurs logs.

Runbooks

Procédures bascule, restore, montée de version, incident disque, incident réplication.

Piège classique : une base peut être parfaitement configurée, mais tomber à cause d’un stockage lent, d’un filesystem plein, d’un NTP désynchronisé ou d’un firewall mal documenté.

3. PostgreSQL standalone — socle d’administration

PostgreSQL standalone désigne une instance principale isolée, généralement installée sur une VM. Avant de parler Patroni ou réplication, il faut maîtriser le socle : configuration, journaux WAL, connexions, sécurité, sauvegarde, vacuum et diagnostic.

Paramètres essentiels

ParamètreRôlePoint de vigilance
shared_buffersCache mémoire PostgreSQL.Souvent 25 % RAM serveur comme point de départ, à ajuster par mesure.
work_memMémoire par opération de tri/hash.Attention multiplication par nombre de sessions/opérations.
max_connectionsNombre maximal de connexions.Trop haut = mémoire gaspillée ; préférer pgBouncer.
wal_levelNiveau de journalisation WAL.Nécessaire pour réplication et PITR.
archive_modeActive l’archivage WAL.Obligatoire pour PITR sérieux.
autovacuumMaintenance MVCC.Un autovacuum mal réglé crée bloat et lenteurs.

Exemple de configuration de base

postgresql.conf
listen_addresses = '*'
port = 5432
max_connections = 200
shared_buffers = '4GB'
effective_cache_size = '12GB'
work_mem = '16MB'
maintenance_work_mem = '1GB'
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /srv/db-platform/postgres/wal_archive/%f && cp %p /srv/db-platform/postgres/wal_archive/%f'
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
log_min_duration_statement = 1000
log_checkpoints = on
log_connections = on
log_disconnections = on

Contrôles quotidiens DBA

postgres-daily-checks.sql
SELECT datname, numbackends, xact_commit, xact_rollback
FROM pg_stat_database
ORDER BY numbackends DESC;

SELECT pid, usename, state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

SELECT schemaname, relname, n_dead_tup, last_autovacuum, last_vacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

SELECT slot_name, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;
Message entretien : PostgreSQL standalone est simple à démarrer, mais la vraie compétence DBA commence avec WAL, autovacuum, pooling, sauvegarde physique et diagnostic des locks.

4. PostgreSQL streaming replication

La streaming replication PostgreSQL consiste à envoyer les WAL du primary vers un ou plusieurs standby. Le standby peut servir de secours, de lecture read-only, ou de base pour un PRA. PostgreSQL distingue bien le serveur primary, qui envoie les WAL, et le standby, qui les reçoit.

Flux streaming replication PostgreSQL
Application
Primary PostgreSQL
WAL
Standby 1
WAL
Standby 2

Préparation du primary

primary-replication.sql
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'change-me';

SELECT pg_create_physical_replication_slot('standby_01');
SELECT pg_create_physical_replication_slot('standby_02');
pg_hba.conf
host replication replicator 10.10.20.11/32 scram-sha-256
host replication replicator 10.10.20.12/32 scram-sha-256

Création d’un standby avec pg_basebackup

create-standby.sh
systemctl stop postgresql
rm -rf /var/lib/postgresql/18/main/*

pg_basebackup \
  --host=10.10.20.10 \
  --port=5432 \
  --username=replicator \
  --pgdata=/var/lib/postgresql/18/main \
  --format=plain \
  --write-recovery-conf \
  --slot=standby_01 \
  --checkpoint=fast \
  --progress

systemctl start postgresql

Commandes de diagnostic

Sur primarySur standbyInterprétation
SELECT * FROM pg_stat_replication;SELECT pg_is_in_recovery();Le primary voit ses standby ; le standby confirme son mode recovery.
SELECT * FROM pg_replication_slots;SELECT now() - pg_last_xact_replay_timestamp();Contrôle slots, rétention WAL et lag de rejeu.
SELECT pg_current_wal_lsn();SELECT pg_last_wal_replay_lsn();Compare la position WAL primary/standby.
Point critique : les replication slots protègent les standby, mais peuvent remplir le disque du primary si un standby reste absent trop longtemps.

5. Patroni — haute disponibilité PostgreSQL

Patroni automatise la haute disponibilité PostgreSQL. Il s’appuie sur un Distributed Configuration Store comme etcd, Consul, ZooKeeper ou Kubernetes pour décider quel nœud est leader et orchestrer failover/switchover.

Architecture Patroni typique
Application
HAProxy / VIP
Patroni Leader
etcd / Consul
Patroni Replicas

Composants à préparer

ComposantRôlePoint de vigilance
PatroniContrôle PostgreSQL, leader election, failover, switchover.Ne pas modifier PostgreSQL directement sans comprendre Patroni.
etcd / ConsulConsensus, état du cluster, verrou leader.Quorum obligatoire ; éviter un seul nœud en production.
HAProxyRoute écritures vers leader et lectures vers replicas.Health checks Patroni REST API.
WatchdogProtection contre split brain.Très important sur infrastructure critique.

Exemple patroni.yml simplifié

patroni.yml
scope: pg-prod
name: pg-node-01

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.10.20.10:8008

etcd3:
  hosts: 10.10.30.10:2379,10.10.30.11:2379,10.10.30.12:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        hot_standby: 'on'
        max_wal_senders: 10
        max_replication_slots: 10
  initdb:
    - encoding: UTF8
    - data-checksums

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.10.20.10:5432
  data_dir: /var/lib/postgresql/18/main
  bin_dir: /usr/lib/postgresql/18/bin
  authentication:
    superuser:
      username: postgres
      password: change-me
    replication:
      username: replicator
      password: change-me

HAProxy devant Patroni

haproxy.cfg
listen postgres_write
  bind *:5432
  option httpchk GET /primary
  http-check expect status 200
  default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
  server pg-node-01 10.10.20.10:5432 check port 8008
  server pg-node-02 10.10.20.11:5432 check port 8008
  server pg-node-03 10.10.20.12:5432 check port 8008

listen postgres_read
  bind *:5433
  option httpchk GET /replica
  http-check expect status 200
  server pg-node-01 10.10.20.10:5432 check port 8008
  server pg-node-02 10.10.20.11:5432 check port 8008
  server pg-node-03 10.10.20.12:5432 check port 8008
Question probable : Patroni n’est pas un moteur de réplication. PostgreSQL fait la réplication ; Patroni orchestre l’état du cluster, la promotion, la réintégration et l’exposition du leader.

6. pgBouncer — pooling de connexions PostgreSQL

PostgreSQL gère mal les très grands nombres de connexions directes. pgBouncer agit comme un pooler léger entre l’application et PostgreSQL. Il réduit le coût d’ouverture des connexions et protège le serveur contre les pics applicatifs.

Modes de pooling

ModePrincipeUsageRisque
sessionUne connexion serveur reste liée à la session client.Compatibilité maximale.Moins efficace.
transactionLa connexion serveur est rendue au pool à la fin de chaque transaction.Mode le plus courant pour web apps.Attention aux sessions stateful, prepared statements, temp tables.
statementLibération après chaque statement.Cas très spécifiques.Transactions multi-statements interdites.

Exemple pgbouncer.ini

pgbouncer.ini
[databases]
appdb = host=10.10.20.100 port=5432 dbname=appdb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 50
min_pool_size = 10
reserve_pool_size = 20
server_idle_timeout = 600
server_lifetime = 3600
ignore_startup_parameters = extra_float_digits
admin_users = postgres, dba_admin
stats_users = dba_readonly

Commandes utiles

pgbouncer-admin.sql
SHOW POOLS;
SHOW CLIENTS;
SHOW SERVERS;
SHOW STATS;
SHOW CONFIG;
PAUSE appdb;
RESUME appdb;
RELOAD;
Bon argument : pgBouncer n’améliore pas une mauvaise requête SQL. Il protège surtout PostgreSQL contre la surcharge de connexions.

7. Oracle Database — administration courante

Oracle Database demande une discipline particulière : instance, listener, spfile/pfile, control files, datafiles, redo logs, archivelog, tablespaces, users, rôles, jobs, AWR/ASH et patching. Le DBA doit savoir opérer l’instance et lire les symptômes.

Objets et composants fondamentaux

ComposantRôleSurveillance
InstanceSGA + processus background.Alert log, mémoire, sessions, wait events.
DatabaseFichiers physiques : datafiles, redo logs, control files.État fichiers, checkpoints, corruption, espace.
ListenerEntrée réseau des clients.Port, services, logs, firewall.
TablespaceConteneur logique des segments.Autoextend, free space, fragmentation.
Redo / Archive logsJournalisation transactionnelle.Switch rate, destination pleine, archiver stuck.

Commandes Oracle courantes

oracle-daily-checks.sql
SELECT instance_name, status, database_status
FROM v$instance;

SELECT name, open_mode, database_role, log_mode
FROM v$database;

SELECT tablespace_name, ROUND(used_percent, 2) AS used_percent
FROM dba_tablespace_usage_metrics
ORDER BY used_percent DESC;

SELECT dest_id, status, destination, error
FROM v$archive_dest_status
ORDER BY dest_id;

SELECT username, status, lock_date, expiry_date
FROM dba_users
ORDER BY username;

Opérations DBA classiques

Gestion espace

Tablespaces, datafiles, autoextend, segments volumineux, purge, archivelogs.

Sécurité

Users, profiles, roles, grants, audit, comptes verrouillés, rotation passwords.

Performance

AWR, ASH, wait events, plans SQL, stats optimizer, index, sessions bloquantes.

Maintenance

Patching, sauvegarde, contrôle corruption, jobs, alert log, listener.

Disponibilité

Data Guard, RAC éventuel, services, switchover, failover, redémarrage propre.

Documentation

Inventaire, versions, paramètres, schémas critiques, RPO/RTO, dépendances.

Piège Oracle : ne pas confondre sauvegarde Oracle logique, sauvegarde filesystem et sauvegarde RMAN cohérente.

8. Oracle RMAN — backup et recovery

RMAN est l’outil Oracle de référence pour les sauvegardes et restaurations physiques. Il sait gérer les datafiles, control files, archivelogs, catalogues, incrémentaux, validation et recovery. Le DBA doit savoir créer une stratégie, pas seulement lancer une commande.

Stratégie RMAN standard

ÉlémentDécision DBAContrôle attendu
Mode archivelogObligatoire pour recovery point-in-time sérieux.SELECT log_mode FROM v$database;
Backup fullHebdomadaire ou selon volumétrie.Durée, taille, validation.
Backup incrémentalQuotidien ou plus fréquent.Recoverability et fenêtre RTO.
ArchivelogsSauvegarder et purger selon politique.Destination jamais pleine.
Control file autobackupÀ activer systématiquement.Restore possible même en perte sévère.

Configuration RMAN

rman-config.rcv
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

Script RMAN backup quotidien

daily-backup.rcv
RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/oracle/%d_%T_%U.bkp';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup/oracle/%d_%T_%U.bkp';
  BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 DATABASE TAG 'DAILY_LEVEL_1';
  BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG 'ARCHIVELOG_BACKUP';
  BACKUP CURRENT CONTROLFILE TAG 'CONTROLFILE_BACKUP';
  RELEASE CHANNEL c1;
  RELEASE CHANNEL c2;
}
CROSSCHECK BACKUP;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT OBSOLETE;

Validation RMAN

rman-validate.rcv
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;
VALIDATE CHECK LOGICAL DATABASE;
Phrase forte : RMAN ne se limite pas à produire des fichiers. Il faut valider les backups, tester la restauration, contrôler la rétention et protéger les archivelogs.

9. Oracle Data Guard — standby, switchover, failover

Data Guard maintient une ou plusieurs bases standby à partir d’une base primary. Le but est la haute disponibilité, la reprise après sinistre et parfois le reporting read-only avec Active Data Guard.

Data Guard — flux redo vers standby
Primary Oracle
Redo transport
Standby Oracle
Apply
DR site / Read only

Concepts à maîtriser

ConceptRôleQuestion d’entretien
Physical standbyCopie bloc à bloc transactionnellement cohérente.Comment vérifier le apply lag ?
Redo transportEnvoi des redo logs vers standby.Différence sync/async ?
Redo applyApplication des redo sur standby.Que faire si le apply est bloqué ?
SwitchoverBascule contrôlée, sans perte, planifiée.Quand l’utiliser ?
FailoverBascule d’urgence après perte primary.Quelle conséquence sur l’ancien primary ?

Contrôles Data Guard

dataguard-checks.sql
SELECT name, database_role, open_mode, protection_mode, protection_level
FROM v$database;

SELECT dest_id, status, error, recovery_mode, destination
FROM v$archive_dest_status
ORDER BY dest_id;

SELECT name, value, unit, time_computed
FROM v$dataguard_stats
ORDER BY name;

SELECT process, status, thread#, sequence#, block#, blocks
FROM v$managed_standby
ORDER BY process;

Switchover contrôlé avec Data Guard Broker

dgmgrl-switchover.txt
DGMGRL> CONNECT sys@primary_db
DGMGRL> SHOW CONFIGURATION;
DGMGRL> VALIDATE DATABASE primary_db;
DGMGRL> VALIDATE DATABASE standby_db;
DGMGRL> SWITCHOVER TO standby_db;
DGMGRL> SHOW CONFIGURATION;
Point critique : un failover est une décision de crise. Il peut imposer une réintégration complexe ou un rebuild de l’ancien primary.

10. MySQL / MariaDB — administration courante

MySQL et MariaDB restent très présents en environnement traditionnel. Le DBA doit connaître InnoDB, binlogs, users, réplication, sauvegarde physique/logique, slow query log, buffer pool et opérations de maintenance.

Paramètres importants

ParamètreRôleVigilance
innodb_buffer_pool_sizeCache principal InnoDB.Souvent la clé de performance sur serveur dédié.
binlog_formatFormat des événements binlog.ROW recommandé pour réplication robuste.
server_idIdentifiant unique réplication.Chaque serveur doit avoir un ID distinct.
gtid_modeGestion des transactions globales.Facilite failover et resynchronisation.
slow_query_logDétection requêtes lentes.Base du tuning SQL.

Exemple MySQL my.cnf

my.cnf
[mysqld]
server_id = 101
bind-address = 0.0.0.0
port = 3306

innodb_buffer_pool_size = 8G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_replica_updates = ON

slow_query_log = ON
long_query_time = 1
log_error = /var/log/mysql/error.log

Contrôles quotidiens

mysql-daily-checks.sql
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW BINARY LOGS;
SHOW PROCESSLIST;
SELECT user, host, plugin, account_locked FROM mysql.user ORDER BY user, host;
Bon réflexe : sur MySQL/MariaDB, vérifier très tôt les binlogs, l’espace disque, le slow query log et l’état InnoDB.

11. MySQL / MariaDB — réplication asynchrone et semi-synchrone

La réplication MySQL classique repose sur le binlog du source et le relay log des replicas. Par défaut elle est asynchrone : le source peut valider une transaction sans garantie qu’un replica l’ait reçue. La semi-synchrone ajoute une attente d’acquittement.

Réplication MySQL / MariaDB
Source
Binlog
Replica 1
Relay log
SQL apply
+
Replica 2

Comparaison réplication

ModeAvantageRisqueCas d’usage
AsynchroneSimple, rapide, peu bloquant.Transactions perdues possibles si source crash avant envoi.Read replicas, reporting, PRA avec RPO non nul.
Semi-synchroneRéduit le risque de perte.Latence commit plus élevée, dépend des replicas.Production critique avec besoin de meilleure durabilité.
GTIDFailover et repositionnement facilités.Demande discipline de configuration.Clusters modernes et procédures de bascule.

Création d’un utilisateur de réplication

replication-user.sql
CREATE USER 'repl'@'10.10.40.%' IDENTIFIED BY 'change-me';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.10.40.%';
FLUSH PRIVILEGES;

Configuration replica avec GTID

replica-setup.sql
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.10.40.10',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'change-me',
  SOURCE_AUTO_POSITION = 1;

START REPLICA;
SHOW REPLICA STATUS\G

Semi-synchrone MySQL

semisync.sql
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';

SET GLOBAL rpl_semi_sync_source_enabled = 1;
SET GLOBAL rpl_semi_sync_replica_enabled = 1;
SET GLOBAL rpl_semi_sync_source_timeout = 10000;

SHOW VARIABLES LIKE 'rpl_semi_sync%';
SHOW STATUS LIKE 'Rpl_semi_sync%';
Question piège : une réplication n’est pas une sauvegarde. Une suppression logique ou un mauvais script peut être répliqué partout.

12. MariaDB Galera Cluster

Galera fournit une réplication virtuellement synchrone et multi-primary. C’est une solution de haute disponibilité puissante, mais elle exige de bien comprendre quorum, certification, latence réseau, SST/IST et split brain.

Galera — cluster multi-nœuds avec quorum
Node 1
Node 2
Node 3
Proxy / MaxScale

Concepts clés Galera

ConceptDéfinitionVigilance
QuorumMajorité nécessaire pour rester Primary Component.Préférer nombre impair de nœuds.
SSTState Snapshot Transfer, resynchronisation complète.Coûteux, peut impacter production.
ISTIncremental State Transfer, rattrapage incrémental.Dépend de la taille du gcache.
CertificationValidation des transactions concurrentes.Conflits possibles en multi-writer.
Flow controlRalentissement global si un nœud ne suit pas.Latence réseau et nœud lent critiques.

Exemple galera.cnf

galera.cnf
[mysqld]
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
bind-address = 0.0.0.0

wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = prod_galera
wsrep_cluster_address = gcomm://10.10.50.10,10.10.50.11,10.10.50.12
wsrep_node_address = 10.10.50.10
wsrep_node_name = galera-node-01
wsrep_sst_method = mariabackup
wsrep_sst_auth = sst_user:change-me

Contrôles Galera

galera-checks.sql
SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_ready';
SHOW STATUS LIKE 'wsrep_connected';
SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_flow_control_paused';
Position prudente : même si Galera est multi-primary, beaucoup d’architectures production préfèrent un mode single-writer logique pour réduire les conflits applicatifs.

13. Stratégie de sauvegarde

Une stratégie de sauvegarde sérieuse combine fréquence, type de backup, journalisation transactionnelle, stockage externe, rétention, chiffrement, immutabilité éventuelle et tests de restauration. Elle doit être liée aux RPO/RTO métiers.

Types de sauvegarde par moteur

MoteurBackup logiqueBackup physiqueJournal transactionnelOutils
PostgreSQLpg_dump, pg_dumpallpg_basebackup, pgBackRest, BarmanWAL archivepgBackRest, Barman, WAL-G.
OracleData PumpRMANArchived redo logsRMAN, catalog, Data Guard.
MySQLmysqldump, MySQL Shell dumpEnterprise Backup, Percona XtraBackupBinary logsxtrabackup, mysqlbinlog.
MariaDBmariadb-dumpmariabackupBinary logs / Galera statemariabackup, MaxScale tools.

Planning type

FréquenceActionObjectifValidation
Toutes les 5-15 minArchivage WAL/binlog/archivelog.Réduire le RPO.Contrôle retard et destination.
QuotidienBackup incrémental ou différentiel.Restauration rapide.Logs backup + checksum.
HebdomadaireBackup complet.Base de récupération.Restore test en environnement isolé.
MensuelBackup longue rétention.Conformité / audit.Inventaire et preuve d’intégrité.

Exemple PostgreSQL avec pg_basebackup

pg-basebackup.sh
backup_dir="/backup/postgres/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$backup_dir"

pg_basebackup \
  --host=127.0.0.1 \
  --port=5432 \
  --username=backup_user \
  --pgdata="$backup_dir" \
  --format=tar \
  --gzip \
  --checkpoint=fast \
  --wal-method=stream \
  --progress
Règle absolue : ne pas stocker les backups uniquement sur le serveur de production. Une perte filesystem ou ransomware détruirait tout.

14. Tester les restaurations

Tester une restauration est l’acte le plus important du DBA. Une entreprise ne paie pas seulement pour des backups ; elle paie pour la certitude de pouvoir récupérer un service, des données et un historique dans un délai acceptable.

Types de restauration

TypeExempleCompétence attendue
Restore completPerte serveur ou corruption massive.Reconstruire instance complète depuis backup.
PITRSuppression accidentelle à 10:42.Revenir à 10:41:59 sans appliquer l’erreur.
Restore partielTable supprimée ou schéma altéré.Restaurer ailleurs puis réinjecter sélectivement.
Restore DRPerte site primaire.Basculer vers site secours avec procédure métier.

Runbook de test restore

  1. Choisir un backup précis et noter son identifiant.
  2. Provisionner un serveur ou environnement isolé.
  3. Restaurer fichiers de données et journaux transactionnels.
  4. Appliquer la récupération jusqu’au point choisi.
  5. Ouvrir la base en mode contrôlé.
  6. Vérifier comptes, tables critiques, volumes, cohérence applicative.
  7. Mesurer durée réelle de restauration.
  8. Documenter écarts par rapport au RTO attendu.

PostgreSQL PITR conceptuel

postgresql-pitr.conf
restore_command = 'cp /srv/db-platform/postgres/wal_archive/%f %p'
recovery_target_time = '2026-06-01 10:41:59+02'
recovery_target_action = 'promote'

Oracle restore validation

oracle-restore-test.rcv
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG FROM TIME "SYSDATE-1" VALIDATE;
RECOVER DATABASE VALIDATE;
Livrable attendu : un tableau mensuel de tests de restauration avec date, moteur, backup utilisé, durée, résultat, écarts, actions correctives et validation métier.

15. PRA/PCA — reprise et continuité d’activité

Le PRA vise la reprise après sinistre. Le PCA vise la continuité de service. Le DBA doit relier les architectures de réplication, backup et standby aux besoins métier : perte acceptable de données, durée d’interruption acceptable, priorité des applications.

RPO / RTO

IndicateurDéfinitionExempleImpact architecture
RPOQuantité maximale de données que l’on accepte de perdre.5 minutesWAL/binlog/redo très fréquents, réplication proche temps réel.
RTODurée maximale acceptable avant reprise du service.30 minutesStandby prêt, runbook, DNS/VIP, équipe entraînée.
MTTRDurée moyenne de réparation.45 minutesMesure opérationnelle, amélioration continue.

Matrice PRA/PCA par technologie

MoteurPRA minimalPRA avancéPCA / HA
PostgreSQLBackup physique + WAL archive.Standby distant + PITR.Patroni + HAProxy + replicas.
OracleRMAN + archivelogs externalisés.Data Guard site distant.Data Guard Fast-Start Failover ou RAC selon contexte.
MySQLBackup physique + binlogs.Replica distant + GTID.Semi-sync + orchestrateur/proxy.
MariaDBmariabackup + binlogs.Replica distant ou Galera multi-site prudent.Galera local 3 nœuds + proxy.

Runbook de crise

Phase 1 — qualification

Identifier impact, moteur, instance, symptômes, heure de début, données à risque.

Phase 2 — décision

Choisir restore, switchover, failover, rollback applicatif ou attente.

Phase 3 — exécution

Appliquer procédure validée, tracer actions, informer parties prenantes.

Phase 4 — validation

Contrôles techniques, tests applicatifs, cohérence métier, supervision.

Phase 5 — retour normal

Réintégration ancien primary, rebuild replica, retour DNS/proxy si nécessaire.

Phase 6 — post-mortem

Timeline, cause racine, écarts RTO/RPO, actions préventives.

Erreur à éviter : annoncer un RTO théorique sans l’avoir mesuré lors d’un exercice complet de restauration ou bascule.

16. Check-list entretien et lab de préparation

Pour cette fiche DBA classique, tu dois préparer un discours orienté production : disponibilité, sauvegarde, restauration, réplication, diagnostic, sécurité et méthodes d’exploitation. Il faut aussi savoir poser les bonnes questions.

Lab personnel conseillé

BlocCe que tu dois monterPreuve à montrer
PostgreSQL1 primary, 2 standby, pg_basebackup, WAL archive, PITR.Capture failover manuel + restore PITR.
Patroni3 nœuds Patroni + etcd + HAProxy.Switchover et failover testés.
pgBouncerPool transaction devant PostgreSQL.Comparatif connexions directes vs poolées.
OracleInstance lab, archivelog, RMAN full/incrémental.Restore validate et rapport backup.
MySQL/MariaDBSource + replica GTID, puis semi-sync.SHOW REPLICA STATUS propre et test failover.
Galera3 nœuds Galera.Contrôle quorum, perte nœud, resync IST/SST.

Questions à poser au recruteur

  1. Quels moteurs sont réellement en production et dans quelles versions ?
  2. Les bases tournent-elles sur VM, bare metal, cloud IaaS ou appliance ?
  3. Quels sont les RPO/RTO par application critique ?
  4. Les restaurations sont-elles testées ? À quelle fréquence ?
  5. Quel outil de sauvegarde est utilisé : RMAN, pgBackRest, Barman, XtraBackup, mariabackup ?
  6. Qui décide d’un failover en production ? DBA, astreinte, comité de crise ?
  7. Existe-t-il des runbooks validés et maintenus ?
  8. Quel outil de supervision : OEM, Zabbix, Prometheus, Grafana, Datadog, Dynatrace ?
  9. Les environnements de préproduction permettent-ils de tester les restores ?
  10. Quel est le niveau d’automatisation attendu ? Scripts, Ansible, Terraform, procédures manuelles ?

Réponses fortes à préparer

Sur les backups

“Je considère qu’un backup n’est validé qu’après restauration testée, mesurée et documentée.”

Sur la réplication

“La réplication améliore la disponibilité mais ne remplace jamais une sauvegarde indépendante.”

Sur le failover

“Je distingue switchover planifié, failover de crise et retour arrière. Chaque cas doit avoir son runbook.”

Sur le PRA

“Je relie toujours la solution technique au couple RPO/RTO métier. Sinon, on fait de la technologie sans contrat de service.”

Références utiles à garder en tête

SujetRéférence officielle
PostgreSQL replicationDocumentation PostgreSQL — Runtime replication settings, standby servers, pg_basebackup.
PatroniDocumentation Patroni — HA PostgreSQL with distributed configuration store.
pgBouncerDocumentation pgBouncer — pooling modes and configuration.
Oracle RMANOracle Backup and Recovery User’s Guide.
Oracle Data GuardOracle Data Guard Concepts and Administration.
MySQL replicationMySQL Reference Manual — replication and semisynchronous replication.
MariaDB GaleraMariaDB Galera Cluster documentation.
Conclusion : ce poste est moins “Kubernetes platform” que le précédent, mais il est tout aussi exigeant. Il demande une culture DBA solide : moteur, OS, stockage, réplication, backup, restore, incident, PRA/PCA et communication de crise.