Hello Chris,
thank you for putting this together. It seems to be the replication
guide we are looking for: an overview over the principles and solutions
of replication for PostgreSQL. Good work!
Some suggestions I came up with when reading: when preparing my
presentation I came to the conclu
Hi,
Chris Browne wrote:
Under conditions where one expects to see a lot of conflicting
updates, pushing out locks earlier would allow sooner discovery of
these conflicts; whether this improves or worsens total performance is
at least a bit ambiguous.
That's a good point, yes. Given one gets lo
Hi,
has there been a consensus about where a replication document should go
and what it should cover?
Regards
Markus
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Robert Treat wrote:
On Monday 21 August 2006 09:47, Markus Schiltknecht wrote:
has there been a consensus about where a replication document should go
and what it should cover?
>
I think the general idea is to toss it on techdocs... like the GUI Tools
page... http://www.postgresql.org/d
Bruce Momjian wrote:
I will work on a replication section for 8.2, similar to the XML docs I
posted a few days ago.
Okay, great! You have Christopher's draft [1]? How much information do
you want to include into the main documentation? Do you want to put some
more details to the techdocs?
R
Bruce Momjian wrote:
My content will be more general.
That sounds good to me.
Shall we put more details into the techdocs, then? Or do you want to
leave it up to every single project to better document itself?
I will post to the docs list when it
is ready for review.
Great. I'll be on va
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 mak
Hannu Krosing wrote:
I think the "official" term for this kind of "replication" is
Shared-Nothing Clustering.
Well, that's just another distinction for clusters. Most of the time
it's between Shared-Disk vs. Shared-Nothing. You could also see the very
Big Irons as a Shared-Everything Cluster.
Hello Josh,
Josh Berkus wrote:
Hmmm ... while the primer on different types of replication is fine, I
think what users were really looking for is a listing of the different
replication solutions which are available for PostgreSQL and how to get
them.
Well, let's see what we have:
* Shared D
Hi,
Bruce Momjian wrote:
I have updated the text. Please let me know what else I should change.
I am unsure if I should be mentioning commercial PostgreSQL products in
our documentation.
I support your POV and vote for not including any pointers to commercial
extensions in the official docu
Hi,
Jim C. Nasby wrote:
Those to statements are at odds with each other, at least based on
everyone I've ever talked to in a commercial setting. People will use
terms like 'replication', 'HA' or 'clustering' fairly interchangably.
Usually what these folks want is some kind of high-availability
s
Hi,
Jeff Frost wrote:
I would speculate that your terminology is slightly more accurate than mine.
I can't help it, but I'm still thinking the terminology in the
replication documentation is somewhat made up.
Bruce Momjian wrote:
Hmmm. Interesting. Does anyone else have details or an op
Hello Bruce,
I was trying to put together all comments to specific sections, thus the
new thread. Hope that helps.
*** Synchronous Multi-Master Replication ***
Bruce Momjian wrote:
> OK, new title is "Synchonous Multi-Master Replication", and the next
> heading is "Asynchronous Multi-Master R
Hello Emmanuel,
Emmanuel Cecchet wrote:
Even here I think that there is a common misconception between
performance and scalability. Most people think that by having
multiple nodes their query will run faster which is obviously wrong
if your original workload does not saturate a single node.
Hi,
Bruce Momjian wrote:
OK, it is two separate entries now:
http://momjian.us/main/writings/pgsql/sgml/high-availability.html
Yes, that's fine with me.
Uh, good point. The title is now "Statement-Based Replication
Middleware". That doesn't say multi-master, but it doesn't say
mas
Hi,
Robert Treat wrote:
Normally the www list is the best place to ask www related questions, but the
answer to this is to take a look at the techdocs section of the website
(http://www.postgresql.org/docs/techdocs/)
That URL doesn't quite work because of the trailing slash. Removing it
and
Hi,
Peter Eisentraut wrote:
I believe both the FAQ and the documentation do explain the naming issue near
the beginning. But the rest of the document should use one name
consistently, or it will just look silly and confusing. Also consider that
many of our written resources are not read line
Hello Bruce,
Bruce Momjian wrote:
I have added a High Availability, Load Balancing, and Replication
Feature Matrix table to the docs:
Nice work. I appreciate your efforts in clearing up the uncertainty that
surrounds this topic.
As you might have guessed, I have some complaints regarding th
Hello Bruce,
thank you for your detailed answer.
Bruce Momjian wrote:
Not sure if you were around when we wrote this chapter but there was a
lot of good discussion to get it to where it is now.
Uh.. IIRC quite a good part of the discussion for chapter 23 was between
you and me, pretty exactl
Hello Bruce,
Bruce Momjian wrote:
Sorry, I forgot who was involved in that discussion.
Well, at least that means I didn't annoy you to death last time ;-)
With the other two I'm unsure.. I see it's very hard to find helpful
positive formulations...
Yea, that's where I got stuck --- that th
Hello Bruce,
Bruce Momjian wrote:
I think the point is that with middleware each server is as least
working simultaneously while with multi-master they don't, at least in
most current implementations, no?
Current implementations include PgCluster, which calls itself a
multi-master replication
Hello Bruce,
Bruce Momjian wrote:
Uh, I think of PgCluster as multi-master, but in a way it is a hybrid
because there is a central server that gets all the queries.
Yes, PgCluster as well as Sequoia use statement based replication.
Sequoia is also clearly a middleware (no changes to Postgres
Hello Bruce,
Bruce Momjian wrote:
Depending on the RAIDb level you are using, Sequoia can be considered
multi-master (RAIDb-1) or single-master (RAIDb-0). Also note that
sequoia can run multiple controllers, thus it does not rely on one
central server.
But in those cases isn't the multi-mast
Hello Bruce,
Bruce Momjian wrote:
Uh, to me the issue is something like pgpool and Sequoia, where the
_master_/replication is happening _outside_ the server
Well, you are saying that the controllers are the masters and do
replication. I can see the reasoning behind it: they are the only nodes
24 matches
Mail list logo
