Postgresql pg_standby prend une éternité pour effectuer un basculement

Question

J'ai une configuration d'expédition WAL qui fonctionne avec un serveur esclave de secours chaud appliquant les fichiers WAL. Lorsque je crée le fichier de trigger pg_standby, il le détecte immédiatement, mais il faut environ 10 à 15 minutes pour être prêt à accepter les connexions. La plupart du temps on passe à attendre des fichiers .history.

Le fichier de trigger est vide, un basculement "intelligent" doit donc être effectué. Puis-je faire quelque chose pour accélérer (beaucoup) le basculement?

sortie du journal:

WAL file not present yet. Checking for trigger file... 
trigger file found: smart failover 
LOG: could not open file "pg_xlog/000000010000000000000089" (log file 0, segment 137): No such file or directory 
LOG: redo done at 0/88003428 
LOG: last completed transaction was at log time 2010-08-10 13:26:20.232799+00 
Trigger file  : /psql_archive/role.master 
Waiting for WAL file : 000000010000000000000088 
WAL file path  : /psql_archive/000000010000000000000088 
Restoring to  : pg_xlog/RECOVERYXLOG 
Sleep interval  : 60 seconds 
Max wait interval : 0 forever 
Command for restore : cp "/psql_archive/000000010000000000000088" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 000000000000000000000000 and later 
trigger file found: smart failover 
running restore  : OK 

LOG: restored log file "000000010000000000000088" from archive 
Trigger file  : /psql_archive/role.master 
Waiting for WAL file : 00000002.history 
WAL file path  : /psql_archive/00000002.history 
Restoring to  : pg_xlog/RECOVERYHISTORY 
Sleep interval  : 60 seconds 
Max wait interval : 0 forever 
Command for restore : cp "/psql_archive/00000002.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore  :cp: cannot stat `/psql_archive/00000002.history': No such file or directory 
cp: cannot stat `/psql_archive/00000002.history': No such file or directory 
cp: cannot stat `/psql_archive/00000002.history': No such file or directory 
cp: cannot stat `/psql_archive/00000002.history': No such file or directory 
not restored 
history file not found 
LOG: selected new timeline ID: 2 
Trigger file  : /psql_archive/role.master 
Waiting for WAL file : 00000001.history 
WAL file path  : /psql_archive/00000001.history 
Restoring to  : pg_xlog/RECOVERYHISTORY 
Sleep interval  : 60 seconds 
Max wait interval : 0 forever 
Command for restore : cp "/psql_archive/00000001.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore  :cp: cannot stat `/psql_archive/00000001.history': No such file or directory 
cp: cannot stat `/psql_archive/00000001.history': No such file or directory 
cp: cannot stat `/psql_archive/00000001.history': No such file or directory 
cp: cannot stat `/psql_archive/00000001.history': No such file or directory 
not restored 
history file not found 
LOG: archive recovery complete 
LOG: autovacuum launcher started 
LOG: database system is ready to accept connections 

Merci.

-Dennis

Answer 1

Selon les docs: http://www.postgresql.org/docs/current/static/pgstandby.html

Basculement rapide: une reprise en ligne rapide, le serveur est mis immédiatement. Tous les fichiers WAL de l'archive qui n'ont pas encore été appliqués seront ignorés et toutes les transactions de ces fichiers seront perdues. Pour déclencher un basculement rapide, créez un fichier de trigger et écrivez le mot fast dans celui-ci. pg_standby peut également être configuré pour exécuter un basculement rapide automatiquement si aucun nouveau fichier WAL n'apparaît dans un intervalle défini.

Ou jetez un oeil dans "Tableau F-23, options pg_standby" il y a un maxwaittime décrit.

Vive

Answer 2

En bref, si vous n'utilisez pas pg_standby rapide de basculement continuera à traiter tous les journaux qui sont à gauche (comme il devrait) pour minimiser la perte de données.

Pour vous faciliter la vie, je regarderais PITRTools.