Core team statement on replication in PostgreSQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Core team statement on replication in PostgreSQL
Дата
Msg-id 26529.1212070375@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Core team statement on replication in PostgreSQL  ("Marko Kreen" <markokr@gmail.com>)
Re: Core team statement on replication in PostgreSQL  (David Fetter <david@fetter.org>)
Re: Core team statement on replication in PostgreSQL  (Mathias Brossard <mathias.brossard@opentrust.com>)
Re: Core team statement on replication in PostgreSQL  (Peter Eisentraut <peter_e@gmx.net>)
Re: Core team statement on replication in PostgreSQL  ("Gurjeet Singh" <singh.gurjeet@gmail.com>)
Re: Core team statement on replication in PostgreSQL  (Simon Riggs <simon@2ndquadrant.com>)
Re: Core team statement on replication in PostgreSQL  ("Dawid Kuroczko" <qnex42@gmail.com>)
Список pgsql-hackers
The Postgres core team met at PGCon to discuss a few issues, the largest
of which is the need for simple, built-in replication for PostgreSQL.
Historically the project policy has been to avoid putting replication
into core PostgreSQL, so as to leave room for development of competing
solutions, recognizing that there is no "one size fits all" replication
solution.  However, it is becoming clear that this policy is hindering
acceptance of PostgreSQL to too great an extent, compared to the benefit
it offers to the add-on replication projects.  Users who might consider
PostgreSQL are choosing other database systems because our existing
replication options are too complex to install and use for simple cases.
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.

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.
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.)

Again, this will not replace Slony, pgPool, Continuent, Londiste, or
other systems for many users, as it will be not be highly scalable nor
support long-distance replication nor replicating less than an entire
installation.  But it is time to include a simple, reliable basic
replication feature in the core system.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: [PERFORM] Memory question on win32 systems
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Upcoming back-branch update releases