Re: Cascade replication
От | Simon Riggs |
---|---|
Тема | Re: Cascade replication |
Дата | |
Msg-id | CA+U5nM+OfZr7aLs7-DYy0V-DeC-QcPArKWqB-kiKR+_rQHzJ0Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Cascade replication (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Cascade replication
|
Список | pgsql-hackers |
On Wed, Jul 6, 2011 at 2:13 AM, Fujii Masao <masao.fujii@gmail.com> wrote: >> IMHO it's time to get rid of RECOVERYXLOG as an initial target for >> de-archived files. That made sense once, but now we have streaming it >> makes more sense for us to de-archive straight onto the correct file >> name and let the file be cleaned up later. So de-archiving it and then >> copying to the new location doesn't seem the right thing to do >> (especially not to copy rather than rename). RECOVERYXLOG allowed us >> to de-archive the file without removing a pre-existing file, so we >> must handle that still - the current patch would fail if a >> pre-existing WAL file were there. > <snip> > If we don't need to keep a pre-existing file, I'll change the way to de-archive > according to your suggestion, as follows; > > 1. Rename a pre-existing file to EXISTINGXLOG > 2. De-archive the file onto the correct name > 3. If the de-archived file is invalid (i.e., its size is not 16MB), > remove it and > rename EXISTINGXLOG to the correct name > 4. If the de-archived file is valid, remove EXISTINGXLOG > 5. Replay the file with the correct name I'm laughing quite hard here... :-) > Or > > 1. De-archive the file to RECOVERYXLOG > 2. If RECOVERYXLOG is valid, remove a pre-existing one and rename > RECOVERYXLOG to the correct name > 3. Replay the file with the correct name Yes please, that makes sense. >> Those changes will make this code cleaner for the long term. >> >> I don't think we should simply shutdown a WALSender when we startup. >> That is indistinguishable from a failure, which is going to be very >> worrying if we do a switchover. Is there another way to do this? Or if >> not, at least a log message to explain it was normal that we requested >> this. > > What about outputing something like the following message in that case? > > if ("walsender receives SIGUSR2") > ereport(LOG, "terminating walsender process due to > administrator command"); ...which doesn't explain the situation because we don't know why SIGUSR2 was sent. I was thinking of something like this LOG: requesting walsenders for cascading replication reconnect to update timeline but then I ask: Why not simply send a new message type saying "new timeline id is X" and that way we don't need to restart the connection at all? >> It would be possible to have synchronous cascaded replication but that >> is probably another patch :-) > > Yeah, right. You'll try? ;) I'll wait for a request... -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: