Postgres HA (basé sur WAL-expédition) échoue

J'espère que quelqu'un peut m'aider un problème WAL-expédition et de secours chaud. Mon système de secours tourne heureusement pendant des semaines, puis tout d'un coup il commence à chercher des fichiers .history qui n'existent pas. Il craps puis et je ne peux pas le redémarrer avec succès sans reconstruire la veille.Postgres HA (basé sur WAL-expédition) échoue

Les deux systèmes exécutent CentOS 4.5 et postgres 8.4.1. Ils utilisent NFS pour stocker les fichiers WAL de production en veille.

Un morceau correspondant du journal, avec mes commentaires:

[** Recovery is running normally **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001000000830000005B 
WAL file path   : /var/tafkan_backup_from_db1/00000001000000830000005B 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 00000001000000830000004D and later 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
running restore   : OK 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001000000830000005B 
WAL file path   : /var/tafkan_backup_from_db1/00000001000000830000005B 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 000000000000000000000000 and later 
running restore   : OK 

[** All of a sudden it starts looks for .history files **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000002.history 
WAL file path   : /var/tafkan_backup_from_db1/00000002.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
not restored 
history file not found 
Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001.history 
WAL file path   : /var/tafkan_backup_from_db1/00000001.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
not restored 
history file not found 

[** I stopped Postgres, renamed recovery.done to recovery.conf, and restarted it. **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000002.history 
WAL file path   : /var/tafkan_backup_from_db1/00000002.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
not restored 
history file not found 
Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 0000000200000083000000A2 
WAL file path   : /var/tafkan_backup_from_db1/0000000200000083000000A2 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/0000000200000083000000A2" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 000000000000000000000000 and later 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 

[** This file is not present. All WAL files start with 00000001. **]

Toutes les idées? Je ne sais même pas ce que sont les fichiers .history, et la documentation (surtout excellente) n'est pas très claire sur tout ça.

PS. Je voudrais exécuter des machines virtuelles afin que je puisse utiliser link text et ne pas avoir à se soucier de ce non-sens HA de niveau application :-)

Mise à jour: Voici quelques-uns des journaux du serveur de secours à ce moment. Il semble que quelque chose ait fait que le serveur arrête de se rétablir et se connecte, mais je ne sais pas quoi. Je suis à peu près certain que rien n'aurait pu créer le fichier trigger.

2010-01-20 03:30:15 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005A" from archive 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005B" from archive 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: record with zero length at 83/5BFA2FF8 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: redo done at 83/5BFA2FAC 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: last completed transaction was at log time 2010-01-20 03:28:04.594399-05 
2010-01-20 03:30:25 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005B" from archive 
2010-01-20 03:30:37 EST 4b3a5c63.401b LOG: selected new timeline ID: 2 
2010-01-20 03:30:49 EST 4b3a5c63.401b LOG: archive recovery complete 
2010-01-20 03:30:59 EST 4b3a5c62.4019 LOG: database system is ready to accept connections

Source

2010-01-20 sbleon

salut sbleon, je veux juste sauvegarder les fichiers WAL à un autre emplacement, je n'ai pas besoin de veille, pouvez-vous aider ?? –

@indyaah, vérifiez [les excellents documents PostgreSQL] (http://www.postgresql.org/docs/) pour votre version. – sbleon

merci pour le copain d'aide. !! : D –

J'ai pu résoudre ce problème en mettant à jour les systèmes d'exploitation CentOS sur mes deux serveurs PostgreSQL. Par conséquent, je pense que c'était un symptôme d'un bug réseau sous-jacent de quelque sorte.

Source

2011-08-02 17:17:06 sbleon

Une approche totalement différente pour HA pourrait être d'accueillir la base de données PG sur un périphérique DRBD partagé entre les deux machines.

Source

2010-01-20 15:19:12

Merci pour la suggestion! C'est probablement ce que je ferai si je n'arrive pas à faire fonctionner WAL-shipping de manière fiable. – sbleon

Avez-vous utilisé votre propre script/programme de récupération? Si oui, ne le faites pas s'il vous plaît. Utilisez pg_standby de PostgreSQL contrib.

Sinon, ignorez simplement les fichiers .history.

Source

2010-01-20 15:32:00

J'utilise pg_standby. recovery.conf contient: "restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger/var/tafkan_backup_from_db1% f% p% r 2 >> standby.log'". Je ne peux pas ignorer les fichiers .history car lorsque pg_standby commence à les rechercher, la récupération échoue, recovery.conf est déplacé vers recovery.done et les fichiers WAL commencent rapidement à s'accumuler. – sbleon

Votre copie répliquée est entrée en ligne à un moment donné. "00000002.history" recherche un fichier d'historique pour le scénario 00000002, tandis que le reste de vos journaux commence par 00000001, qui correspond au scénario d'origine.

Je vérifierais vos journaux PostgreSQL juste avant de commencer à chercher le fichier d'historique pour voir si la base de données est en ligne, même pour un instant.

Source

2010-01-21 00:09:04

Merci, Matthew. J'ai ajouté quelques-uns des journaux à ma question. Vous avez raison de dire que quelque chose l'a mis en ligne, mais je ne peux pas imaginer quoi, ni pourquoi. – sbleon

Est-ce que quelque chose s'est passé du côté de la source? L'entrée "enregistrement avec une longueur nulle à 83/5BFA2FF8" ressemble à un journal WAL partiel qu'il a essayé de restaurer. IIRC, lorsqu'il rencontre un enregistrement invalide dans la WAL, il revient au dernier enregistrement * good * de ce WAL, puis se connecte, indépendamment de l'existence d'un fichier de trigger. Je regarderais les deux journaux de systèmes autour de 2010-01-20 03: 28: 04.594399-05 et voir s'il y avait des erreurs dans Postgres, le système d'exploitation, ou le réseau. –

Ce comportement a du sens. Si Backup voit quelque chose qui ressemble à un échec de Primary, il suppose que Primary est mort et qu'il devrait prendre le relais. Je soupçonne qu'il peut y avoir un problème de réseautage ici. Je vais regarder dans cet angle. Merci! – sbleon

Postgres HA (basé sur WAL-expédition) échoue

Répondre

Questions connexes