Je travaille sur une sauvegarde à chaud pour Postgres 9.1 depuis un certain temps et j'ai rencontré un problème cohérent. Après avoir redémarré Postgres sur le serveur esclave, le fichier journal pgstartup et le fichier journal quotidien sous le répertoire pg_log sont lus sans erreur. Cependant, lorsque j'essaie d'entrer dans la base de données à l'aide de la commande psql, j'obtiens l'erreur:
FATAL: le système de base de données démarre.
Le fichier recovery.conf ne se transforme pas non plus en recovery.done. J'ai fait des recherches approfondies sur cette erreur et trouve toujours la même réponse: la base de données n'a pas été correctement fermée avant d'essayer de redémarrer Postgres. La seule façon dont j'ai redémarré Postgres est via les commandes service postgresql-9.1 restartou /etc/init.d/postgresql-9.1 restart. Après avoir reçu cette erreur, je tue tous les processus et j'essaie à nouveau de redémarrer la base de données tout en recevant la même erreur. Je ne sais pas où aller à partir d'ici et comment résoudre ce problème. Vous trouverez ci-dessous le processus exact que j'ai effectué pour terminer la sauvegarde à chaud.
Configurations du serveur maître:
pg_hba.conf, a ajouté la ligne:
réplication d'hôte postgres IPAddressOfSlaveServer trust
postgresql.conf:
wal_level = hot_standby max_wal_senders = 5 listen_address = '*' port = 5432 max_wal_senders = 5 wal_keep_segments = 32
Configurations du serveur esclave:
postgresql.conf:
hot_standby = on
recovery.conf:
standby_mode = on primary_conninfo = host = IPAddressOfMasterServer port = 5432 user = postgres restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'
Après avoir configuré les deux serveurs
Je passe à l'utilisateur postgres sur le serveur maître et exécute les commandes:
psql -c "Sélectionnez pg_start_backup ('label', true);";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data esclave: /var/lib/pgsql/9.1/data \
--exclure postmaster.pid
pgsql -c "sélectionnez pg_stop_backup ();";
Après la synchronisation de la base de données avec le serveur esclave
Je redémarre le serveur esclave et le démarrage n'échoue pas. Le pgstartup.log se lit comme suit:
Succès. Vous pouvez maintenant démarrer le serveur de base de données en utilisant:
/usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
ou
/usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l démarrage du fichier journal
le fichier journal du jour, postgresql-Thu.log, se lit comme suit:
Journal: arrêt Journal: le système de base de données est arrêté Journal: le système de base de données a été arrêté lors de la récupération le 2012-4-10 Journal: entrée en mode veille Journal: fichier journal "logFileName" restauré à partir de l'archive Journal: état de récupération cohérent atteint à 0 / BF0000B0 Journal: le rétablissement commence à 0 / BF000020 Journal: fichier journal "logFileName" restauré à partir de l'archive Journal: pageaddr inattendu 0/85000000 dans le fichier journal 0, segment 192, décalage 0 Journal: pageaddr inattendu 0/85000000 dans le fichier journal 0, segment 192, décalage 0 Journal: la réplication en streaming est correctement connectée au serveur principal
J'ai recherché des pageaddr inattendus et des archives postgres, je crois comprendre que c'est tout à fait normal et l'un des moyens attendus pour détecter la fin de WAL.
Tout avis serait grandement apprécié.
la source
Fait intéressant, j'ai résolu le problème de la manière opposée à celle de Paul.
J'ai ajouté:
hot_standby = onou, plutôt, changé
#hot_standby = offà ce qui précède. (Cela utilisait 9.5)la source
Je l'ai obtenu dans les journaux:
Pour corriger le démarrage infini du serveur, procédez comme suit: Arrêtez le service (s'il existe), supprimez le processus «postgres» (il existe généralement). Exécutez ceci dans la console:
Cette utilisation apparaît car le répertoire xLog contient des données qui ne doivent pas être écrites avant l'arrêt du service. Et puis au démarrage du service, il essaie de corriger ces données. Parfois, il gèle le démarrage et ne se termine jamais. La commande au nettoyage nettoie ces données non fixées, qui appliquent le service pour commencer avec des données fixes uniquement. Peut-être que certaines parties des données non fixées seront perdues, mais le serveur de base de données fonctionnera normalement et sera accessible par les applications.
la source