Comment PostgreSQL gère-t-il les points de contrôle au milieu d'une sauvegarde compatible WAL?

Sur un PostgreSQL v9.0, j'ai un système d'archivage WAL qui fonctionne. Le WAL dépose donc un archivage régulier (lorsque 3 WAL sont créés ou si un WAL a plus de 15 minutes).

J'ajoute maintenant un pack binaire du répertoire PG_DATA (à l'exclusion du sous-répertoire pg_xlog). Pour ce faire, j'exécute une pg_start_backup(),copie binaire et a pg_stop_backup().

Je pense que je comprends très bien ce que font pg_start_backup et pg_stop_backup, le premier fait un point de contrôle et le dernier s'assure que le dernier fichier WAL est archivé.

D'après la documentation officielle, nous pouvons voir que pour la copie de données binaires, nous devons:

Effectuez la sauvegarde à l'aide de tout outil de sauvegarde de système de fichiers pratique tel que tar ou cpio (pas pg_dump ou pg_dumpall). Il n'est ni nécessaire ni souhaitable d'arrêter le fonctionnement normal de la base de données pendant cette opération.

Je suis donc assez perplexe. Cela signifie qu'un point de contrôle pourrait être effectué pendant que nous faisons la copie. J'ai vu beaucoup de documentation indiquant que la commande de copie devrait permettre des changements de données lors de la copie, je suis d'accord avec ça, il suffit simplement de trouver le bon outil. Mais ma question est de savoir comment postgreSQL gérera la récupération avec un contenu pg_data contenant certains fichiers qui sont incohérents (certains d'avant le point de contrôle, d'autres d'après)?

En relisant les journaux de transactions, Postgresql pourra mettre tous ces fichiers dans le bon état? J'ai vu que les opérations de création de tables et de suppression sont dangereuses pendant la sauvegarde. N'y a-t-il pas des opérations dangereuses comme les commandes de vide ? Le pg_backup suspend-il les opérations de vide? Dois-je faire une copie du fichier global / pg_control à la fin du début du processus de copie binaire? Dois-je utiliser un système de fichiers prenant en charge les instantanés (comme avec un xfs-freeze) pour obtenir un processus de restauration plus rapide?

J'ai vu qu'un crash de script de sauvegarde ne lancerait pas automatiquement pg_stop_backup, il y a donc une chance que mon état de sauvegarde vive longtemps (jusqu'à ce que mon nagios appelle quelqu'un quelque part pour corriger le pg_stop_backup ()). Donc, si quelque chose est différent dans PostgreSQL entre ces deux commandes, j'aimerais le savoir, pour comprendre quel impact cela peut avoir.

Éclairez-moi s'il vous plaît.

Tu as demandé:

comment postgreSQL gérera la récupération avec un contenu pg_data contenant des fichiers incohérents.

pg_start_backup()assurez-vous que le fichier de données est au moins aussi nouveau que le point de contrôle. Lors de la récupération, les journaux sont appliqués.

Si les données sont anciennes, le journal les mettra à jour.

Si les données sont nouvelles, le journal aura le même contenu. Il n'y a aucun mal à l'écrire à nouveau.

Les données ne sont jamais plus récentes que le journal, car les journaux sont en écriture (WAL).

Tu as demandé:

... xfs-freeze...

xfs-freezeest similaire à pg_start_backup(), il ne prend pas un instantané. Vous avez besoin d'un gestionnaire de volume pour ce faire.

Tu as demandé:

... pourquoi les instructions create tablespace & create database ne sont pas prises en charge si le WAL peut tout rejouer?

Il est pris en charge, juste un petit gotcha. Voir http://www.postgresql.org/docs/8.1/static/backup-online.html :

23.3.5. Avertissements

Les commandes CREATE TABLESPACE sont enregistrées en WAL avec le chemin absolu littéral et seront donc réexécutées en tant que créations d'espace de table avec le même chemin absolu. Cela peut être indésirable si le journal est relu sur une autre machine. Cela peut être dangereux même si le journal est relu sur la même machine, mais dans un nouveau répertoire de données: la relecture écrasera toujours le contenu du tablespace d'origine. Pour éviter des accrochages potentiels de ce type, la meilleure pratique consiste à effectuer une nouvelle sauvegarde de base après avoir créé ou supprimé des espaces disque logiques.