Re: Timeline in the light of Synchronous replication
От | fazool mein |
---|---|
Тема | Re: Timeline in the light of Synchronous replication |
Дата | |
Msg-id | AANLkTik4zvqBf96BrU7NgVB5OYMbAHNwESr0CxF5VgQE@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Timeline in the light of Synchronous replication (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-hackers |
I believe we should come up with a universal solution that will solve potential future problems as well (for example, ifin sync replication, we decide to send writes to standbys in parallel to writing on local disk).<br /><br /> The idealthing would be to have an id that is incremented on every failure, and is stored in the WAL. Whenever a standby connectsto the primary, it should send the point p in WAL where streaming should start, plus the id. If the id is the sameat the primary at point p, things are good. Else, we should tell the standby to either create a new copy from scratch,or delete some WALs.<br /><br />@David<br />> One way to get them in sync without starting from scratch is touse<br />> rsync from A to B. This works in the asynchronous case, too. :)<br /><br />The problem mainly is detectingwhen one can rsync/stream and when not.<br /><br />Regards<br /><br /><br /><br /><div class="gmail_quote">On Mon,Oct 18, 2010 at 1:57 AM, Dimitri Fontaine <span dir="ltr"><<a href="mailto:dimitri@2ndquadrant.fr">dimitri@2ndquadrant.fr</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Fujii Masao<<a href="mailto:masao.fujii@gmail.com">masao.fujii@gmail.com</a>> writes:<br /> > But, even though we willhave done that, it should be noted that WAL in<br /> > A might be ahead of that in B. For example, A might crash rightafter<br /> > writing WAL to the disk and before sending it to B. So when we restart<br /> > the old master Aas the standby after failover, we should need to delete<br /> > some WAL files (in A) which are inconsistent with theWAL sequence in B.<br /><br /></div>The idea to send from master to slave the current last applied LSN has<br /> beentalked about already. It would allow to send the WAL content in<br /> parallel of it's local fsync() on the master, thestandby would refrain<br /> from applying any WAL segment until it knows the master is past that.<br /><br /> Now, givensuch a behavior, that would mean that when A joins again as a<br /> standby, it would have to ask B for the currentlast applied LSN too,<br /> and would notice the timeline change. Maybe by adding a facility to<br /> request thelast LSN of the previous timeline, and with the behavior<br /> above applied there (skipping now-known-future-WALs inrecovery), that<br /> would work automatically?<br /><br /> There's still the problem of WALs that have been applied before<br/> recovery, I don't know that we can do anything here. But maybe we could<br /> also tweak the CHECKPOINT mecanismnot to advance the restart point<br /> until we know the standbys have already replayed anything up to the<br />restart point?<br /><font color="#888888"><br /> --<br /> Dimitri Fontaine<br /><a href="http://2ndQuadrant.fr" target="_blank">http://2ndQuadrant.fr</a> PostgreSQL : Expertise, Formation et Support<br /></font></blockquote></div><br/>
В списке pgsql-hackers по дате отправления:
Следующее
От: Cédric VillemainДата:
Сообщение: Re: Creation of temporary tables on read-only standby servers