Le périmètre Réplication / PRA StackX s’adresse aux productions qui ont besoin d’un serveur ou d’une infrastructure de secours exploitable, d’une réplication pilotée et d’une procédure de bascule réellement préparée.
Le modèle repose sur une architecture PRD / DRS opérée par StackX: un serveur de production, un serveur de reprise, des flux SQL et fichiers cohérents, et un outillage d’exploitation dédié.
Selon le périmètre retenu, StackX peut également gérer une VIP de service (standard sur ScalarCloud), la propagation des environnements répliqués et le contrôle du retour nominal.
Le résultat: un PRA plus opérable, plus documenté et plus vérifiable qu’un simple empilement de scripts ponctuels ou de fichiers YAML.
Pour un besoin centré uniquement sur la sauvegarde et la restauration, voir plutôt Sauvegarde / backup.
Socle Réplication / PRA StackX
| Brique | Rôle |
|---|---|
| Architecture PRD / DRS | Un serveur de production et un serveur de reprise exploités ensemble |
| Réplication SQL | Réplication MariaDB/MySQL bi-directionnelle selon la topologie retenue |
| Synchronisation fichiers | prdsync / drssync pour maintenir docroots, configs et contenus cohérents |
| Bastion d’exploitation | Orchestration des opérations critiques, contrôles et remédiations inter-nœuds |
| VIP de service | Déplacement piloté selon l’architecture quand une IP virtuelle fait partie du périmètre |
Convention de nommage :
Les rôles -prd, -drs, -stg, -dev et -bkp sont détaillés sur la page Conventions StackX.
Lecture par moteur SQLMariaDB, MySQL et PostgreSQL
| Moteur | Mode de reprise |
|---|---|
| MariaDB / MySQL | Réplication applicative selon topologie, réparation outillée et resynchronisation avec source de vérité explicite |
| PostgreSQL | Streaming replication primary / standby, promotion DRS et reconstruction du nœud cible lors du retour nominal |
| Fichiers applicatifs | Synchronisation prdsync / drssync selon le sens opérationnel retenu |
| VIP / IP de service | Déplacement piloté selon l’architecture quand elle le prévoit |
Ce que StackX automatiseContrôles, synchronisation et opérations bastion
| Opération | StackX |
|---|---|
| Initialisation | Bootstrap de réplication et contrôles d’accès inter-nœuds |
| Création d’environnements | Propagation des environnements répliqués PRD -> DRS |
| Contrôle | Vérification des services, de la réplication, des backups et du monitoring via sxpostcheck |
| Préchecks | Validation des rôles, accès, états SQL, synchronisations et prérequis avant toute mutation |
| Verrouillage | Une seule opération mutante par paire PRD / DRS afin d’éviter les exécutions concurrentes |
| Réparation | Resynchronisation pilotée avec source de vérité explicite |
| Failover | Activation du PRA / DRS, gel des flux de synchro et bascule du service selon l’architecture |
| Failback | Réensemencement PRD depuis DRS, rattrapage SQL final, resynchronisation fichiers et retour nominal |
| Activation des synchronisations | Démarrage seulement après validation complète de la réplication et du chemin inter-nœuds |
Quand choisir Réplication / PRA
| Contexte | Intérêt |
|---|---|
| Production critique | Réduire le temps de reprise et éviter l’improvisation en incident majeur |
| Dépendances SQL fortes | Maintenir une cohérence base / fichiers sur un second nœud |
| Contraintes RPO / RTO | Préparer le niveau de reprise avant l’incident |
| Multi-zones / multi-DC | Isoler le secours sur un autre site ou une autre zone |
Points de cadrageRPO, RTO, bascule et validation
| Point | Remarque |
|---|---|
| Périmètre StackX | Certaines fonctions dépendent du périmètre effectivement déployé |
| VIP | La présence d’une VIP n’est pas universelle |
| Failback | Le retour nominal peut impliquer un réensemencement contrôlé du PRD |
| Opération destructive | Le nœud cible et la source de vérité doivent être choisis explicitement avant tout réensemencement |
| PRA | Le bon niveau dépend du RPO, du RTO, des flux applicatifs et du budget accepté |
Besoin d’un périmètre Réplication / PRA cadré proprement ?
Nous définissons l’architecture, les flux, le niveau d’automatisation et les procédures de bascule en fonction de votre production réelle.
Infrastructure
ScalarX conçoit et opère des architectures redondantes, maintenables et évolutives, adaptées aux contraintes de production, au fournisseur choisi et au niveau d’indépendance attendu.
Supervision
ScalarX combine supervision locale, contrôle HTTPS externe et tiers de confiance pour qualifier plus finement les incidents, même sur des architectures distribuées entre plusieurs pays, providers ou datacenters.
Infogérance
ScalarX combine expertise humaine, algorithmes conditionnels et systèmes IA agentiques pour renforcer la fiabilité opérationnelle, détecter les signaux faibles, accélérer les interventions et améliorer la qualité d’exploitation.