Erreur de sauvegarde à chaud de PostgreSQL 9.1: le système de base de données démarre
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 le service postgresql-9.1 restart ou /etc/init.d/postgresql-9.1 restart commandes. Après avoir reçu cette erreur, je tue tous les processus et essaie à nouveau de redémarrer la base de données et de recevoir toujours 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 de l'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\
--exclude postmaster.pid
pgsql -c "select 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 à l'aide de: /Usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data /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 veille mode Journal: fichier journal restauré "logFileName" à partir de l'archive Journal: état de récupération cohérent atteint à 0/BF0000B0 Journal: la reprise démarre à 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 s'est correctement connectée au 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é.
Le message "Le système de base de données démarre." n'indique pas une erreur. La raison pour laquelle il est au niveau FATAL est qu'il se rendra toujours dans le journal, quel que soit le paramètre de log_min_messages:
Après la rsync, avez-vous vraiment exécuté ce que vous montrez?:
pgsql -c "sélectionnez pg_stop_backup ();";
Puisqu'il n'y a, pour autant que je sache, aucun exécutable pgsql, qui laisserait la sauvegarde inachevée, et l'esclave ne sortirait jamais du mode de récupération. D'un autre côté, vous avez peut-être vraiment exécuté psql, car sinon je ne vois pas comment l'esclave aurait enregistré des messages de réussite tels que:
Journal: état de récupération cohérent atteint à 0/BF0000B0
et:
Journal: la réplication en streaming s'est correctement connectée au Principal
Avez-vous essayé de vous connecter à l'esclave à ce stade? Qu'est-il arrivé?
Le message "Success. You can now start ..." que vous mentionnez est généré par initdb, qui ne doit pas être exécuté dans le cadre de la configuration d'un esclave; donc je pense que vous pouvez être confus à propos de quelque chose là-bas. Je suis également préoccupé par ces déclarations apparemment contradictoires:
La seule façon dont j'ai redémarré Postgres consiste à utiliser les commandes de redémarrage postgresql-9.1 ou /etc/init.d/postgresql-9.1. Après avoir reçu cette erreur, je tue tous les processus et j'essaie à nouveau de redémarrer la base de données ...
Avez-vous essayé d'arrêter le service via le script de service? Qu'est-il arrivé? Il peut être utile de comprendre les journaux si vous préfixez des lignes avec plus d'informations. Nous utilisons:
log_line_prefix = '[%m] %p %q<%u %d %r> '
Le recovery.conf le script semble étrange. Copiez-vous à partir du répertoire pg_xlog du maître, du répertoire pg_xlog actif de l'esclave ou d'un répertoire d'archives?
J'ai également eu quelques problèmes avec cela, sauf que j'étais en 9.3, pas en 9.1. Quoi qu'il en soit, le correctif s'est avéré assez trivial:
Le fichier postgresql.conf Était en cours de copie du maître vers l'esclave, et je le laissais inchangé sur l'esclave. Je pensais que tout ce que vous aviez à faire était d'ajouter un fichier recovery.conf Et tout fonctionnerait (eh bien oui, mais je ne pouvais pas me connecter au serveur esclave répliqué, mais il était en cours de réplication).
J'ai édité le fichier postgresql.conf De l'esclave et:
- a commenté le
archive_mode=on - commenté la commande
archive; et - commenté
hot_standby=on
Cela l'a fait: j'ai pu obtenir que la base de données soit un serveur en lecture seule prêt à accepter des requêtes en lecture seule.
Il existe un script appelé pg_basebackup Qui créera le répertoire bootstrap pour l'esclave. Il s'agit du répertoire de données contenant la base de données. Vous devez modifier le postgresql.conf avant de pouvoir être utilisé comme esclave comme décrit, quelque chose d'assez simple pour un script post pg_basebackup.
Fait intéressant, j'ai résolu le problème de la manière opposée à celle de Paul.
J'ai ajouté:
hot_standby = on
ou plutôt changé #hot_standby = off à ce qui précède. (Cela utilisait 9.5)
Je l'ai obtenu dans les journaux:
MSK FATAL: the database system is starting up
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:
pg_resetxlog.exe -D ../Data -f
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.