Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
pour tester la réplication avec postgres, j'aurais voulu utiliser notre serveur de dvpt comme standby.
Il y a très peu de màj en production (pour l'instant), donc la charge ne devrait pas être un problème.
Mais je me demande s'il est possible d'avoir une base de dvpt et une base de secours (du serveur de prod) au même endroit.
Faut-il lancer 2 serveurs pg ?
L'acces à la base de prod est dans recovery.conf, mais je ne vois pas comment le standby sait quelle est la base de secours ?
Des variables quelque part ? Ou la réplication se fait-elle au niveau du cluster ? Je n'ai pas encore tout bien compris...
Hors ligne
Bonjour,
la réplication interne de postgres se faisant sur l'instance entière, vous devrez configurer 2 serveurs sur la même machine. Cela se fait très bien, veillez juste à bien configurer la mémoire pour ne pas dépasser la quantité disponible et changer le port sur le nouveau serveur.
Et donc pour votre 2ème question comme dit plus haut c'est l'instance entière qui est répliquée, pas le choix dans les bases.
Dernière modification par rjuju (27/06/2012 01:25:58)
Julien.
https://rjuju.github.io/
Hors ligne
Merci beaucoup pour cet éclaircissement.
Hors ligne
Ca marche ! J'ai ajusté shared_buffers pour les 2 clusters afin de ne pas épuiser les petits 2 Go du serveur de dvpt.
postgres@ks3001539:~$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
postgres 14272 0.2 0.6 170412 12432 ? S 22:37 0:01 /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/secours -c config_file=/etc/postgresql/9.1/secours/postgresql.conf
postgres 14273 0.4 0.1 170468 3224 ? Ss 22:37 0:03 postgres: startup process recovering 000000010000000B00000013
postgres 14274 0.0 0.1 170396 2648 ? Ss 22:37 0:00 postgres: writer process
postgres 14275 0.0 0.0 95628 1680 ? Ss 22:37 0:00 postgres: stats collector process
postgres 14296 0.2 1.3 513604 27732 ? S 22:38 0:01 /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf
postgres 14342 0.0 0.2 513792 5028 ? Ss 22:38 0:00 postgres: writer process
postgres 14343 0.0 0.0 513800 1688 ? Ss 22:38 0:00 postgres: wal writer process
postgres 14344 0.0 0.1 514776 3256 ? Ss 22:38 0:00 postgres: autovacuum launcher process
postgres 14345 0.0 0.0 95780 1996 ? Ss 22:38 0:00 postgres: stats collector process
postgres 14414 0.0 0.1 175396 3404 ? Ss 22:39 0:00 postgres: wal receiver process streaming B/13A53988
Hors ligne
Bonjour,
la réplication fonctionne parfaitement, mais je me pose des questions sur les procédures de reprise.
1) Le master ne fonctionne plus ==> je crée le fichier trigger sur le slave, qui est du coup promu nouveau master
2) Du temps se passe durant lequel des transactions ont lieu sur le secours
3) le master est prêt à redémarrer : que faire pour récupérer les transactions passées sur le secours ?
Configurer l'ancien master en standby, récupérer le répertoire data du secours, démarrer, puis le promouvoir comme maître ?
Je suis en 9.1.4 sur 2 serveurs Ubuntu 12.04 .
Merci de votre aide
Hors ligne
Il faut reconstruire le data de l'ancien master. Si vous avez la possibilité, le plus rapide serait surement un pg_start_bckup, rsync du data du nouveau maître puis pg_stop_backup. Si la taille de la base n'est pas trop importante, vous pouvez utiliser pg_basebackup sur l'ancien master qui reconstruira entièrement le data pour vous.
Julien.
https://rjuju.github.io/
Hors ligne
3) le master est prêt à redémarrer : que faire pour récupérer les transactions passées sur le secours ?
Il faut qu'il soit esclave du secours, ce qui lui permettra de récupérer les transactions manquantes. Ensuite, il faudra basculer sur lui, et reconstruire l'esclave. Dans ce genre de condition, un coup de rsync est souvent bien plus efficace qu'un pg_basebackup, étant donné le peu de données à rejouer sur la machine qu'on veut remonter comme esclave, alors que quelques secondes auparavant elle était maître.
Marc.
Hors ligne
Merci à vous deux, je ferai une simulation de crash un de ces soirs.
Hors ligne
Bonsoir,
En cherchant une solution d'automatisation du passage en mode secours (création du fichier failover), je suis tombé sur pgpool-II
et pgpooladmin . Connaissez-vous ces outils et sont-ils adaptés :
- pour faire du load balancing (select sur le secours)
- pour passer en secours sans intervention humaine ?
D'après le wiki, la version 3.2 encore en développement comprend un watchdog, ce qui était ma recherche initiale.
SInon, j'ai vu heartbeat, mais ça a l'air démesuré par rapport à mes besoins.
Hors ligne
En théorie, oui. En pratique, pgpool est assez sensible à mettre en œuvre, on y rencontre fréquemment des bugs, surtout quand on essaye de mixer plusieurs modes: répartition de requête+failover par exemple.
Marc.
Hors ligne
Si je laissais tomber le load balancing pour l'instant, que serait la solution la plus simple
pour créer automatiquement le fichier trigger en cas de défaillance du master ?
J'avais imaginé un shell dans crontab toutes les x mn, qui essaie de se connecter à la base de prod et crée
le fichier trigger en cas d'échec (+ envoi mail avec ssmtp). Qu'en pensez-vous ?
Hors ligne
Vous voulez faire un trigger pour empêcher les mise à jour si le fail over a été effectué ?
autant mettre slony 
Hors ligne
Si, à la moindre mini-coupure réseau, vous provoquez un "promote" de l'esclave, vous n'avez pas fini de reconstruire votre esclave 
heartbeat peut être une solution, mais j'avoue avoir peu confiance dans les solutions automatisées.
Guillaume.
Hors ligne
je suis d'accord avec Gleu, des fois il vaut mieux que tout soit gérer par l'homme ^^
Hors ligne
Vous me conseilleriez plutôt de me contenter d'envoyer un mail ?
Pour l'instant, voici mon script :
#!/bin/sh
DATE=$(date +%Y-%m-%d-%H-%M)
msg=" $DATE Base xxxx sur xx.xx.xx.xx ne répond pas"
rm -f /var/lib/postgresql/prod_ok.log
psql -h xx.xx.xx.xx xxx -f test_live.sql -q -o prod_ok.log
if grep -q "?column?" /var/lib/postgresql/prod_ok.log
then
echo "$DATE : Prod OK"
else
echo "$DATE : Prod en panne"
echo $msg|ssmtp xx@xx.fr xx@xx.fr
touch /var/lib/postgresql/9.1/secours/failover
fi
Le script sql fait juste select 1 .
Hors ligne
et un vrai serveur de monitoring ?
Hors ligne
Pour l'instant la société est en pleiin démarrage, je cherche une solution simple et peu coûteuse,
quitte à faire quelques compromis. Dans quelques mois, avec la montée en charge (et les rentrées financières correspondantes ),
nous pourrons faire mieux. Pour ma culture personnelle, un serveur de monitoring serait dédié à la surveillance du bon fonctionnement
du serveur de production ? Ce n'est pas un peu lourd ? Qu'est-ce que ça ferait de mieux que mes 10 lignes de script ?
Hors ligne
Pour ma culture personnelle, un serveur de monitoring serait dédié à la surveillance du bon fonctionnement
du serveur de production ?
Oui, mais avec un seul serveur dans votre cas, ce n'est pas vraiment intéressant.
Ce n'est pas un peu lourd ?
Pas quand on a plusieurs serveurs à superviser. Quand on en a un ou deux, c'est un peu trop. Il vaut mieux dans ce cas installer munin.
Qu'est-ce que ça ferait de mieux que mes 10 lignes de script ?
Surveiller des tas d'autres problématiques que la simple indisponibilité d'un serveur.
Guillaume.
Hors ligne
bah un serveur de monitoring, ça check tout ce que vous lui demandez, postgres, cpu, dd, ram, ... envois de mail, avec des modules des sms, ça envois pas sur une erreur, mais sur un certain nombre, donc pas d'envois de mails pour rien...
Mais le script vous le mettez sur quel serveur ?
après c'est vrai que pour 2 serveurs ça fait beaucoup, mais un admin système doit savoir faire ça
Dernière modification par kenrio (06/07/2012 10:54:51)
Hors ligne
Le script tourne sur le dvpt.
Pour l'instant nous avons 2 serveurs : dvpt et prod . J'ai mis le cluster de secours sur le serveur de dvpt
pour l'instant, mais c'est plus une démonstration de faisabilité qu'un vrai secours.
Il est prévu d'avoir un serveur dédié vers la rentrée, la montée en charge va se faire entre la fin juillet et début septembre.
Je suis de mon côté en pleine autoformation sur PostgreSQL et Ubuntu, en espérant être à la hauteur le moment venu.
Vivement qu'on ait besoin de 30 serveurs avec réplication en cascade !
Hors ligne
Je serais parti sur un centos avec un postgresql 9.1 à ta place.
Ubuntu pour du serveur c'est pas le mieux.
Hors ligne
Pour l'instant ça marche nickel, et il y a postgresql 9.1.4 sur les deux.
Quelles sont les limitations/problèmes de Ubuntu 12.04 en serveur ?
Hors ligne
Perso je préfère centos pour ça liaison avec red hat tout simplement, chez HP ils font souvent des drivers pour redhat donc qui fonctionnent avec Centos.
Après je suppose que c'est une histoire de gout et de réputation.
pour le postgresql je confondais avec un autre topic en 8.4.
Hors ligne
Il n'y a pas eu vraiment d'étude scientifique pour le choix de l'OS . Les développeurs connaissaient Ubuntu, j'ai un lourd passé OpenVMS/RDB .
En cherchant un peu j'ai vu que le dvpt avait l'air dynamique sur Ubuntu, alors que centos est en standby pendant des mois
lorsqu'une nouvelle RHEL sort. Le projet d'entreprise se veut novateur et sans cesse remis en question pour bénéficier de
nouvelles technologies, ça m'a semblé coller. Ca fait 6 mois maintenant, et je me sens assez à l'aise avec Ubuntu, plus
trop envie de changer .
Hors ligne
Pages : 1
