SRDF Like – Guide projet IDEO‑LAB

1️⃣ Contrat du projet

• Construire une solution Remote Data Facility Async adaptée à IDEO‑LAB.
• Commencer en DB-first : les bases restent le cœur de la V1.
• Garder une logique SRDF-like, mais modernisée autour d’un pipeline CDC.
• Prévoir une architecture exploitable par une petite équipe, sans usine à gaz dès la phase 1.

2️⃣ Objectifs de niveau de service

3️⃣ Principe directeur

4️⃣ Hypothèses de démarrage

• Deux sites : A primary et B standby.
• Witness / quorum optionnel mais recommandé dès qu’on automatise.
• Failover manuel en V1, puis semi-auto.
• Protection contre erreurs logiques via PITR + base backups.

5️⃣ Message à formaliser dans le CDFC

Le guide n’est pas là pour “faire joli” : il doit verrouiller les invariants de design, éviter les ambiguïtés d’implémentation, et servir de support commun pour toi et tes collègues.

1️⃣ Ce qui est obligatoire en phase 1

• Bases de données : PostgreSQL, MariaDB/MySQL, puis autres moteurs si besoin.
• Métadonnées DR : état réplication, checkpoints, journal, inventaire, état health.
• Observabilité du pipeline : offsets, backlog, erreurs, retries.
• Actioning : déclenchement d’actions sûres depuis le control plane.

2️⃣ Hors scope V1 immédiat

• Object storage / uploads critiques.
• Queues et streams type RabbitMQ / Kafka.
• Caches Redis répliqués “de manière critique”.
• Failback auto complet et non supervisé.

3️⃣ Principe de priorisation

1️⃣ Chaîne cible

2️⃣ Capture

• SQL : WAL / binlog / redo-log selon moteur.
• NoSQL plus tard : oplog / change streams.
• Contrainte : capture idempotente, ordonnée et replayable.

3️⃣ Journalisation

• Stockage local séquentiel par segments.
• Retention contrôlée.
• Checkpoints côté apply.
• Checksum par segment.

4️⃣ Transport

• Protocole fiable avec ACK offset, retry et compression.
• mTLS et authentification obligatoire.
• Backpressure et multi-stream par table / shard / partition.

5️⃣ Apply + Verify

• Apply transactionnel quand possible.
• Rejeu sans doublon.
• DDL vs DML cadré : DDL out-of-band au début.
• Verify par checksum, rowcount et hash sampling.

1️⃣ Mode A – native log shipping

• On envoie le journal natif du moteur au standby.
• Rapide, robuste, performant.
• Excellent choix pour PostgreSQL / MySQL dans un démarrage pragmatique.
• Moins générique, plus dépendant du moteur.

2️⃣ Mode B – logical row-based CDC

• On transporte des événements logiques INSERT / UPDATE / DELETE.
• Plus générique, plus multi-cibles.
• Plus complexe : ordering, drift de schéma, mapping de types.

3️⃣ Recommandation de lancement

4️⃣ Décision projet

1️⃣ Responsabilités du Control Plane

• Inventaire des sites, pairs, agents, DB instances et endpoints.
• Dashboard global : santé, backlog, état de réplication, alertes.
• Runbooks et traces d’orchestration.
• Historique d’actions et décisions opérateur.

2️⃣ Écrans V1 attendus

• Overview cluster / pair.
• Replication state detail.
• Health timeline.
• Action center avec confirmation.

3️⃣ API et logique métier

1️⃣ Métriques minimales

• replication lag (seconds)
• backlog size (bytes / segments)
• throughput capture / transport / apply
• error rate + retry count
• checksum mismatch
• estimated catch-up ETA

2️⃣ États de haut niveau

3️⃣ Alerting V1

1️⃣ Mesures minimales

• mTLS site A ↔ site B.
• Journal local chiffré au repos.
• Rotation des clés / certificats.
• Least privilege sur les comptes CDC et agents.

2️⃣ Split-brain

• Couper l’accès du primary historique avant promotion B.
• Fencing réseau : firewall / security group / ACL.
• VIP / DNS redirigé seulement après fencing validé.

3️⃣ Witness / quorum

Optionnel au tout début, mais fortement recommandé dès qu’on veut aller vers du semi-auto. Son rôle : arbitrer et réduire le risque de double-primary.

4️⃣ Politique sécurité projet

1️⃣ PostgreSQL – priorité absolue

• Physical streaming replication async.
• Lag via pg_stat_replication côté primary.
• Replay delay via recovery functions côté standby.
• PITR via archiving + base backup.

2️⃣ MariaDB – phase suivante

• Brancher après stabilisation du socle V1.
• Conserver le même contrat de health / action / state.
• Éviter de tout abstraire avant d’avoir le premier connecteur vraiment robuste.

3️⃣ Filesync et trafic

• Filesync utile pour fichiers applicatifs hors DB.
• Nginx / proxy / VIP / DNS pour la bascule du trafic utilisateur.
• Ces briques doivent s’intégrer au runbook, pas vivre séparément.

4️⃣ Décision d’implémentation

1️⃣ Plan minimal

• Exercice failover mensuel.
• Test lien coupé 1h avec rattrapage.
• Test corruption logique type DROP TABLE pour valider PITR.
• Mesure RTO/RPO réels et pas théoriques.

2️⃣ Critères de succès

1️⃣ Ce que SRDF Like reprend

• Réplication distante primary / standby.
• Logique de bascule et de reprise sur sinistre.
• Exigence de cohérence opératoire et d’observabilité.

2️⃣ Ce qu’il simplifie

• Approche logicielle ouverte au lieu d’un stack storage propriétaire.
• DB-first et produit “PME / labo / infra pragmatique”.
• Control plane Django lisible plutôt qu’une boîte noire pure infra.

3️⃣ Extensions futures

• Auto-failover encadré par witness.
• Connecteurs multi-moteurs supplémentaires.
• Filesync avancé et cohérence objet.
• Capacity planning et advisor réseau / backlog.
• Policy engine et workflows d’exploitation avancés.

1️⃣ Invariants d’architecture

• same major PostgreSQL version on both sites
• stable endpoint for app traffic
• time sync on both nodes
• fast enough storage for WAL and data on standby

2️⃣ Succès du POC

• standby connected
• replay delay low when idle
• manual promote works
• dashboard shows lag / backlog / state