Re: Using RSYNC for replication?
От | Denis A. Doroshenko |
---|---|
Тема | Re: Using RSYNC for replication? |
Дата | |
Msg-id | 20030129102917.H8476@hermit.omnitel.lan обсуждение исходный текст |
Ответ на | Re: Using RSYNC for replication? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Using RSYNC for replication?
|
Список | pgsql-general |
Do not like stepping in with thoughts on a subject that can already cause anger. Anyway, just a thought. 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 it is very healthy to laugh... :-) This is how I understand FFS (fast file system) snapshots work for background fsck and online backups. It is said to work in FreeBSD 5.0 (though I did not try it)... On Tue, Jan 28, 2003 at 01:39:43PM -0500, Tom Lane wrote: > jhihn1 <jhihn1@umbc.edu> writes: > > I don't understand what is so hard about doing it this way. > > If you want separate installations, make separate installations. Don't > expect multiple databases in a single installation to be implemented > with the same amount of overhead as separate installations would be. > If we did it that way, we'd legitimately get complaints. > > > It would make replication so simple and fast. > > No it wouldn't; as I've been trying to explain to you, there are a lot > of reasons why rsync'ing a database won't work. Fixing a few of them > doesn't produce a working solution. Nor are we going to contort the > system design to make a fundamentally wrongheaded approach to > replication work. rsync is just not the basis of a workable solution, > because it doesn't and can't know anything about the database state or > the semantics of the different files in the database. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Denis A. Doroshenko, GPRS engineer, d.doroshenko@omnitel.net, +37069863486 Omnitel Ltd., Muitines Str. 35, LT-2600 Vilnius, Lithuania; www.omnitel.lt
В списке pgsql-general по дате отправления: