From: | Mathias Brossard <mathias(dot)brossard(at)opentrust(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Core team statement on replication in PostgreSQL |
Date: | 2008-05-29 16:01:44 |
Message-ID: | 483ED368.5090408@opentrust.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
Tom Lane wrote:
> In practice, simple asynchronous single-master-multiple-slave
> replication covers a respectable fraction of use cases, so we have
> concluded that we should allow such a feature to be included in the core
> project. We emphasize that this is not meant to prevent continued
> development of add-on replication projects that cover more complex use
> cases.
IMHO, this will help PostgreSQL adoption, mindshare and even boost interest in
development for the other replication use cases.
> We believe that the most appropriate base technology for this is
> probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.
The slides are up at http://www.pgcon.org/2008/schedule/events/76.en.html
From what I gather from those slides it seems to me that the NTT solution is
synchronous not asynchronous. In my opinion it's even better, but I do
understand that others might prefer asynchronous. I'm going to speculate, but I
would think it should be possible (without a substancial rewrite) to support
both modes (or even some intermediate modes, like DRBD on Linux).
> We hope that such a feature can be completed for 8.4. Ideally this
> would be coupled with the ability to execute read-only queries on the
> slave servers, but we see technical difficulties that might prevent that
> from being completed before 8.5 or even further out. (The big problem
> is that long-running slave-side queries might still need tuples that are
> vacuumable on the master, and so replication of vacuuming actions would
> cause the slave's queries to deliver wrong answers.)
From the 8.4dev documentation, another problem for read-only slaves would be :
« Operations on hash indexes are not presently WAL-logged, so replay will not
update these indexes. The recommended workaround is to manually REINDEX each
such index after completing a recovery operation. ».
Sincerely,
--
Mathias Brossard
Attachment | Content-Type | Size |
---|---|---|
mathias_brossard.vcf | text/x-vcard | 191 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2008-05-29 16:03:15 | Re: State of PostgreSQL, BOF at OSCON? |
Previous Message | Dave Page | 2008-05-29 16:00:55 | Re: Core team statement on replication in PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2008-05-29 16:03:06 | Re: [PERFORM] Memory question on win32 systems |
Previous Message | Dave Page | 2008-05-29 16:00:55 | Re: Core team statement on replication in PostgreSQL |