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

Le 29/09/2010 15:25, philippe(dot)beaudoin(at)bull(dot)net a écrit :
> Merci Dim et Guillaume,
>
> Nous allons donc encadrer l'opération de SPLIT time-finder avec ces
> pg_start_backup et pg_stop_backup.
>
>>> 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.
> Ca me semble être effectivement l'argument clé.
>
>>> 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.
> Cela signifie-t'il que le bg-writer continue d'appliquer sur les fichiers
> de données les modifications enregistrées dans les WAL entre le
> start_backup et le stop_backup ? (J'avais en tête que non.)
>

Oui. C'est d'ailleurs pour cela que la doc prévient qu'il est possible
que des outils comme tar se plaignent que les fichiers changent pendant
qu'il les sauvegarde.

>> 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.
> Si j'interprète bien, ça répond (négativement) à ma question précédente.
> Isn't it ?
>

Oui.

>>> 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.
> OK, mais dans notre cas, avec fsync = on, avec ou sans CHECKPOINT, nos
> données sont sur disque (wal ou fichiers de données).

Ça ne force pas la modification du pg_control. De plus, comme le dit
Dimitri, il y a aussi la question du restartpoint.

> A ce propos, nous venons d'ajouter un CHECKPOINT avant les opérations de
> SPLIT. Comme normalement, à ce moment, l'activité sur la base est quasi
> nulle, le SPLIT a très peu de chance d'intervenir pendant l'activité du
> bg-writer.

Je ne suis pas certain que tu veuilles risquer tes données sur un « peu
de chance » de modifications :)

> Au fait, ce CHECKPOINT ne génère-t-il pas lui même le pg_control
> (répondant ainsi au besoin pour rejouer les transactions) ?
>

Si. Mais tu as toujours le soucis du restartpoint et du recyclage des
journaux de transactions.

>> 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).
> Je comprends que le restart-point dont tu parles se matérialise par le
> fichier pg_control dont parle Guillaume. Right ?
>

Oui. Pour infos, le contenu de ce fichier est visualisable avec l'outil
pg_controldata. Attention, préfère plutôt la version anglaise que
française (LANG=C pg_controldata repertoire_data). Je sais, j'ai fait la
traduction, je ne l'aime pas trop, mais c'est sur un domaine assez
compliqué ce qui fait que je n'ai moi-même vraiment aucune confiance sur
cette trad-là (oui, c'est lamentable, je sais :) celui qui veut aider
est le bienvenu).

++

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