Skip site navigation (1) Skip section navigation (2)

Redundant databases/real-time backup

From: root <root(at)dennis(dot)veritime(dot)com>
To: pgsql-admin(at)postgreSQL(dot)org
Subject: Redundant databases/real-time backup
Date: 2000-11-16 16:14:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Several people have expressed an interest in having the capability to have real
time redundancy.  I am releasing my kludge solution to the mailing list in hope
that others might expand upon it.

First, you should dump your database, drop it, and recreate it on the computer
to be mirrored.  You should also create a fresh copy on the mirroring computer.
Most likely, your OIDs are still not going to be in synch.  For those of you
that use OIDs as a poor man's primary key, it will be necessary for you to
write a script that can sync up the oids on both computers (probably best run
as a cron script too).  I have thought about ways to do this, but I'll leave
that to someone else to complete.  (PLEASE POST YOUR RESULTS THOUGH!)

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

su -l postgres -c '/usr/bin/postmaster -i -D/home/postgres/data >/home/postgres/data/query_log 2>&1 &'

In this case I have specified a file called query_log that will maintain a copy
of all of the queries that have been executed.   I have included a complete
copy of my startup script called (unimaginatively) postgresql.  For linux users,
it should be in /etc/rc.d/init.d

I have also attached my pg_options file.  For me, this resides in
/home/postgres/data.  I have found that this file does not seem to affect my
query_log, but I incude it for reference for others to use.

Next, you should create a line in your /etc/crontab or /var/spool/cron/root file
to execute the redundancy script with root level permissions:

0-59/5 * * * * /root/

You should install the and scripts in the same

You will, of course, need to modify these scripts to work.  Several of my dead
ends are still in the scripts commented out. is set up to work with qmail instead of sendmail.  You should
be able to substitute the path to your sendmail program and it should work
fine, i.e. /usr/sbin/sendmail instead of /var/qmail/bin/qmail-inject

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.....

Also, my script does not check for network problems....

The script takes a lot of overhead.  For high volume inserts and deletes,
depending on how often you run, sometimes it just cannot keep up. can bog down and crash your server if the backlog becomes too

Also, I chose to allow it to pass SELECT statements and get back the results
from the remote database......I beleive that if you do not use sub-selects, you
may grep -v 'SELECT' and improve your performance significantly.

Please email comments and suggestions/modifications to me at
rhampton(at)veritime(dot)com or root(at)veritime(dot)com

Attachment: postgresql
Description: application/x-shellscript (2.5 KB)
Attachment: pg_options
Description: text/plain (35 bytes)
Description: application/x-perl (1.1 KB)
Description: application/x-perl (4.1 KB)


pgsql-admin by date

Next:From: turing2000Date: 2000-11-16 16:24:52
Previous:From: Dronamraju RajeshDate: 2000-11-16 15:48:51
Subject: Re: V7.0.3 on Solaris 2.7

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group