PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Backup/Replication : sites distants => site central)

Technique - général | Backup/Replication : sites distants => site central)

Par eric.laforce le 13/11/2007 - 08:23

Bonjour

Je recherche une solution "simple" pour faire du backup/replication en asynchrone d'un server principal vers un serveur de secours.

BESOINS = Avoir sur un site central, un backup journalier de la base de données applicative principale de 23 sites différents.

CONTRAINTES/SPECIFICITES
1) Taille base de données de chaque site ~250Go
2) Connexions WAN entre les sites distants et le site central
3) Chaque jour, seul un faible volume de données est mis à jour ou ajouté
=> une solution de type replication asynchrone me semblait peut etre adaptée ?

Jusqu'a présent je travaillais en dump compressé + transfert WAN
- => pas optimum et ne fonctione pour l'instant qu'en alternant chaque les sites pour limiter la taille des transfert.

J'ai regardé rapidement la description de quelques outils de réplication pour POSTGRES mais sans en trouver un qui semble simple et adapaté à ma situation.
Toute suggestion mĂŞme autre que la replication est la bienvenue (diff de dump, ...)
=> je n'ai trouvé pour l'instant d'autres solutions.

Je vous remercie par avance pour vos conseils ou indications.
ERIC

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Quelques pistes...

Jean-Paul Argudo/ = 13 Novembre, 2007 - 11:28

Bonjour Eric,

Avez-vous pensé à la technique du Warm Standby? Si vous avez une version antérieure à la 8.1 je vous incite à passer à la 8.2 pour bénéficier de cette technologie.

Nous l'avons mise en place chez plusieurs de nos clients, et il s'avère que c'est très stable et robuste.

Dans votre cas, cela se traduirait par avoir un (ou plusieurs) serveurs PostgreSQL en stand-by sur le site central qui hébergerai(en)t les 23 bases.

Cette technologie, pour peu que tous les serveurs des 23 sites accèdent au site central sans difficulté, vous permettrait d'assurer une continuité de service pour vos clients. Si l'un des 23 serveurs tombait, la base en stand-by sur le site central est prête à prendre le relais, très rapidement, avec une perte d'informations minime.

Vous pouvez aussi pratiquer la réplication des journaux de transaction, qui nécessitera une sauvegarde de la base (les fichiers, pas un dump, qui est un export), à chaud ou à froid, puis la recopie des fichiers WAL. Cette technologie est disponible depuis la 8.1, et se nome Archivage continu et récupération d'un instantané (PITR).

Mais là encore, une perte d'information est possible en cas de crash du serveur maître.

Si vous voulez (ou devez) absolument ne perdre qu'une infime partie des informations en cas de crash (les toutes dernières transactions), peut-être vous devrez finalement utiliser Slony-I. Cependant, cette technologie est plus complexe que les précédentes, et nécessite un approfondissement particulier de votre part. À moins que vous n'ayez la bonne idée d'opter pour une formation Slony...

Quoi qu'il en soit, toutes ces méthodes vont vous imposer d'avoir 6 To de stockage côté site central. Vous pourrez les répartir sur plusieurs serveurs, bien sûr, ou sur un SAN/NAS...

J'espère que ces pistes vous permettront d'avancer dans la résolution de votre problématique.

Cordialement,

--
Jean-Paul ARGUDO
http://dalibo.com | http://dalibo.org


Précisions

SAS/ = 16 Novembre, 2007 - 13:47

Bonjour,

Souhaitez-vous disposer d'une solution de secours de chaque base (chaque base étant donc dupliquée), ou d'une consolidation de toutes les bases sur un même serveur.

Ce serveur doit-il être accédé ?

S'agit-il de 23 bases identiques ? Le serveur principal ne sert-il que de serveur de sauvegardes ?

Souhaitez-vous bénéficier d'une solution de reprise sur incident ? D'une sécurisation matérielle ou des données ?

Quelle est la fenêtre de perte des données acceptable ?

À chaque cas va pouvoir s'appliquer une solution différente.

Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr


© PostgreSQLFr, tous droits rĂ©servĂ©s.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.