Réf. : Re: Nécessité de pg _start_backup pour du log-shipping

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

>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, 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 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.
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) ?

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

Merci encore.
A+ Philippe.