Re: [pgsql-fr-generale] Nécessité de pg_start_backup pour du log-shipping

Le 29 septembre 2010 11:19, <philippe(dot)beaudoin(at)bull(dot)net> a écrit :
>
> 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 ?
>
> 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.
> - un fichier backup_label_file est créé ; il ne nous est pas d'une grande
> utilité !
> - 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 ?

Il me semble.

Pour résumer et vulgariser:

les start/stop_backup posent des marqueurs. (et autres full_page_write
passe a ON de force, etc..)
pendant ce temps on peut copier/rsyncer/snapshoter le fs, le pgdata ou autre.

*Mais* le processus d'archivage des WAL est indépendant (il n'est
d'ailleurs pas intéressant de copier le répertoire pg_xlog durant
l'étape précédente).

Soit on recopie le répertoire pg_xlog avant le start/stop puis on le
rsync après le stop_backup.
Soit on a bien activé l'archive_command qui sert a ca.

PS: un fsync = ON ne garantit pas que toutes les données soient
constamment écrites sur disque, seuleument les WAL. (penser au dirty
cache de linux par exemple qui va bufferiser l'écriture des tables)

PS2: faire un snapshot du serveur secondaire peut etre fait aussi.. au
lieu du primaire, réduisant les coût et impacts sur la production.

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support