Re: Core team statement on replication in PostgreSQL
От | Dimitri Fontaine |
---|---|
Тема | Re: Core team statement on replication in PostgreSQL |
Дата | |
Msg-id | 5966F428-2B4C-4383-B123-077D23DF9A55@hi-media.com обсуждение исходный текст |
Ответ на | Re: Core team statement on replication in PostgreSQL (Robert Treat <xzilla@users.sourceforge.net>) |
Ответы |
Re: Core team statement on replication in PostgreSQL
|
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'd first want to applaud core decision: having bare PostgreSQL propose a reliable and simple to set-up synchronous replication solution is an excellent perspective! ... Le 29 mai 08 à 23:42, Robert Treat a écrit : > I would have thought the read only piece would have been more > important than > the synchronous piece. In my experience readable slaves is the big > selling > point in both Oracle and MySQL's implementations, and people are not > nearly > as concerned if there is a small asynchronous window. ... Even more so when you're confronted to this exact problem. A fellow PG user ended up having both the WAL and the data replicated by DRBD (protocol C) and some heartbeat scripts to do the automatic failover. This wasn't easy to setup, and to some extend we're still concerned about the reliability part of it. We know about the "easy to use" part of it: we didn't get it. While at it, would it be possible for the "simple" part of the core team statement to include automatic failover? That would mean for current master when it's going to stop on error (fatal) to tell the slave to warm-up. Of course in case of more severe crash the slave would have to get started by other means, but covering the fatal error path and have the master restart as a slave would only add up to the reliability... wouldn't it? > It would also be easier to implement on some level; we have already > solved the > asynchronus wal shipping problem, so we would just need to solve the > read-only bits. For synchronus hot standby, you have to solve both the > synchronus shipping and the read-only bits. Seems like more work > with less > upside that read-only slaves vs. pitr warm standby we have now. > > Interesting that core views this differently. core seems to think read-only slave is more complex than synchronous slave, in term of slave read only long transaction and master vacuums for example. Regards, - -- dim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkg/Kk8ACgkQlBXRlnbh1bneKACeMK+fSp8VExctndo46X76NTxV atIAn2UYw1g/4RPddypqirrZcqg5C7gm =JeA6 -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления: