Re: Nécessité de pg_start_backup pour du log-shipping

Bonjour Philippe,

Le 29/09/2010 11:19, philippe(dot)beaudoin(at)bull(dot)net a écrit :
> [...]
> Je travaille avec un de mes clients, la CNAF pour ne rien cacher, sur un
> projet de mise en oeuvre de log shipping.
> L'objectif est de sécuriser encore un peu plus les productions pour par
> exemple être capable de ne pas perdre une journée d'activité des
> utilisateurs si, par exemple, vers 16h30, un DBA étourdi faisait un
> malencontreux DROP DATABASE, SCHEMA, TABLE ... ou si un FS se trouvait
> cassé !
>
> Actuellement, les nombreuses bases sont physiquement hébergées sur des
> baies de disques EMC via un SAN. Pour les sauvegardes, la CNAF dispose
> d'un jeu de mirroirs des disques, utilisant la fonctionalité TIime-Finder
> Clone des baies. En temps normal, les mirroirs (CLONEs) conservent l'image
> des bases à la veille au soir. En fin d'après-midi, ces CLONE sont mis en
> état "synchronisation". Puis vers 18h, la synchronisation est coupé
> (SPLIT), les mirroirs restant alors dans un état figé pendant 24h. Ce sont
> ces CLONEs qui sont ensuite utilisés pour les sauvegardes sur cartouche,
> pendant que la production tourne sur les "vrais bases". Ils contiennent
> bien sûr tous les fichiers des clusters, tablespaces et pg_xlog compris.
> Lorsqu'il est nécessaire de restaurer une base, le CLONE concerné est
> restauré et le cluster redémarré. Comme le SPLIT a été fait sans arrêt du
> cluster, au redémarrage, celui-ci se retrouve dans un état instable,
> similaire à celui obtenu après un crash du serveur. Mais après la recovery
> initiale, ça repart !
>
> Pour le projet de log shipping, l'idée est d'archiver les WAL pour être
> capable, le cas échéant, de les ré-appliquer (complètement ou en PITR) sur
> des images de bases présentes sur les CLONEs.
> Les premiers tests réalisés montrent que 1) ça marche (mais nous n'en
> doutions pas ! ), 2) la volumétrie des logs à archiver (après compression
> avec pg_lesslog) est tout à fait raisonable.
>
> J'en arrive donc à ma question !
> La documentation PostgreSQL sur l'archivage en continu indique qu'il faut
> utiliser les commandes pg_start_backup et pg_stop_backup. Mais celles-ci
> sont elles utiles ici ?
>

Oui. Elles sont nécessaires pour enregistrer la position du dernier
checkpoint dans le fichier de contrôle.

> Sur ce point, ma compréhension du fonctionnement de postgres est la
> suivante :
> - entre le retour de la commande pg_start_backup et le lancement de
> pg_stop_backup, les fichiers de données sont figés et les mises à jours
> s'empilent dans les WAL ; pour nous, tout étant dans le même espace
> disque, ce sont toujours des mises à jours de fichiers qui peuvent
> intervenir même au moment du SPLIT.

Rien n'est figé concernant la modification des fichiers, que ce soit des
fichiers pour les données ou des fichiers pour les journaux de
transactions. La base continue à fonctionner (de ce côté là) comme de
normal.

> - un fichier backup_label_file est créé ; il ne nous est pas d'une grande
> utilité !

Un autre fichier est impacté, global/pg_control. Et sa modification est
nécessaire pour que PostgreSQL sache à partir de quel journal il doit
rejouer les transactions.

> - au stop_backup, un nouveau log est utilisé ; pas d'impact pour nous.
> - un fichier backup_history_file est créé avec le label fourni au
> pg_start_backup (nous ne voyons pas d'info spécialement intéressant à y
> mettre, l'endroit de stockage de la sauvegarde état toujours le même), les
> heures d'exécution des 2 fonctions et les identifiants des WAL contenant
> les transactions de la période start_backup / stop_backup.
> Je ne vois donc rien d'essentiel.
>
> Mais est-ce que je passe à côté de quelque chose ?
>

Oui, la modification du pg_control ainsi que l'exécution du CHECKPOINT
qui permet de s'assurer que les données en cache sont stockées sur le
disque, dans les fichiers de données.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com