pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedSynchronous Multimaster Replication
3+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2019-10-07 dafeac8047 4fe04a62c5 7ae8a9959c b569a7146f e4ca62b948 5136dcf6ab 47eec34e46 docs: Improve A?synchronous Multimaster Replication descr.
* Synchronous Multimaster Replication
@ 2019-09-15 16:37 PG Doc comments form <noreply@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: PG Doc comments form @ 2019-09-15 16:37 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: juha-pekka.eloranta@reaktor.fi
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/11/different-replication-solutions.html
Description:
Not sure if this is an error but I was wondering about this sentence: "In
fact, write performance is often worse than that of a single server". Isn't
syncronous multimaster write performance always (rather than "often") worse
than that of a single (non-distributed) server?
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Synchronous Multimaster Replication
@ 2019-09-28 13:47 Bruce Momjian <bruce@momjian.us>
parent: PG Doc comments form <noreply@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: Bruce Momjian @ 2019-09-28 13:47 UTC (permalink / raw)
To: juha-pekka.eloranta@reaktor.fi; pgsql-docs@lists.postgresql.org
On Sun, Sep 15, 2019 at 04:37:18PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/11/different-replication-solutions.html
> Description:
>
> Not sure if this is an error but I was wondering about this sentence: "In
> fact, write performance is often worse than that of a single server". Isn't
> syncronous multimaster write performance always (rather than "often") worse
> than that of a single (non-distributed) server?
Very good point. I have improved the text with the attached patch. I
also clarified the asynchronous case.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachments:
sync.diff (text/x-diff, 2.2K) download
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
new file mode 100644
index 43bcb2a..a42541f
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*************** protocol to make nodes agree on a serial
*** 237,243 ****
<listitem>
<para>
! For servers that are not regularly connected, like laptops or
remote servers, keeping data consistent among servers is a
challenge. Using asynchronous multimaster replication, each
server works independently, and periodically communicates with
--- 237,244 ----
<listitem>
<para>
! For servers that are not regularly connected or have slow
! communication links, like laptops or
remote servers, keeping data consistent among servers is a
challenge. Using asynchronous multimaster replication, each
server works independently, and periodically communicates with
*************** protocol to make nodes agree on a serial
*** 256,264 ****
In synchronous multimaster replication, each server can accept
write requests, and modified data is transmitted from the
original server to every other server before each transaction
! commits. Heavy write activity can cause excessive locking,
! leading to poor performance. In fact, write performance is
! often worse than that of a single server. Read requests can
be sent to any server. Some implementations use shared disk
to reduce the communication overhead. Synchronous multimaster
replication is best for mostly read workloads, though its big
--- 257,264 ----
In synchronous multimaster replication, each server can accept
write requests, and modified data is transmitted from the
original server to every other server before each transaction
! commits. Heavy write activity can cause excessive locking and
! commit delays, leading to poor performance. Read requests can
be sent to any server. Some implementations use shared disk
to reduce the communication overhead. Synchronous multimaster
replication is best for mostly read workloads, though its big
* Re: Synchronous Multimaster Replication
@ 2019-10-07 22:06 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 3+ messages in thread
From: Bruce Momjian @ 2019-10-07 22:06 UTC (permalink / raw)
To: juha-pekka.eloranta@reaktor.fi; pgsql-docs@lists.postgresql.org
On Sat, Sep 28, 2019 at 09:47:40AM -0400, Bruce Momjian wrote:
> On Sun, Sep 15, 2019 at 04:37:18PM +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/11/different-replication-solutions.html
> > Description:
> >
> > Not sure if this is an error but I was wondering about this sentence: "In
> > fact, write performance is often worse than that of a single server". Isn't
> > syncronous multimaster write performance always (rather than "often") worse
> > than that of a single (non-distributed) server?
>
> Very good point. I have improved the text with the attached patch. I
> also clarified the asynchronous case.
Patch applied thorough all current versions of the Postgres docs.
Thanks for the report.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2019-10-07 22:06 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-09-15 16:37 Synchronous Multimaster Replication PG Doc comments form <noreply@postgresql.org>
2019-09-28 13:47 ` Bruce Momjian <bruce@momjian.us>
2019-10-07 22:06 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox