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

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 ?

Cordialement.

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

Bonjour,

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
>> 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.

Et surtout pour que PostgreSQL arrête de recycler les fichiers de WAL
déjà clôturés, histoire de ne pas réécrire l'histoire pendant la
sauvegarde.

> 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.

D'où le démarrage comme après un crash lorsqu'on utilise ce mode de
restauration.

> 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.

Il s'agit aussi, il me semble, de forcer la création d'un "restart
point", évènement qui arrive également lors de la vie ordinaire du
serveur.

On le force ici pour garantir que le redémarrage lors de la restauration
peut se faire avec les fichiers WALs sauvegardés seulement. Sans cette
étape, je ne crois pas que l'on puisse garantir qu'aucun des WAL
nécessaires n'a été recyclés au moment du pg_start_backup() (race
condition).

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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.

Le 29/09/2010 15:57, Marc Cousin a écrit :
> The Wednesday 29 September 2010 11:19:59, philippe(dot)beaudoin(at)bull(dot)net wrote :
>>[...]
>> 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.

Ah bah quand même. Moi qui étais étonné de ne pas te voir répondre pour
corriger mes approximations, je commençais à me demander si tu n'étais
pas malade ou trop occupé avec le forum web de pgfr. Bref, je suis
rassuré :-D

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

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