"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Dimitri Fontaine <dfontaine@hi-media.com> wrote:
>
>> 4. sync: slave is no more lagging, it's applying the stream as it
>> gets it, either as part of the master transaction or not
>> depending on the GUC settings
>
> I think the interesting bit is when you're at this point and the
> connection between the master and slave goes down for a couple days.
> How do you handle that?
Maybe how londiste handle the case could help us here:
http://skytools.projects.postgresql.org/doc/londiste.ref.html#toc18
State | Owner | What is done
---------------------+--------+--------------------
NULL | replay | Changes state to "in-copy", launches londiste.py copy
process,continues with it's work
in-copy | copy | drops indexes, truncates, copies data in, restores
indexes,changes state to "catching-up"
catching-up | copy | replay events for that table only until no more batches
(meanscurrent moment), change state to "wanna-sync:<tick_id>"
and wait for state to change
wanna-sync:<tick_id> | replay | catch up to given tick_id, change state to
"do-sync:<tick_id>"and wait for state to change
do-sync:<tick_id> | copy | catch up to given tick_id, both replay and copy must now
beat same position. change state to "ok" and exit
ok | replay | synced table, events can be applied
Such state changes must guarantee that any process can die at any time
and by just restarting it can continue where it left.
"subscriber add" registers table with NULL state. "subscriber add
—expect-sync" registers table with ok state.
"subscriber resync" sets table state to NULL.
Regards,
--
dim