public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Markus Schiltknecht <[email protected]>
Cc: PostgreSQL-documentation <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Replication documentation addition
Date: Tue, 24 Oct 2006 22:53:14 -0400 (EDT)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
I have changed the text to reference "fail over" and "load balancing".
I think it makes it clearer. Let me know what you think. I am hesitant
to mention commercial PostgreSQL products in our documentation.
---------------------------------------------------------------------------
Markus Schiltknecht wrote:
> Hello Bruce,
>
> Bruce Momjian wrote:
> > Here is a new replication documentation section I want to add for 8.2:
> >
> > ftp://momjian.us/pub/postgresql/mypatches/replication
> >
> > Comments welcomed.
>
> Thank you, that sounds good. It's targeted to production use and
> currently available solutions, which makes sense in the official manual.
>
> You are explaining the sync vs. async categorization, but I sort of
> asked myself where the explanation of single vs multi-master has gone. I
> then realized, that you are talking about read-only and a "read/write
> mix of servers". Then again, you are mentioning 'Multi-Master
> Replication' as one type of replication solutions. I think we should be
> consistent in our naming. As Single- and Multi-Master are the more
> common terms among database replication experts, I'd recommend to use
> them and explain what they mean instead of introducing new names.
>
> Along with that, I'd argue that this Single- or Multi-Master is a
> categorization as Sync vs Async. In that sense, the last chapter should
> probably be named 'Distributed-Shared-Memory Replication' or something
> like that instead of 'Multi-Master Replication', because as we know,
> there are several ways of doing Multi-Master Replication (Slony-II /
> Postgres-R, Distributed Shared Memory, 2PC in application code or the
> above mentioned 'Query Broadcast Replication', which would fall into a
> Multi-Master Replication model as well)
>
> Also in the last chapter, instead of just saying that "PostgreSQL does
> not offer this type of replication", we could probably say that
> different projects are trying to come up with better replication
> solutions. And there are several proprietary products based on
> PostgreSQL which do solve some kinds of Multi-Master Replication. Not
> that I want to advertise for any of them, but it just sounds better than
> the current "no, we don't offer that".
>
> As this documentation mainly covers production-quality solutions (which
> is absolutely perfect), can we document the status of current projects
> somewhere, probably in a wiki? Or at least mention them somewhere and
> point to their websites? It would help to get rid of all those rumors
> and uncertainties. Or are those intentional?
>
> Just my two cents.
>
> Regards
>
> Markus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian [email protected]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
view thread (117+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Replication documentation addition
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox