Re: Using RSYNC for replication?

Поиск
Список
Период
Сортировка
От jhihn1
Тема Re: Using RSYNC for replication?
Дата
Msg-id 3E372618@webmail.umbc.edu
обсуждение исходный текст
Ответ на Using RSYNC for replication?  (Jason Hihn <jhihn1@umbc.edu>)
Ответы Re: Using RSYNC for replication?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Why isn't database data and system data seperate? I realize I'm stretching
ACID here, but  I think isolation also applies to databases themselves, and
from the system as well. At any given time, given an idle database, I should
be able to rip out the data and put a new in. Something as simple as
remounting the data directory to a [NFS] backup copy.

In my idea clog and WAL would be flushed and empty for the given databases.
Even if there is one set of logs for all the databases, as long as there are
no entries for the database being updated (and there won't be, because we
flushed them out) changing out the data should be simple. True, indexes should
be dumped and reloaded, but that is acceptible for me.

I don't understand what is so hard about doing it this way. It would make
replication so simple and fast. I'm attempting to do what amounts to a
file-system level backup, while still running. Normally a bad idea, but I am
in the situation that I can ensure that the clog and WAL are empty (for this
database anyway) and nothing is coming in.

If it can't do this, then it damn well should. Move clogs and WALs into each
database's directory so each is isolated. Put a call into Postgres (psql
function) to catch up on the logs. Then lock every table from writes (JIC),
perform the backup, unlock every table.

PS. Sorry my mailer dropped the subject. Fixed now.
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
Sent: Tuesday, January 28, 2003 10:51 AM
To: jhihn1
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL]


jhihn1 <jhihn1@umbc.edu> writes:
> Another problem, and this is a big one, is I can't shutdown my master
> postmaster here. I have queries running all the time on multiple databases
on
> 1 postmaster. I can make sure that nothing is running in the database that
is
> being updated, but I can't lock people out of the 600-some other databases
> under this postmaster. No way, uh-uh, never going to happen!

<blink>  You're expecting to rsync just one database out of an
installation?  Not a chance.  The WAL and clog files must be replicated
too, and those are shared across the whole installation.  And the
guaranteed-no-update condition must hold across the whole installation,
too.

Forget rsync; there is no way on earth that you have a prayer of making
that work.  Go look at the various existing replication projects (see
the link someone already provided).  One of them might suit your needs.

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster


В списке pgsql-general по дате отправления:

Предыдущее
От: Tomaz Borstnar
Дата:
Сообщение: Re: list server problems?
Следующее
От: Dennis Gearon
Дата:
Сообщение: stopping access to a database