Vous n'êtes pas identifié(e).
Bonjour à tous,
Pour un projet interne à ma société, nous utilisons la solution Jive SBS et Postgres comme DB, dans sa version 8.4 sous RHEL 5.5 64 bits.
Dans la mesure où l'application est assez sensible, elle requiert une haute dispo et pour ce faire, je comptais mettre en place une réplication entre ma base maitre dans un datacenter vers une base esclave dans un autre datacenter (nous possédons les deux datacenters et avons une interconnexion).
L'idée est que si le datacenter de PROD tombe, alors on peut rétablir le service sur le datacenter hébergeant les envts de Préprod/PRA.
Pour un autre projet géré par un partenaire, je sais que la solution Slony est utilisée pour la réplication.
Les questions que je me pose (j'avoue d'office que je suis novice concernant postgres, j'ai plutôt un passé orienté MySQL) :
- Slony I 1.x vs Slony I 2.x : de ce que je lis sur ce forums, la version 2.x est plutôt déconseillée. Est-ce toujours le cas ?
- Dans la documentation de Slony I 2.x, il est mentionné un certain nombre de limitations, est-ce aussi valable pour la version 1.x (http://www.slony.info/documentation/2.0 … tions.html)
- Quels sont les points à vérifier sur mon schema pour décider de la meilleure solution de réplication ?
- D'un point de vue infra, j'ai deux solutions : soit je monte un serveur de PRA et un de PREPROD et dans ce cas, chacun héberge sa base indépendemment. La réplication se faisant alors de la PROD vers le PRA. Soit je mutualise le serveur et héberge les deux bases avec pour le coup une réplication complète de la base de PROD vers la base de PRA (mais sans perturber la base de PREPROD voisine).
Merci d'avance pour vos lumières,
Nicolas
Hors ligne
a/ La version 2.x est de plus en plus stable, même si la version 1.x reste la plus couramment utilisée.
b/ Les limitations de la 2.x sont les mêmes que pour la 1.x. Il est important de comprendre que tous les changements de schémas de la base devront être fait via des scripts Slonik. Slony implique une surcharge de travail et de maintenance qui ne doit pas être négligée.
c1/ Vérifier que vous n'utilisez pas de blob ou de champs binaires
c2/ Vérifier que le schéma de la base est figé
d/ Sans plus d'information, il est difficile de vous orienter entre les deux solutions...
Au final, réfléchissez bien avant de vous tourner vers Slony c'est un logiciel très puissant qui demande beaucoup d'attention et ajoute une couche de complexité à votre infrastructure.
Si votre but est simplement d'avoir un serveur de secours en cas de crash du serveur principal, alors la mise en plase du Warm Standby est beaucoup plus simple et largement suffisante. Voir l'article si dessous pour un tutoriel complet :
Réplication War Standby :
http://www.dalibo.org/hs44_la_replicati … ansactions
Et pour info, la doc de Slony est disponible en français là : http://www.slony.fr/
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Merci pour ce retour.
Je lisais en parallèle les articles sur dalilbo.org - très instructifs !
Si je fais des grep sur mon schema à la recherche des mots clés "binary, bin, blob", j'ai juste des champs de type "bytea"
Je me renseigne en parallèle auprès de l'éditeur de la solution pour avoir une vision plus clair sur les modifications de schémas.
Hors ligne
Pour avoir un panel complet des différentes solutions de HA avec PostgreSQL, voir les slides d'une conférence que j'ai donné : http://www.dalibo.org/haute_disponibili … postgresql
Guillaume.
Hors ligne
Bonjour Nicolas,
La version 2.0 de Slony apporte un peu plus de souplesse à la réplication. Elle évite notamment d'avoir à poser un verrou exclusif sur 'ensemble des tables participant à la réplication lors d'une modification de schéma.
Il n'y a aucune difficulté à répliquer des champs bytea.
Concernant l'administration de la réplication, si ton choix se porte sur Slony, tu peux envisager d'utiliser des outils d'administration tels que les outils perl inclus dans le package officiel, ou slony-ctl (http://pgfoundry.org/projects/slony1-ctl/).
Ces outils facilitent l'administration quotidienne de la réplication.
Concernant les points à vérifier, il ne s'agit pas que de considération de schéma.
En version 8.4, seuls slony, bucardo, londiste et pgpool te permettront d'avoir un accès en lecture (voir en écriture pour bucardo) sur tes réplicats.
Slony est le seul qui te permette de faire de la réplication en cascade (PROD -> PRA -> PréPROD), et de repartir sur la PRA maître en cas de perte de la PROD.
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Merci pour vos retours et désolé pour mon temps de réponse...
Vu que les modifications de schéma sont assez ponctuelles, slony est envisageable. Le choix entre Warm Standby ou Slony se fera suivant nos contraintes d'hébergement je pense. Je vais essayer de pousser le Warm Standby pour s'éviter des contraintes 
Merci à tous les trois !
Nicolas
PS : et un coucou à SAS en mémoire d'une entreprise commune en 2004 ;-)
Hors ligne
