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

The Wednesday 29 September 2010 11:19:59, philippe(dot)beaudoin(at)bull(dot)net wrote :
> Bonjour à tous,
>
> 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 ?
Pour nuancer les propos (oui franc et massif de Guillaume), ces commandes ne
sont pas forcément utiles, mais une sécurité supplémentaire.

Je m'explique:
le but de pg_start_backup et pg_end_backup, comme l'ont expliqué les autres
messages, est de permettre la sauvegarde de la base alors qu'elle est en cours
de modification, et de pouvoir repartir de cette sauvegarde incohérentes
(fichiers modifiés lors de la sauvegarde, blocs potentiellement fractionnés,
incohérence entre les différents fichiers, etc…).

Sur une sauvegarde par snapshot (ou clone), c'est en théorie inutile: le
périphérique, au niveau bloc, est gelé le temps de la prise du snapshot, ou de
la déconnexion du clone.

Le souci, c'est qu'il se peut que vous ayez plusieurs systèmes de fichiers à
snapshotter (si vous avez par exemple plusieurs tablespaces dans des systèmes
de fichier différents) . Dans ce cas, certaines baies SAN permettent de faire
des 'groupes de snapshot' sur lesquelles on peut déclencher des snapshots
cohérents (et donc obtenir des copies logiques des périphériques disques tels
qu'ils auraient étés si on avait crashé le serveur au moment du snapshot). Si
vous n'avez pas cette fonctionnalité, vous DEVEZ faire un pg_start_backup. Si
vous avez la fonctionnalité dans votre baie SAN, vous n'êtes pas obligé, mais
ça ne coûte rien, et ça peut éviter une surprise désagréable au moment de la
restauration.

>
> 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.
Non, comme expliqué par Guillaume et Dimitri

> - un fichier backup_label_file est créé ; il ne nous est pas d'une grande
> utilité !
À vous non, au moteur oui (c'est ce qui lui permet, entre autres, de savoir
que c'est une sauvegarde qui est dans le répertoire quand vous la restaurez,
et qui vous évite de vous tirer dans le pied: il sait qu'il doit faire une
récupération).

> - 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.
L'adresse dans le WAL de fin de backup est une information capitale : sans
lui, le moteur ne peut pas savoir quel est l'endroit minimum jusqu'où rejouer
les journaux pour que les fichiers soient cohérents.