Re: réplication wal : restore, boot, restore ?

Bonjour,

je cherche à mettre en place une réplication de données Master-Slave sur un
postgresql 8.4 (Debian squeeze). Après une étude rapide de l'existant mon
choix se porte sur l'utilisation des WAL (je dois pouvoir répliquer les
changements de structure de données facilement).
Aussi, j'ai réalisé plusieurs tests dont le dernier avec walmgr qui propose
une mise en oeuvre simple et rapide. (Merci à Dalibo pour sa doc :
http://www.dalibo.org/hs44_la_replication_par_les_journaux_de_transactions )

L'objectif de cette réplication n'est pas d'avoir une sauvegarde des
données, mais de pouvoir interroger le slave en lecture seule 2 à 3 heures
par jour. Aussi, après avoir initialisé le cluster sur le slave, lancé le
serveur en mode recovery et constaté que tout fonctionne je m'interroge sur
un point. Je sors du mode recovery, je me connecte à la base et je réalise
quelques requêtes en lecture seule sur les données répliquées (objectif de
départ) avec succès.
Comment reprendre ensuite le fil de l'exploitation des WAL ?
Est-ce tout simplement possible ?
La réponse à la deuxième commande "walmgr slave.ini restore" me laisse
penser qu'il faut également reprendre la procédure de backup du cluster ...
(l'intérêt de la réplication deviendrait alors limité).

Merci de me confirmer les possibilités d'utilisation de la réplication WAL
par rapport à ce besoin.
Faut-il passer par un autre fichier wal-slave.ini ? par une recopie du main
(slave) dans main.shippedxlog (slave) avant de relancer ?

Merci pour vos réponses éventuelles,

Bien cordialement

Lionel

Quelques infos sur ma config

Réponse de la commande restore à la reprise :

postgres(at)testreplication:~$ walmgr /etc/postgresql/8.4/main/wal-slave.ini
restore
2012-08-29 14:40:58,242 11370 INFO Move
/var/lib/postgresql/8.4/main.shippedxlog/data.master to
/var/lib/postgresql/8.4/main
2012-08-29 14:40:58,242 11370 CRITICAL Job replica_walmgr_slave crashed:
<type 'exceptions.OSError'>: '[Errno 2] No such file or directory'
(<traceback object at 0x2287488>: [' File
"/usr/lib/pymodules/python2.6/skytools/scripting.py", line 510, in
run_once\n return self.work()\n', ' File "/usr/bin/walmgr", line 1051,
in restore_database\n os.rename(full_dir, data_dir)\n'])

Contenu du wal-slave.ini :

[wal-slave]
job_name = replica_walmgr_slave
logfile = ~/log/wal-slave.log
use_skylog = 0

slave_data = /var/lib/postgresql/8.4/main
slave_stop_cmd = /etc/init.d/postgresql stop
slave_start_cmd = /etc/init.d/postgresql start

slave = /var/lib/postgresql/8.4/main.shippedxlog
completed_wals = %(slave)s/logs.complete
partial_wals = %(slave)s/logs.partial
full_backup = %(slave)s/data.master

keep_backups = 1
archive_command =

Contenu du wal-master.ini :

[wal-master]
job_name = raplication_walgmr_master
logfile = /var/lib/postgresql/log/wal-master.log
use_skylog = 0

master_db = dbname=postgres
master_data = /var/lib/postgresql/8.4/main
master_config = /etc/postgresql/8.4/main/postgresql.conf

slave_config = /etc/postgresql/8.4/main/wal-slave.ini
slave = slavehost:/var/lib/postgresql/8.4/main.shippedxlog

completed_wals = %(slave)s/logs.complete
partial_wals = %(slave)s/logs.partial
full_backup = %(slave)s/data.master
file_target = %(slave)s/files.master

# syncdaemon update frequency
loop_delay = 10.0
# use record based shipping available in 8.2
use_xlog_functions = 0

# periodic sync
#command_interval = 600
#periodic_command = /var/lib/postgresql/walshipping/periodic.sh

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 29/08/2012 14:50, LionelB a écrit :
> Bonjour,
>
> je cherche à mettre en place une réplication de données Master-Slave sur
> un postgresql 8.4 (Debian squeeze). Après une étude rapide de l'existant
> mon choix se porte sur l'utilisation des WAL (je dois pouvoir répliquer
> les changements de structure de données facilement). Aussi, j'ai réalisé
> plusieurs tests dont le dernier avec walmgr qui propose une mise en oeuvre
> simple et rapide. (Merci à Dalibo pour sa doc :
> http://www.dalibo.org/hs44_la_replication_par_les_journaux_de_transactions
> )
>
> L'objectif de cette réplication n'est pas d'avoir une sauvegarde des
> données, mais de pouvoir interroger le slave en lecture seule 2 à 3 heures
> par jour. Aussi, après avoir initialisé le cluster sur le slave, lancé le
> serveur en mode recovery et constaté que tout fonctionne je m'interroge
> sur un point. Je sors du mode recovery, je me connecte à la base et je
> réalise quelques requêtes en lecture seule sur les données répliquées
> (objectif de départ) avec succès. Comment reprendre ensuite le fil de
> l'exploitation des WAL ? Est-ce tout simplement possible ? La réponse à la
> deuxième commande "walmgr slave.ini restore" me laisse penser qu'il faut
> également reprendre la procédure de backup du cluster ... (l'intérêt de la
> réplication deviendrait alors limité).
>
> Merci de me confirmer les possibilités d'utilisation de la réplication WAL
> par rapport à ce besoin. Faut-il passer par un autre fichier wal-slave.ini
> ? par une recopie du main (slave) dans main.shippedxlog (slave) avant de
> relancer ?
>
> Merci pour vos réponses éventuelles,
>
> Bien cordialement
>
> Lionel

Bonjour,

A priori, l'objectif du hot standby est justement de repartir rapidement en
cas de crash du maître, en repassant l'esclave en mode autonome.

Il n'est pas prévu que ce nœud de secours soit utilisé pour de la lecture.

C'est justement l'idée de l'esclave en lecture seule apparu en 9.0, ou des
outils de réplication de type Slony/Londiste qui permettent de requêter
l'esclave.

La propagation des modifications des schémas n'est pas à ce point compliqué
avec ces outils.

D'autre part, PG 8.4 est-il une obligation incontournable dans le cadre de ce
projet ?

Meilleures salutations,
- --
Stéphane Schildknecht
http://www.Loxodata.com
Contact régional PostgreSQL
http://bistri.me/sas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA+NrYACgkQA+REPKWGI0GbnwCeK5S5BQdk+j7Qg5K7fAj/fHvT
jNUAoKokpUlWZDBxrtxVb41HcXLraT38
=wn24
-----END PGP SIGNATURE-----

Le 29/08/2012 17:35, "Stéphane A. Schildknecht" a écrit :
> Bonjour,
> A priori, l'objectif du hot standby est justement de repartir rapidement en
> cas de crash du maître, en repassant l'esclave en mode autonome.
>
> Il n'est pas prévu que ce nœud de secours soit utilisé pour de la lecture.
>
> C'est justement l'idée de l'esclave en lecture seule apparu en 9.0, ou des
> outils de réplication de type Slony/Londiste qui permettent de requêter
> l'esclave.
>
> La propagation des modifications des schémas n'est pas à ce point compliqué
> avec ces outils.
>
> D'autre part, PG 8.4 est-il une obligation incontournable dans le cadre de ce
> projet ?
>
> Meilleures salutations,
> - --
> Stéphane Schildknecht
> http://www.Loxodata.com
> Contact régional PostgreSQL
> http://bistri.me/sas
Bonjour,

Le passage à une version supérieure de PG est à l'étude mais
l'indisponibilité de certains modules en debian stable (postgis) pour
cette version de PG pose encore quelques difficultés.
Par contre c'est surement la direction à suivre pour répondre au besoin
de réplication et de requêtes en lecture seule pour ce projet.
Merci pour votre réponse.
Cordialement

Lionel

LionelB <lionel(dot)bargeot(at)gmail(dot)com> writes:
> Comment reprendre ensuite le fil de l'exploitation des WAL ?
> Est-ce tout simplement possible ?

Non.

Plusieurs solutions s'offrent à vous. Je privilégierais, comme Stéphane,
l'étude d'une migration à PostgreSQL 9.1. Réaliser le backport de
PostGIS pour debian est relativement simple, et je travaille à un projet
d'hébergement complet des package debian pour toutes les versions
stables de PostgreSQL, cela devrait bientôt être disponible et répondre
à vos besoins.

Une autre option consiste à faire un snapshot du système de fichiers
afin de pouvoir revenir en arrière après exploitation de l'esclave, ou
bien une copie complète du base backup le plus récent et des fichiers
WAL archivés jusque là, à placer dans le pg_xlog de la copie avant de
démarrer l'instance éphémère.

N'hésitez pas à nous solliciter,
--
Dimitri Fontaine 06 63 07 10 78
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Le 31/08/2012 12:00, Dimitri Fontaine a écrit :
>
> Plusieurs solutions s'offrent à vous. Je privilégierais, comme Stéphane,
> l'étude d'une migration à PostgreSQL 9.1. Réaliser le backport de
> PostGIS pour debian est relativement simple, et je travaille à un projet
> d'hébergement complet des package debian pour toutes les versions
> stables de PostgreSQL, cela devrait bientôt être disponible et répondre
> à vos besoins.
Excellente nouvelle !
Pour tout dire, il existe déjà un backport de postgresql-9.1-postgis
pour squeeze ici.
http://rodolphe.quiedeville.org/debian/
Seulement le saut de version que nous devons réaliser a un impact sur
les processus de développement de l'application en cours. Il ne peut se
faire sans une vérification complète et du coup, repousse les échéances
de mise en place de serveurs répliqués. Le changement de PG 8.3 à 8.4
m'incite à être prudent sur ce point.

> Une autre option consiste à faire un snapshot du système de fichiers
> afin de pouvoir revenir en arrière après exploitation de l'esclave, ou
> bien une copie complète du base backup le plus récent et des fichiers
> WAL archivés jusque là, à placer dans le pg_xlog de la copie avant de
> démarrer l'instance éphémère.
>
> N'hésitez pas à nous solliciter,
Bon, je crois que nous allons travailler sur le passage en 9.1 , ca nous
économisera quelques heures de scripting.
Merci pour vos réponses
Cordialement
Lionel