Il y a forcément un moment où une info se perd même si c'est commité toutes les demi-secondes ou même "instantanément". Une coupure en plein milieu d'un commit et réplication entre base... Et hop incohérence. C'est ici que s'arrête mon "expertise" :D
C'est la qu'il faut utiliser les termes RTO (Recovery Time Objectif) et RPO (Recovery Point Objectif) en gros le temps d'arrêt max que tu veux atteindre (RTO) et le volume de données que tu peu te permettre de perdre (RPO)
Et ce en cas d'incident grave touchant l'entreprise ou le système informatique ( incendie inondation etc ... )
Exemple : dans le domaine bancaire RTO = 1h d'arrêt d'exploitation et RPO = rien pas de perte de données
Mais cela coute cher ...
Attention cela ne dispense pas de faire des sauvegardes car si une transaction est une bêtise elle sera aussi dupliquée ...
Il y a quelques temps ... en règle général dans une entreprise "classique" peut se permettre 1/2 journée d'arrêt avec environ 15mn à 1/2h de perte de données.
Mais cela nécessitait un double environnement informatique avec STANDBY DB de chez ORACLE
Un équivalent du coté SQL SERVER de chez M$ existe aussi
Après quelques rechreches : Coté POSTGRESQL apparement cela s'appelle le PITR Point in Time recovery
Si des personnes avisées pouvaient decrire le processus avec des mots simples sur ce forum cela serait sympa ...
[^] # Re: CEPH c'est bien mais ...
Posté par Christophe B. (site web personnel) . En réponse au journal Proxmox et le HA. Évalué à 2.
Salut ! ;)
C'est la qu'il faut utiliser les termes RTO (Recovery Time Objectif) et RPO (Recovery Point Objectif) en gros le temps d'arrêt max que tu veux atteindre (RTO) et le volume de données que tu peu te permettre de perdre (RPO)
Et ce en cas d'incident grave touchant l'entreprise ou le système informatique ( incendie inondation etc ... )
Exemple : dans le domaine bancaire RTO = 1h d'arrêt d'exploitation et RPO = rien pas de perte de données
Mais cela coute cher ...
Attention cela ne dispense pas de faire des sauvegardes car si une transaction est une bêtise elle sera aussi dupliquée ...
Il y a quelques temps ... en règle général dans une entreprise "classique" peut se permettre 1/2 journée d'arrêt avec environ 15mn à 1/2h de perte de données.
Mais cela nécessitait un double environnement informatique avec STANDBY DB de chez ORACLE
Un équivalent du coté SQL SERVER de chez M$ existe aussi
Après quelques rechreches : Coté POSTGRESQL apparement cela s'appelle le PITR Point in Time recovery
Si des personnes avisées pouvaient decrire le processus avec des mots simples sur ce forum cela serait sympa ...