•  
  • slony (4)

Changer l’ IP du serveur sous Slony

Categories: Postgresql, slony
Comments: No Comments
Published on: 14 décembre 2012

Bonjour,

Changer l’ip d’un serveur est loin d’être courant et cela engendre souvent bien des problèmes…

Slony ne sera pas si compliqué à gérer pour ce genre de problème, connaître cette technique est utile si vos serveurs sont dans un Wan (changement FAI, contrat,etc…).

Il y a 2 solutions :

  • Delete de la réplication -> nouvelle réplication
  • Modification du catalogue de la réplication

et c’est cette dernière que je vais décrire brièvement.

Il suffira de se connecter sur les 2 catalogues (maitre et esclave), on ouvre la table sl_path, vous y trouverez quelques chose de ce type dans le champ « pa_conninfo » :

dbname=madb host=192.168.0.10 port=5432 user=slony password=abc

il suffit de changer l’ host par la nouvelle ip, faites cette manipulation sur les 2 serveurs.

On kill les 2 daemons slon et on les relance.

Pensez bien à modifier le .pgpass (si vous l’utilisez)et le pg_hba.

Je fais tout à partir de pgadmin, faisable sans problème en psql depuis le terminal.

Slony 2.0.1 pg 9.1

Problem solved

Slony en WAN ?

Categories: slony
Comments: No Comments
Published on: 2 octobre 2012

Il est peu recommandé d’utiliser Slony sur un réseau étendu ( wan ).
Pourtant ça marche très bien mais sous certaines conditions.

Déjà la stabilité de la réplication dépendra de la ligne, j’ai constaté une grosse différence de stabilité entre le même opérateur.

Ensuite le choix du placement des Daemons slons est primordial.

Sur une infrastructure Lan vous pouvez lancer tous les slons sur le même serveur Maitre pour faire une sorte de gestion administrée, les Slony-ctl fonctionnent comme ça, et dans la plus part des cas c’est très bien.

Mais pourquoi ne pas le faire en Wan ?

2 raisons :

– Si vous avez trop de noeuds, il y aura trop de process sur le Maitre, imaginez 6 serveurs, chacun avec 2 réplications, on est a 12 *2 process sur la machine, on rajoute à ça une gestion des logs par réplication, ça fait beaucoup trop de travail pour le serveur qui doit en plus gérer sa base Postgresql.
En lançant les slons en local, on réparti donc les process et leur travail, et la gestion des logs peut etre affinée.

- Avoir les slons en local permet une meilleure stabilitée, et pas qu’un peu, pour info un serveur avec une ligne adsl moyenne, avec un slon distant plante une fois par jour avec état de zombie et ne se rattrape pas seul ! un redémarrage est obligatoire !
Si le slon est démarré en local, ce même serveur plante une fois par semaine environ (la durée moyenne pour se rattrapper dans mon cas se situe aux alentours de 20min), et se rattrape tout seul !!

Par contre pour démarrer un slon en local n’oubliez pas que le host est le 127.0.0.1 ! et oui car sur un wan c’est l’ip publique que vous voyez ! (hors vpn)

Voilà pour mon petit constat sur slony 2.0.7 en wan ( et oui toujours pas en 2.1 ^^ )

Petit retour sur Slony 2.0.7

Categories: Postgresql, slony
Comments: 2 Comments
Published on: 6 septembre 2011

A priori je suis content… :)

Mon bug était :

Après un arrêt réseau coté maître ou esclave ma réplication reprenait correctement mais pourtant mon écart continuais de monter… donc mon monitoring continuait de crier au secours… un peu relou avec un mail toutes les 10mins…

Et maintenant j’ai testé un arrêt coté slave et une coupure réseau coté maître et tout est revenu nickel après :D

Problème sloved !

Par contre je voudrais dire un grand merci à la personne qui gère www.pgrpms.org, c’est tellement simple de faire un :

yum update slony1-90
/love :p

Et conjugué aux outils slony-ctl c’est du pure bonheur merci à eux.
Après une simple yum sur toutes les machines utilsant la réplication il suffit d’ utiliser le script 42 avec comme argument le nom de la répli et son set :)

Testé et approuvé

Slony passe en 2.0.7

Categories: Postgresql, slony
Comments: No Comments
Published on: 2 août 2011

bonjour,

Juste pour vous informer que slony passe en 2.0.7 et c’est pas plus mal j’espère qu’ils ont réparé le bug qui me tracassait depuis longtemps, à savoir qu’après une coupure la réplication revenait bien mais slony considérait toujours le slave comme hs… bug chiant mais pas préocupant :p

j’éditerais après l’avoir mis en fonction.

Merci aux devs ;)

lien de la release notes

page 1 of 1

Welcome , today is Samedi, 24 juin 2017