Re: Using RSYNC for replication?
От | Andrew Sullivan |
---|---|
Тема | Re: Using RSYNC for replication? |
Дата | |
Msg-id | 20030129124826.M4935@mail.libertyrms.com обсуждение исходный текст |
Ответ на | Re: Using RSYNC for replication? ("Denis A. Doroshenko" <d.doroshenko@omnitel.net>) |
Список | pgsql-general |
On Wed, Jan 29, 2003 at 10:29:17AM +0200, Denis A. Doroshenko wrote: > What if there would be such a method: the database is "frozen", which > means, all commited work is flushed to the database, ongoing changes > are going to an alternative destination (kind of journal), while the > original database becomes read-only with the "journal" on top of it > (i.e. all inserts, updates and deletes made to journal are visible for > the clients); later once the database is unfrozen, the jorunal is joined > into the database (i.e. database is synched). > > Well, may be at least the above paragraph made you laughing. Doctors say Actually, there is nothing to laugh about in the proposal. Some commercial systems do it more or less like that. This is really a way of making point-in-time backups, and using them as a basis for replication, too. I think it may be a mistake to try to overload point-in-time recovery and replication, however. PostgreSQL stays remarkably close to the traditional UNIX approach of small, specialised tools that can be stuck together to do something larger. I like this approach, because it tends to localise bugs: a problem in one area doesn't cause you pain in another. That said, there is work going on with point-in-time for 7.4, so I suspect you'll be able to take this approach in the near-ish future. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
В списке pgsql-general по дате отправления: