Skip site navigation (1) Skip section navigation (2)

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

From: philippe(dot)beaudoin(at)bull(dot)net
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>,pgsql-fr-generale(at)postgresql(dot)org,pgsql-fr-generale-owner(at)postgresql(dot)org,philippe(dot)beaudoin(at)bull(dot)net,thibaud(dot)walkowiak(at)certia(dot)cnafmail(dot)fr
Subject: Réf. : Re: Nécessité de pg _start_backup pour du log-shipping
Date: 2010-09-29 13:25:09
Message-ID: OF43C43686.68DAFD3B-ONC12577AD.00474995@frcl.bull.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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.

Responses

pgsql-fr-generale by date

Next:From: Marc CousinDate: 2010-09-29 13:57:38
Subject: Re: Nécessité de pg_start_backup pour du log-shipping
Previous:From: Dimitri FontaineDate: 2010-09-29 12:27:18
Subject: Re: Nécessité de pg_start_backup pour du log-shipping

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group