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?  (Andrew Sullivan <andrew@libertyrms.info>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgresql 7.3.1 + readline
Следующее
От: "Alain RICHARD"
Дата:
Сообщение: Re : Getting results from a dynamic query in PL/pgSQL