Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Réplication » PG_STANDBY » 29/05/2009 11:59:33
20672 ? Ss 0:00 postgres: startup process waiting for 00000004000000000000001C
20679 ? S 0:00 sh -c /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00020680 ? S 0:00 /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00000000021611 ? Ss 0:00 sshd: root@pts/2on dirais qu'il attend apres ce fichier...
Comment je peux faire car ce fichier n'est pas dans le repertoire (j'ai du l'effacer)
Tu crois que je dois recommencer du debut?
Bonjour
Je viens de m'inscrire puisque en ce moment je fais des tests de réplication et après différents essais
j'ai constaté le comportement suivant :
Au début tout fonctionne, nous avons les segments WAL de type 00000001000000000000001C
qui sont bien recopié sur le SLAVE et bien pris en compte
Et nous avons bien le process
sh -c pg_standby -d -t /tmp/stoprestore /var/postgresl/backup_wals/ 00000001000000000000001C
Puis quand on arrête le RECOVERY par le fichier /tmp/stoprestore
Le serveur sur SLAVE devient autonome, la base de donnée devient accessible
Des segments WALL apparaît dans pg_xlog avec pour nom 00000002000000000000001C (Incrémentation du TimeLineID)
Un 2 apparaît à la place du 1
Du coup quand on arrête la base de donnée, on remet recovery.conf et on relance la base de donnée en mode recovery
j'ai le process suivant :
sh -c pg_standby -d -t /tmp/stoprestore /var/postgresl/backup_wals/ 00000002000000000000001C
Le SLAVE ne peut plus synchronisé puisqu'il attend 00000002... alors que le Master continue à envoyer les 00000001...
Remède:
La seule solution que j'ai trouvé est de réinitialiser le SLAVE à chaque fois que l'on veut redémarrer le mode RECOVERY
Si la base est volumineux, on peut utiliser sync -a pour recopier le delta du MASTER vers le SLAVE
Pages : 1