Re: write ahead logging in standby (streaming replication)
От | Greg Smith |
---|---|
Тема | Re: write ahead logging in standby (streaming replication) |
Дата | |
Msg-id | 4AFC3C8E.1070505@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: write ahead logging in standby (streaming replication) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: write ahead logging in standby (streaming replication)
|
Список | pgsql-hackers |
Tom Lane wrote: <blockquote cite="mid:24069.1258037544@sss.pgh.pa.us" type="cite"><pre wrap="">Fujii Masao <a class="moz-txt-link-rfc2396E"href="mailto:masao.fujii@gmail.com"><masao.fujii@gmail.com></a> writes: </pre><blockquotetype="cite"><pre wrap="">The problem is that fsync needs to be issued too frequently, which would be harmless in asynchronous replication, but not in synchronous one. A transaction would have to wait for the primary's and standby's fsync before returning a "success" to a client. </pre></blockquote><pre wrap=""> Surely that is exactly what is *required* if the user has asked for synchronous replication. </pre></blockquote> This a distressingly common thing people get wrong about replication. You caneither have synchronous replication, which as you say has to be slow: you must wait for an fsync ACK from the secondaryand a return trip before you can say something is committed on the primary. Or you can get better performance bynot waiting for all of those things, but the minute you do that it's *not* synchronous replication anymore. You can'tget high-performance and true synchronous behavior; you have to pick one. The best you can do if you need both is workon accelerating fsync everywhere using the standard battery-backed write cache technique.<br /><br /><pre class="moz-signature"cols="72">-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
В списке pgsql-hackers по дате отправления: