Que fait pg_resetxlog ? Et comment fonctionne-t-il ?

Question

J'ai consulté la documentation de postgres et le synopsis ci-dessous est donné :

pg_resetxlog [-f] [-n] [-ooid ] [-x xid ] [-e xid_epoch ] [-m mxid ] [-O mxoff ] [-l timelineid,fileid,seg ] datadir

Mais à aucun moment la documentation n'explique ce qu'est le datadir. S'agit-il du %postgres-path%/9.0/data ou pourrait-il s'agir %postgres-path%/9.0/data/pgxlog ?

De même, si je veux changer de répertoire xlog, puis-je simplement déplacer les éléments dans mon répertoire actuel de xlog ? pg_xlog et exécuter la commande pour pointer vers un autre répertoire ? (Supposons que mon répertoire pg_xlog actuel se trouve dans /data1/postgres/data/pg_xlog ET le répertoire dans lequel je veux que les logs aillent est le suivant : /data2/pg_xlog )

La commande suivante permettrait-elle d'obtenir ce que je viens de décrire ?

mv /data1/postgres/data/pg_xlog /data2/pg_xlog
pg_resetxlog /data2

Answer 1

pg_resetxlog est un outil de dernier recours pour faire fonctionner à nouveau votre base de données :

• Vous avez supprimé des fichiers que vous n'auriez pas dû supprimer de pg_xlog ;

• Vous avez restauré une sauvegarde de niveau système de fichiers qui omettait l'option pg_xlog à cause d'une erreur de configuration du système de sauvegarde (cela arrive plus souvent qu'on ne le pense, les gens se disent "il y a log dans le nom, donc ça ne doit pas être important, je vais le laisser en dehors des sauvegardes").

• Une corruption du système de fichiers due à une défaillance matérielle ou à une panne du disque dur a endommagé votre répertoire de données.

• un bogue de PostgreSQL ou du système d'exploitation a endommagé les journaux d'écriture (extrêmement rare).

Comme le dit le manuel :

pg_resetxlog efface le journal d'écriture (WAL) [...]. Cette Cette fonction est parfois nécessaire si ces fichiers ont été corrompus. Cette fonction est parfois nécessaire si ces fichiers ont été corrompus. Elle ne doit être utilisée qu'en dernier recours, lorsque le serveur ne démarre pas. à cause d'une telle corruption.

Ne pas courir pg_resetxlog à moins que vous ne sachiez exactement ce que vous faites et pourquoi vous le faites . Si vous n'êtes pas sûr, posez la question sur le site Liste de diffusion pgsql-general ou sur https://dba.stackexchange.com/ .

pg_resetxlog peut corrompre votre base de données comme l'indique la documentation. Si vous devez l'utiliser, vous devez REINDEX Pour ce faire, vous devez vidanger votre ou vos bases de données, réinitialiserdb et recharger vos bases de données. Ne continuez pas à utiliser le cluster endommagé. Selon la documentation :

Après avoir exécuté cette commande, il devrait être possible de mais gardez à l'esprit que la base de données peut contenir des données incohérentes en raison de transactions partiellement engagées. Vous devez immédiatement vidanger vos données, exécuter initdb et recharger. Après le rechargement, vérifiez les incohérences et réparez-les si nécessaire.

Si vous souhaitez simplement déplacer le répertoire de votre journal d'écrasement vers un autre emplacement, vous pouvez le faire :

• Arrêter PostgreSQL
• Déplacer pg_xlog
• Ajouter un lien symbolique de l'ancien emplacement vers le nouvel emplacement
• Démarrer PostgreSQL

Ou, comme le dit le la documentation dit :

Il est préférable que le journal soit situé sur un disque différent de celui de l'application fichiers de la base de données principale. Ceci peut être réalisé en déplaçant le répertoire pg_xlog à un autre endroit (pendant que le serveur est arrêté, bien sûr) et en créant un lien symbolique à partir du répertoire ori. bien sûr) et en créant un lien symbolique à partir de l'emplacement d'origine dans le répertoire de données vers le nouvel emplacement.

Si PostgreSQL ne démarre pas, c'est que vous avez fait quelque chose de mal. N'utilisez pas pg_resetxlog pour le "réparer". Annulez vos modifications et déterminez ce que vous avez fait de mal.

Answer 2

Déplacez le contenu de votre répertoire pg_xlog vers l'emplacement souhaité, par exemple '/home/foo/pg_xlog'.

mv pg_xlog/* /home/foo/pg_xlog

Supprimer le répertoire pg_xlog

rm -rf pg_xlog

Créer un soft-link de pg_xlog

ln -s /home/foo/pg_xlog pg_xlog

Vérifier le lien

ls -lrt pg_xlog

Note : pg_resetxlog n'est pas le bon outil pour déplacer le pg_xlog.

http://www.postgresql.org/docs/9.2/static/app-pgresetxlog.html

Answer 3

Le répertoire de données correspond au répertoire data_directory dans le fichier postgresql.conf, ou l'entrée PGDATA et il peut également être interrogé en direct en SQL avec la variable d'environnement SHOW data_directory déclaration. Elle ne renvoie pas à la pg_xlog mais un niveau au-dessus.

Pour modifier l'emplacement des fichiers WAL, le serveur PG doit être arrêté, l'option pg_xlog et son contenu déplacés vers le nouvel emplacement, un lien symbolique doit être créé de l'ancien emplacement vers le nouveau, et le serveur doit être redémarré. pg_resetxlog ne doit pas être utilisé pour cela, car il risque de supprimer les dernières transactions (cet outil est généralement utilisé dans les situations de récupération après un crash, lorsque tout le reste a échoué).

Answer 4

Il ne faut jamais toucher manuellement aux fichiers WAL, c'est parfaitement clair.

S'il y a des fichiers suspendus dans le fichier pg_xlog c'est-à-dire qu'il y a un fichier qui se termine par .done* dans le sous-dossier archive_status qui doivent être nettoyées manuellement, ce qui peut être fait avec la commande sql

CHECKPOINT;

ce qui force un point de contrôle de la transaction qui inclut le nettoyage des fichiers de segments WAL.

Véase documentation pour la 9.3 mais existe dans toutes les versions actuelles de Postgresql.