Re: Using RSYNC for replication? - Mailing list pgsql-general

From Rick Gigger
Subject Re: Using RSYNC for replication?
Date
Msg-id 010f01c2c775$95447d70$0a00000a@grouch
Whole thread Raw
In response to Re: Using RSYNC for replication?  (jhihn1 <jhihn1@umbc.edu>)
Responses Re: Using RSYNC for replication?
List 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.

Maybe you should consider using mysql if that is what you want.  Mysql works
that way.  Each database is entirely encapsulated in it's own directory.


pgsql-general by date:

Previous
From: Christoph Dalitz
Date:
Subject: Re: psql command line question..
Next
From: "Rick Gigger"
Date:
Subject: Re: embedded postgres