Re: Core team statement on replication in PostgreSQL
От | Merlin Moncure |
---|---|
Тема | Re: Core team statement on replication in PostgreSQL |
Дата | |
Msg-id | b42b73150805291203q7e2bc7f5ga551958556be532d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Core team statement on replication in PostgreSQL (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Core team statement on replication in PostgreSQL
|
Список | pgsql-hackers |
On Thu, May 29, 2008 at 12:19 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > That's not what Tom's email said, AIUI. "Synchronous" replication surely > means that the master and slave always have the same set of transactions > applied. Streaming <> synchronous. But streaming log shipping will allow us > to get get closer to synchronicity in some situations, i.e. the window for > missing transactions will be much smaller. > > Some of us were discussing this late on Friday night after PGcon. ISTM that > we can have either 1) fairly hot failover slaves that are guaranteed to be > almost up to date, or 2) slaves that can support read-only transactions but > might get somewhat out of date if they run long transactions. The big > problem is in having slaves which are both highly up to date and support > arbitrary read-only transactions. Maybe in the first instance, at least, we > need to make slaves choose which role they will play. I personally would be thrilled to have slaves be query-able in any fashion, even if 'wrong' under certain circumstances. Any asynchronous solution by definition gives the wrong answer on the slave. Read only slave is the #1 most anticipated feature in the circles I run with. It would literally transform how the database world thinks about postgres overnight. This, coupled with easier standby setup (a pg_archive to mirror pg_restore) would be most welcome! merlin
В списке pgsql-hackers по дате отправления: