Re: write ahead logging in standby (streaming replication)
От | Greg Smith |
---|---|
Тема | Re: write ahead logging in standby (streaming replication) |
Дата | |
Msg-id | 4AFCFA0C.7010703@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: write ahead logging in standby (streaming replication) (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: write ahead logging in standby (streaming replication)
|
Список | pgsql-hackers |
Fujii Masao wrote: > On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith <greg@2ndquadrant.com> wrote: > >> Right, those are the possibilities, all four of them have valid use cases in >> the field and are worth implementing. I don't like the label >> "semi-synchronous replication" myself, but it's a valuable feature to >> implement, and that is unfortunately the term other parts of the industry >> use for that approach. >> > > BTW, MySQL and DRBD use the term "semi-synchronous": > http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication > http://www.drbd.org/users-guide/s-replication-protocols.html > Yeah, that's the "other parts of the industry" I was referring to. MySQL uses "semi-synchronous" to distinguish between its completely asynchronous default replication mode and one where it provides a somewhat safer implementation. The description reads more as "asynchronous with some synchronous elements", not "one style of synchronous implementation". None of their documentation wanders into the problem area here by calling it a true synchronous solution when it's really not--MySQL Cluster is their synchronous vehicle. It's fine to adopt the term "semi-synchronous", as it's become quite popular and people are going to label the PG implementation with it regardless of what is settled on here. But we should all try to be careful to use it as correctly as possible. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: