Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Comme j'ai déjà eu l'occasion de l'évoquer dans un autre thread, nous utilisons activement PostgreSQL dans le cadre de services Web à fort traffic. Nous observons chaque jour plusieurs milliers de connexions (environ 6000 simultanément) , et nous utilisons de plus en plus de fonctions "avancées" de PostgreSQL, sur des bases de plus en plus volumineuses. Je réfléchis donc depuis un certain temps à des solutions de répartition de charge. Si, de surcroît, on peut y intégrer des solutions de haute disponibilité, ce serait la cerise sur le gâteau, mais ce n'est pas l'objectif premier, la disponibilité actuelle de notre serveur PostgreSQL étant déjà plus que satisfaisante.
Après plusieurs réflexions et échanges sur ce forum, voici l'état actuel de ma réflexion. Le principe général serait de mettre en place une réplication maitre/esclaves avec des esclaves accessibles en lecture seule, les applications demandant beaucoup plus de lectures que de modifications des données. Pgpool II serait utilisé en tant que pooler et "dispatcheur" des requêtes vers les différents serveurs, via son option "Load balancing". En ce qui concerne l'aspect réplication, après moultes hésitations, je partirais vers Slony-I. En effet, ce projet semble être un des plus anciens et des plus matures. J'avais déjà effectué quelques tests et, à vrai dire, je n'en gardais pas un très bon souvenir, non pas à cause d'un éventuel manque de fiabilité, mais à cause de la relative complexité de mise en oeuvre, et surtout à cause des implications concernant les modifications ultérieures du schéma de la base répliquée.
J'ai attentivement relu l'article consacré à Slony-I dans le HS de Linux Mag sur PostgreSQL, et j'y ai découvert l'existance du projet Slony-ctl, qui semble offrir des scripts facilitant grandement la mise en oeuvre et la maintenance de l'ensemble. J'ai cependant quelques questions, que je me permets de vous soumettre.
-Peut-on faire cohabiter plusieurs versions de Slony et de PostgreSQL dans un seul système. En effet, mon idée serait de préparer un noeud esclave en PostgreSQL 8.4, mon serveur actuel étant en 8.3, puis de mettre en place une réplication du maitre 8.3 vers l'esclave 8.4. Une fois les données répliquées, je promouvrai l'esclave en tant que maitre, ce qui me permettrait alors d'arrêter le maitre 8.3, le temps de l'upgrader en 8.4. Une fois l'opération effectuée, je le configurerais en tant qu'esclave du 2ème serveur. Une fois les données mises à jour, je pourrais alors "switcher" de façon à ce que le serveur redevienne maitre. Vous l'aurez compris, l'objectif est de pouvoir migrer le serveur PostgreSQL actuel de la version 8.3 vers la version 8.4 sans interrompre le service.
-Pour faciliter les modifications ultérieures de la base, je pensais installer un deuxième "petit" pgPool en mode réplication, qui ne serait utilisé que par notre équipe de développement, lors des modifications de schémas. De la sorte les schémas de l'ensemble des serveurs seraient toujours identiques. Il ne me resterait qu'à ajouter les ressources au "set" répliqué par Slony. Le script "slony_addobj.sh" semble indiqué pour cet usage.
-Toujours en ce qui concerne les modifications de schéma (nous sommes en perpétuels développements, et il peut donc être amené à être modifié relativement souvent), si j'ai bien compris, lorsque l'on modifie une table (par exemple ajout d'une colonne), cela a pour effet d'arrêter la réplication tant que la modification n'a pas été reportée sur les noeuds esclaves. Une fois ceux-ci mis à jour, la réplication reprend automatiquement là ou elle était rendue. C'est bien cela ?
-En cas d'ajouts d'objets (tables, fonctions, schémas,...) , je viens de l'évoquer, un appel à "slony_addobj.sh" devrait suffire.
-En cas de suppression d'objets, le script "exec_dropobj.sh" semble tout-à-fait indiqué. Que se passe-t-il si on omet de l'appeler ? Slony va-t-il simplement l'ignorer (après tout, il ne risque plus d'y avoir de modification sur une table qui n'existerait plus), ou cela va-t-il geler la réplication. Je suppose en effet que le principal problème proviendrait au cas où un esclave serait promu maitre, et essayerait donc à nouveau de répliquer une table disparue sur l'autre serveur.
-Enfin, est-il aisé de supprimer une réplication et tous les éléments associés ? Suffit-t-il de supprimer le schéma créé par Slony ou il-y-a-t-il de nombreuses autres manipulations à effectuer. L'idée derrière cette question est de ne pas m'empêcher de basculer du système de réplication de Slony vers celui que ne manquera pas de proposer PostgreSQL 8.5 (vivement cette version !!!)
Voila, un long message et de nombreuses questions. Par avance, merci de l'attention qui vous pourrez y porter.
Cordialement,
Jérôme
PS: L'article sur Slony du HS de LinuxMag précisait qu'à l'heure où il avait été écrit, Slony n'était pas encore compatible avec PostgreSQL 8.4. A priori, la version 1.2.16 apporte cette compatibilité, d'où mes interrogations sur la possibilité de l'utiliser pour upgrader mes serveurs sans interruption de service.
Hors ligne
-Peut-on faire cohabiter plusieurs versions de Slony et de PostgreSQL dans un seul système.
En fait dans ta question, ce que tu veux c'est faire cohabiter 2 versions de postgres différentes dans un même cluster slony. C'est tout à fait possible, c'est même un des cas d'utilisation de slony : la migration de version postgres presque sans interruption de service. Par contre effectivement il te faut une version compatible 8.4.
-"Pour faciliter les modifications ultérieures de la base"
Là je suis moins sûr, mais aux dernières nouvelles, il fallait absolument faire passer les modifications de schema par slony, pour qu'il les applique au même 'moment' (au niveau transactionnel) sur tous les noeuds. Ou bien je n'ai pas compris la question.
-Enfin, est-il aisé de supprimer une réplication et tous les éléments associés ?
Il faut désinstaller slony des bases (un slonik uninstall node de mémoire) si tu veux dire arrêter complètement la réplication, ou faire un drop set si c'est juste pour un jeu de tables que tu ne veux plus répliquer.
Marc.
Hors ligne
Peut-on faire cohabiter plusieurs versions de Slony et de PostgreSQL dans un seul système
Oui. C'est même fait pour que ça marche. Attention à bien changer le numéro de port du deuxième serveur PostgreSQL. Attention que si vous faites cela, les performances seront forcément dégradées le temps de la synchronisation.
je pensais installer un deuxième "petit" pgPool en mode réplication
Je ne vois pas très bien comment cela pourrait fonctionner. Toutes les requêtes vont être répliquées, autant celles de modification de schéma que celles de modifications de données. Ce qui va mettre un beau bazar sur vos bases si Slony essaie de faire de même. Pouvez-vous expliquer plus en détails ce que vous voulez faire ?
si j'ai bien compris, lorsque l'on modifie une table (par exemple ajout d'une colonne), cela a pour effet d'arrêter la réplication tant que la modification n'a pas été reportée sur les noeuds esclaves. Une fois ceux-ci mis à jour, la réplication reprend automatiquement là ou elle était rendue. C'est bien cela ?
Slony ne pourra plus répliquer vers la table modifiée. Cela provoquera des erreurs sur le serveur secondaire. Je ne pense pas que ce soit une bonne façon de procéder. Utilisez plutôt le script Perl slonik_execute_script (script AltPerl) ou le script Bash 42_exec_exec.sh (script slony1-ctl).
un appel à "slony_addobj.sh" devrait suffire
Il faut utiliser les scripts numérotés. Comme Stéphane, le développeur des scripts, me l'a expliqué, les fichiers sans numérotation doivent plutôt être vus comme des bibliothèques de fonctions. Donc, dans ce cas précis, il faut utiliser 11_create_addobj.sh puis 12_exec_addobj.sh.
En cas de suppression d'objets, le script "exec_dropobj.sh" semble tout-à-fait indiqué.
Même topo 
Dans ce cas, il s'agit plutôt de 111_create_dropobj.sh puis de 112_exec_dropobj.sh.
Qu'on soit bien d'accord. Peut-être est-ce clair pour vous, mais j'avoue ne pas arriver à savoir en vous lisant. slony1-ctl ne s'occupe que de la suppression de la table dans la configuration des tables répliquées. Donc ça ne supprime pas la table elle-même. Ça la supprime de la liste des tables à répliquer. Du coup, il faut d'abord exécuter ces scripts puis un 42_exec_exec.sh avec le script SQL "DROP TABLE...".
Que se passe-t-il si on omet de l'appeler ?
Slony tentera toujours de répliquer cette table, ce qui générera un bon paquet de messages d'erreurs dans les logs de Slony. Mais il n'y aura pas de gel de la réplication.
Enfin, est-il aisé de supprimer une réplication et tous les éléments associés ?
Vous arrêtez les démons, et vous supprimez le schéma Slony. C'est une façon assez sale de le faire mais ça fonctionne bien.
Si vous ne voulez supprimer la réplication d'un nœud, c'est possible aussi.
la version 1.2.16 apporte cette compatibilité
Non, il s'agit de la 1.2.17. Cette version est sortie récemment, le 14 octobre pour être précis, donc bien après la parution de cet article. Cependant, il existe deux bugs, spécifiques à la 8.4, dans cette version qui peuvent s'avèrer assez gênants.
Guillaume.
Hors ligne
Là je suis moins sûr, mais aux dernières nouvelles, il fallait absolument faire passer les modifications de schema par slony, pour qu'il les applique au même 'moment' (au niveau transactionnel) sur tous les noeuds.
Pas forcément, mais il est vrai que c'est la façon la plus propre.
Guillaume.
Hors ligne
Pages : 1
