web-dev-qa-db-fra.com

Comment puis-je résoudre le problème postgresql après avoir supprimé les fichiers wal?

J'ai activé archive_mode sur ma configuration postgresql pour tester un serveur de sauvegarde. Et puisque les fichiers wal prenaient beaucoup d'espace disque, après mon test, je l'ai désactivé et j'ai également supprimé les fichiers wal. Lorsque j'ai essayé de redémarrer postgresql, j'ai eu l'erreur suivante.

 root@hooshang:/etc/postgresql/9.1/main# /etc/init.d/postgresql restart
 * Restarting PostgreSQL 9.1 database server
 * The PostgreSQL server failed to start. Please check the log output:
 2014-10-16 13:15:28 IRST LOG:  database system was shut down at 2014-10-15 15:51:53 IRST
 2014-10-16 13:15:28 IRST LOG:  could not open file "pg_xlog/00000001000007DC00000037" (log file 2012, segment 55): No such file or directory
 2014-10-16 13:15:28 IRST LOG:  invalid primary checkpoint record
 2014-10-16 13:15:28 IRST LOG:  could not open file "pg_xlog/00000001000007DC00000029" (log file 2012, segment 41): No such file or directory
 2014-10-16 13:15:28 IRST LOG:  invalid secondary checkpoint record
 2014-10-16 13:15:28 IRST PANIC:  could not locate a valid checkpoint record
 2014-10-16 13:15:28 IRST LOG:  startup process (PID 17467) was terminated by signal 6: Aborted
 2014-10-16 13:15:28 IRST LOG:  aborting startup due to startup process failure

Comment puis-je résoudre ce problème?

postgresqlpostgresql-9.1backupcheckpointwrite-ahead-logging
6
Sina

Vous avez corrompu votre base de données en supprimant manuellement les fichiers du répertoire de données. Ne jamais supprimer manuellement des fichiers du répertoire de données.

Retirer WAL en toute sécurité

Si vous souhaitez supprimer WAL, laissez le serveur le faire à CHECKPOINT heure, ou tilisez pg_archivecleanup . Notez que le serveur supprimera WAL dont il n'a plus besoin automatiquement, sauf:

  • archive_mode est activé, mais archive_command échoue, donc le serveur continue de réessayer les tentatives d'archivage jusqu'à ce qu'elles réussissent ou que l'administrateur intervienne;
  • Il est toujours conservé par wal_keep_segments
  • (en 9.4) Il est toujours nécessaire par un slot de réplication.

Si aucun de ces éléments ne s'applique, un CHECKPOINT (automatique ou émis manuellement via SQL) supprimera tous les WAL qui ne sont pas actuellement requis. Vous n'avez donc pas à le supprimer à la main.

Dans des circonstances inhabituelles, vous devrez peut-être utiliser pg_archivecleanup, comme si vous manquez d'espace disque en raison de l'accumulation de WAL après que l'archivage a échoué pendant une longue période. Vous pouvez décider d'accepter que vous devrez recréer vos réplicas à la suite de la suppression du WAL dont ils ont encore besoin et utiliser pg_archivecleanup pour libérer de l'espace pour faire fonctionner le maître.

Mais vous ne devez jamais supprimer les segments WAL à la main.

Récupération avec WAL archivé

Si vous avez conservé le WAL archivé ailleurs, vous pourrez peut-être simplement recopier les fichiers dans pg_xlog, ou créez un recovery.conf avec un restore_command faire cela. Voir le manuel sur PITR et l'expédition des journaux pour plus de détails.

Récupération sans WAL archivé

Si vous n'avez pas de copie de ces fichiers WAL ailleurs, vous devez restaurer à partir d'une sauvegarde si vous avez une sauvegarde récente, car vous avez corrompu votre base de données.

Si vous n'avez pas de sauvegarde, suivez les instructions de la page wiki de corruption et seulement une fois que vous avez fait une copie complète de l'état actuel de la base de données , en dernier recours , utilisez pg_resetxlog pour supprimer les journaux de transactions et forcer la base de données à démarrer avec des transactions incomplètes.

Vous devez alors pg_dump la base de données, arrêtez-la, initdb une nouvelle, et restaurez-la. Ne pas continuer à utiliser la base de données que vous avez endommagée. Jamais continuez à utiliser une base de données que vous avez utilisée pg_resetxlog on, et ne l'utilisez jamais qu'en dernier recours.

18
Craig Ringer