Re: [pgsql-fr-generale] pg_start_backup et cohérence de la base

Le 6 octobre 2014 09:58, adrien nayrat <adrien(dot)nayrat(dot)axess(at)gmail(dot)com> a
écrit :

> Bonjour,
>
> J'ai une question à propos du backup à chaud des fichiers avec
> pg_start_backup.
>
> On trouve beaucoup d'exemples sur internet où le backup se fait en lançant
> pg_start_backup. Ensuite on effectue une copie des fichiers (tar, rsync,
> cp...) puis un pg_stop_backup.
>
> pg_start_backup effectue un checkpoint et écrit un fichier backup_label
> contenant le dernier checkpoint.
>
> Au premier abord, je me suis interrogé sur la cohérence de la base si les
> fichiers sont modifiés durant la copie. Durant une formation PG j'ai appris
> que postgres ne supprime pas les données (c'est le vacuum qui s'en charge),
> il indique juste leur validité (xmin, xmax). Ce qui, pour moi, pouvait
> expliquer que la base restait cohérente.
>
> Dernièrement je me suis demandé ce qu'il pouvait se passer si durant le
> backup il y avait un vacuum (normal ou full). je pensais que la commande
> devait être bloquée mais j'ai remarqué que ce n'était pas le cas.
>
>
>
> Si on se dessine une timeline :
> PG_START_BAKUP START TAR END
> TAR PG_STOP_BACKUP
> + +
> + +
> | |
> | |
> | |
> | |
>
> +------------------+---------------+--------------+------------------------+------->
>
> |
>
> |
>
> |
>
> +
> VACUUM
>
>
>
>
> Exemple : Au début du pg_start_backup un enregistrement a un xmin de 100,
> durant le backup cet enregistrement est modifié, on se retrouve avec deux
> enregistrements, le premier avec un xmin = 100 et un xmax=150, le deuxième
> avec le xmin=150. Ensuite un vacuum est effectué et celui-ci supprime
> l'enregistrement avec un xmin=100 (celui au début du pg_start_backup). On
> se retrouve dans une situation bancale ?
>
>
>
> En creusant je suis tombé sur cette conversation qui illustre très bien
> mon interrogation
>
> http://www.postgresql.org/message-id/CA+CZih7ehLzhHkFivPfFHs0dvf+XdUpGXVMkrOLrcULiO4_mkw@mail.gmail.com
>
> Au fil des échanges, un intervenant explique que le backup n'est cohérent
> qu'après le pg_stop_backup :
>
>> http://www.postgresql.org/message-id/51A02AF9.9040804@vmware.com
>> When you restore the backup, the database is restored to the state it
>> was when pg_stop_backup() was called. What did you expect?
>
>
>
> Comment la base peut être restaurée au point "PG_STOP_BACKUP" alors que
> le TAR se termine avant?
>
>
Au moment de la sauvegarde, elle n'est pas cohérente si des modifications
ont eu lieu (un DROP TABLE par exemple supprimera le fichier associé). Et
PostgreSQL n'interdit aucune modification, en dehors du fichier pg_control.

En fait, ce n'est pas la sauvegarde qui est cohérente au moment du "stop
backup", mais la restauration. Quand on restaure les fichiers et qu'on
demande à PostgreSQL de rejouer les journaux archivés, ce n'est qu'à partir
du moment où on atteint le moment du "stop backend" que les fichiers de la
restauration son cohérents.

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com