Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby
От | Dimitri Fontaine |
---|---|
Тема | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |
Дата | |
Msg-id | 87skh7bnv3.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Synch Rep: direct transfer of WAL file from
the primary to the standby
|
Список | pgsql-hackers |
Hi, Tom Lane <tgl@sss.pgh.pa.us> writes: > I think this fails the basic sanity check: do you need it to still work > when the master is dead. I don't get it. Why would we want to setup a slave against a dead master? The way I understand the current design of Synch Rep, when you start a new slave the following happen: 1. init: slave asks the master the current LSN and start streaming WAL 2. setup: slave asks the master for missing WALs from its current position to this LSN it just got, and apply them allto reach initial LSN (this happen in parallel to 1.) 3. catchup: slave has replayed missing WALs and now is replaying the stream he received in parallel, and which appliesfrom init LSN (just reached) 4. sync: slave is no more lagging, it's applying the stream as it gets it, either as part of the master transaction ornot depending on the GUC settings So, what I'm understanding you're saying is that the slave still should be able to setup properly when master died before it synced. What I'm saying is that if master dies before any sync slave exists, you get to start from backups (filesystem snaphost + archives for example, PITR recovery etc), as there's no slave. Regards, -- dim
В списке pgsql-hackers по дате отправления: