Vous n'êtes pas identifié(e).
Bonjour,
J'ai mis en place une réplication avec postgres 9.1 au départ entre deux serveurs : 1 maitre et 1 standby, et j'ai testé hier soir entre 1 maitre et 2 standbys.
Pour cela j'ai fait:
echo "SELECT pg_start_backup('backup', true)" | su postgres -c psql
rsync -avz -e ssh /data/ IP_standby1:/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf --exclude save/ --exclude logs/ --exclude files/ --exclude pg_log/ &&
rsync -a -v -e ssh /data/ IP_standby2:/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf --exclude save/ --exclude logs/ --exclude files/ --exclude pg_log/
echo "SELECT pg_stop_backup()" | su postgres -c psql
Du coup il a synchronisé le premier standby, qui n'est pas sur le même site que le serveur maitre donc il a mis près de 2h-2h30, puis ensuite le deuxième standby, qui est sur même site que le maitre, il a mis 1h.
Est -il mieux de faire c'est deux "rsync" dans la même commande, en parallèle, l'un après l'autre?
Vaut il mieux faire le pg_start_backup, le rsync, le pg_stop_backup pour un standby puis refaire la même chose pour l'autre standby ?
Je me demandais aussi quelle est la méthode pour ajouter 1 standby à un maitre qui possède déjà un standby.
Si on fait le pg_start_backup, il arrête la communication avec son 1er standby déjà mis en place depuis quelques temps?
ou alors il continue normalement avec lui et sait que ce n'est que pour le deuxième standby ?
Je voudrai aussi tester la commande qui est arrivée en 9.1:
pg_basebackup -D /tmp/newcluster -U replication –v
Cette commande évite de faire les 3 commandes "pg_start_backup, le rsync, le pg_stop_backup" d'après ce que j'ai compris.
Elle copie tout le répertoire data de postgres?
Peut on exclure des répertoires ou fichiers?
Car nous avons dans notre "data" des répertoires de sauvegardes, de fichiers qui ne doivent pas être copier sur les standbys (au pire nous ferons des umount de ces répertoires le temps de la copie).
Une dernière question :
est ce que ça sert à quelque chose de compresser nos wall pour les transferts entre serveurs ?
J'ai fait des tests hier et il me semblait que le rsync prenait le même temps avec ou sans l'option "z"...
Merci beaucoup pour vos réponses
Charlotte
Hors ligne
Vaut il mieux faire le pg_start_backup, le rsync, le pg_stop_backup pour un standby puis refaire la même chose pour l'autre standby ?
J'aurais tendance à faire un tar en local (entre le pg_start_backup et le pg_stop_backup), puis d'envoyer le tar sur les deux serveurs.
Je me demandais aussi quelle est la méthode pour ajouter 1 standby à un maitre qui possède déjà un standby.
Comme pour le premier : pg_start_backup, copie, pg_stop_backup, ...
Si on fait le pg_start_backup, il arrête la communication avec son 1er standby déjà mis en place depuis quelques temps?
Non.
ou alors il continue normalement avec lui et sait que ce n'est que pour le deuxième standby ?
Il continue normalement (et se fout de savoir pour qui c'est 
).
Elle copie tout le répertoire data de postgres?
Oui.
Peut on exclure des répertoires ou fichiers?
Non (sauf à modifier son code source, ce qui n'est pas très compliqué).
Car nous avons dans notre "data" des répertoires de sauvegardes, de fichiers qui ne doivent pas être copier sur les standbys (au pire nous ferons des umount de ces répertoires le temps de la copie).
Vous ne devriez pas avoir ça dans le répertoire des données de PostgreSQL, c'est une très mauvaise pratique. PostgreSQL est seul maitre à bord de ce répertoire.
Guillaume.
Hors ligne
Merci guillaume, je vais tenter le tar alors pour le 1er transfert du répertoire data.
Les répertoires ajoutés dans notre 'data' sont des points de montage, donc je pense que je les démonterai (umount"erai") le temps du rsync.
Bon alors je retourne à mes tests!
Hors ligne
J'aurai une petite question technique sur l'ajout d'un Standby :
Mon maitre possède déjà un Standby, il copie chez lui les WAL dans un répertoire "archives_xlog".
Si j'ajoute un Standby :
1-faut il redémarrer postgres sur le maitre pour qu'il prenne en compte les modifications de :
archive_command et max_wal_senders ?
2-On fait le pg_start_backup, ça créé un fichier backup_label, est ce que cela à une influence sur le Standby en cours, par exemple ça le met en pause ?
Car je sais que pour mon 2ème standby la copie de data va prendre 3h....et que je lance ça la nuit, donc je ne ferai la commande pg_stop_backup que 12 heures plus tard.
3-Pendant le pg_start_backup, il commence déjà à envoyer les nouveaux fichiers avec mon archive_command? et quand le 2ème Standby est prêt, il pourra les "avaler"...
4- Mon 2ème standby étant plus lent, il a été très en retard l'autre nuit suite à un reindex du maitre.
J'avais mis le wal_keep_segments à 10, donc quand le Standby est venu 3h après, dire au maitre que pour tel fichier WAL c'était ok, le maitre lui a répondu que c'était déjà supprimé.
Est ce une erreur grave? est ce que cela veut dire que sans la confirmation, le Standby n'a pas fait la maj du WAL ?
Du coup, là j'ai passé le paramètre à 100...
Dernière modification par lolotte35 (07/11/2011 17:04:29)
Hors ligne
2-On fait le pg_start_backup, ça créé un fichier backup_label, est ce que cela à une influence sur le Standby en cours, par exemple ça le met en pause ?
Car je sais que pour mon 2ème standby la copie de data va prendre 3h....et que je lance ça la nuit, donc je ne ferai la commande pg_stop_backup que 12 heures plus tard.
je peux pas répondre à vos questions désolé, mais pourquoi douze heures plus tard ?
Hors ligne
parce que je dois lancer mon start à 18h en partant pour ne pas saturer notre réseau, ainsi que la copie du data (qui met prêt de 3h) , puis je ne lance le stop que le lendemain matin quand je reviens au travail! ça doit faire dans les 12h....
Hors ligne
Pourquoi c'est pas un script .sh qui lance le start backup, la copie et ensuite le stop ?
Hors ligne
Je n'ai jamais fait de script comme ça alors je ne m'y suis pas lancée...
Mais je suis d'accord que pour la mise en production il faudra que je m'y colle...
D'ailleurs j'ai trouvé sur un post un script que je commençais à mettre à ma sauce, mais pas testé encore:
#!/bin/bash
PSQL_BIN=/usr/bin #Binary folder
PSQL_DATA=/data #Folder containing all the configuration files
IP_SLAVE=XXX.XXX.XX.XX
#Initialize standby
service postgresql-9.1 stop
rm -rf /data/pg_*
rm -f /data/postmaster*
rm -rf /data/PG_VERSION
rm -rf /data/base
rm -rf /data/global
rm -rf /data/archives_xlog
sleep 1
cp $PSQL_DATA/postgresql.conf.slave $PSQL_DATA/postgresql.conf
cp $PSQL_DATA/recovery.conf.slave $PSQL_DATA/recovery.conf
echo "Le Standby est pret pour la copie"
sleep 1
$PSQL_BIN/psql postgres -c "select pg_start_backup('backup')"
rsync -a -v -e ssh /$PSQL_DATA/ $IP_SLAVE:/$PSQL_DATA/ --exclude postmaster.pid --exclude postgresql.conf --exclude save/ --exclude logs/ --exclude files/
$PSQL_BIN/psql postgres -c "select pg_stop_backup()"
sleep 1
echo "La copie est finie"
sleep 1
service postgresql-9.1 start
sleep 1
echo "Le standby est actif"
exit 0
Hors ligne
Mais j'aimerai quand même comprendre le mécanisme pour répondre aux questions possibles de la hiérarchie et être sûre pour la mise en prod!
Hors ligne
$PSQL_BIN/psql postgres -c "select pg_start_backup('backup')"
rsync -a -v -e ssh /$PSQL_DATA/ $IP_SLAVE:/$PSQL_DATA/ --exclude postmaster.pid --exclude postgresql.conf --exclude save/ --exclude logs/ --exclude files/
$PSQL_BIN/psql postgres -c "select pg_stop_backup()"
c'est ce que je disais : start backup, rsync, stop backup.
c'est le script que je fais pour mes sauvegardes pitr.
en prod faut oublier le "je ferais ça chaque matin et chaque soir" toujours utiliser le cron et des scripts et le mieux c'est de les tester en test ^^
Dernière modification par kenrio (07/11/2011 17:49:57)
Hors ligne
oui en prod on nele ferai qu'une seule fois, le jour J ensuite normalement y aura pas de problème!
là justement je suis en test donc je tue souvent mes bases et mes réplications pour tout refaire!
Hors ligne
oui en prod on nele ferai qu'une seule fois, le jour J ensuite normalement y aura pas de problème!
là justement je suis en test donc je tue souvent mes bases et mes réplications pour tout refaire!
"avale", "tue" postgres n'est pas une bête sauvage 
Hors ligne
un peu quand même , vu ce que je lui fais faire en ce moment, le pauvre!
Dernière modification par lolotte35 (07/11/2011 17:57:39)
Hors ligne
Pour répondre aux premières questions :
1-faut il redémarrer postgres sur le maitre pour qu'il prenne en compte les modifications de : archive_command et max_wal_senders ?
archive_command, non. max_wal_senders, oui.
2-On fait le pg_start_backup, ça créé un fichier backup_label, est ce que cela à une influence sur le Standby en cours, par exemple ça le met en pause ? Car je sais que pour mon 2ème standby la copie de data va prendre 3h....et que je lance ça la nuit, donc je ne ferai la commande pg_stop_backup que 12 heures plus tard.
Non, ça ne le met pas en pause. Aucun soucis, vous pouvez lancer pg_stop_backup bien plus tard.
3-Pendant le pg_start_backup, il commence déjà à envoyer les nouveaux fichiers avec mon archive_command? et quand le 2ème Standby est prêt, il pourra les "avaler"...
Rien à voir avec le pg_start_backup. L'envoi des journaux se fait dès que le archive_command est configuré.
4- Mon 2ème standby étant plus lent, il a été très en retard l'autre nuit suite à un reindex du maitre. J'avais mis le wal_keep_segments à 10, donc quand le Standby est venu 3h après, dire au maitre que pour tel fichier WAL c'était ok, le maitre lui a répondu que c'était déjà supprimé. Est ce une erreur grave? est ce que cela veut dire que sans la confirmation, le Standby n'a pas fait la maj du WAL ? Du coup, là j'ai passé le paramètre à 100...
Grave... oui, quand même. Faut refaire l'esclave.
Guillaume.
Hors ligne
J'ai testé le pg_basebackup pour éviter de faire le start, le rsync et le stop, mais ce n'est pas possible dans mon cas car mon maitre et mes standby sont sur des serveurs différents et le pg_basebackup croit que l'ip que je lui donne est un répertoire en local!
Je crois que ça ne peut fonctionner que si le maitre et le standby sont sur le même serveur, non?
Hors ligne
Non, pg_basebackup marche parfaitement entre deux machines distinctes. C'est même le but.
Donnez votre ligne de commande, il doit y avoir un problème de ce côté là.
Marc.
Hors ligne
/usr/pgsql-9.1/bin/pg_basebackup -D 192.168.13.36:/data/ -U replication_role –v
J'ai exécuté cette commande sur le maitre
l'ip est celle d'un standby
le répertoire où il doit copier est "/data"
l'utilisateur de réplication est replication_role
Hors ligne
-D 192.168.13.36:/data/ n'est pas le bon format, à moins que vous ayez un répertoire appelé "192.168.13.36:" sur votre machine.
Par contre, la commande pg_basebackup doit être exécutée sur la machine esclave (il faut bien que pg_basebackup puisse écrire). Je présume que c'est ça votre problème ?
(pour préciser le host, le port, l'utilisateur, etc, c'est les options habituelles, -h, -p -U …)
Marc.
Hors ligne
ah donc sur l'esclave je dois faire
/usr/pgsql-9.1/bin/pg_basebackup -D /data/ -U replication_role –v
et il sait tout seul où est son maitre! mais quel homme !
Hors ligne
Non, il ne sait pas tout seul qui est le maître, désolé de vous décevoir
Vous devez lui indiquer le maître avec les options de connexion habituelles (-h, -p, -U). À priori, vous cherchez à faire ça :
/usr/pgsql-9.1/bin/pg_basebackup -h 192.168.13.36 -D le_repertoire_local_ou_installer_l_esclave -U replication_role –v
Guillaume.
Hors ligne
En effet, je suis si déçue!
ok donc sur l'esclave je lance :
/usr/pgsql-9.1/bin/pg_basebackup -h IP_MAITRE -D /data -U replication_role –v
j'essayerai dès lundi, en arrêtant un de mes standbys!
Pour le week end, je vais les laisser se reposer.
Hors ligne
ça fonctionne!
Hors ligne
Cool
Guillaume.
Hors ligne
