Re: Redundant databases/real-time backup-Revisited

Hi,

Tried by modifying /etc/rc.d/init.d/postgresql with following changes:
su -l postgres -c '/usr/bin/postmaster -i -D /var/lib/pgsql
/var/lib/pgsql/query_log 2>&1 &'

The file query_log is created. But it is remaining empty even after restart and
all sorts of transactions including insert statements.

Early thanks for any help

Wish you all a vey happy new 2001.

Lockhurst


> ----- Original Message -----
> From: "Ragnar Kjørstad" <postgres@ragnark.vestdata.no>
> To: "root" <root@dennis.veritime.com>
> Cc: <pgsql-admin@postgresql.org>
> Sent: Thursday, November 23, 2000 8:28 AM
> Subject: Re: [ADMIN] Redundant databases/real-time backup
>
> > On Thu, Nov 16, 2000 at 11:14:15AM -0500, root wrote:
> > > It is necessary to create/alter the postgresql startup script.  I have
> included
> > > a copy of mine.  The database to be mirrored must start up with logging
> > > enabled:
> > >
> > > su -l postgres -c '/usr/bin/postmaster -i -D/home/postgres/data
> >/home/postgres/data/query_log 2>&1 &'
> >
> > But why do you do 2>&1 in your startup-script? This will redirect data
> > on stderr to stdout - I don't think that is a good idea.
> >
> > > Other points:
> > > The query_log can get large rather quickly.  You cannot simply issue a
> rm -rf
> > > query_log, touch query_log and chmod.  Even with the appropriate
> permissions
> > > the daemon will not write to a new file, for some reason you must
> restart
> > > postgres using the startup script.  Perhaps one of the developers has an
> answer
> > > to this problem.....
> >
> > This is becuase the postgres deamon keeps the file open, and will keep
> > on writing to the old file even after you delete it. Most deamons will
> > reopen their log-files if you send them a HUP signal, so a possible
> > solution is:
> >
> > mv logfile logfile.1
> > kill -HUP <pid>
> > process logfile.1
> > rm logfile.1
> >
> > The order is important to make sure you don't have a race-condition.
> >
> > A different alternative is to use a FIFO instead of a normal file, and
> > process it continually istead of in batch-jobs.
> >
> >
> >
> >
> > A totally different approach would be to have a "sql-proxy" relay all
> > requests to two (or more) different servers to always keep them in sync.
> >
> >
> > --
> > Ragnar Kjørstad
> >