Re: [Gnumed-devel] database replication with bucardo

[Karsten Hilbert]

On Sat, Aug 18, 2012 at 01:19:13PM +0200, Slappinjohn wrote:

> > can you describe the other solution. I would like to put something in
> > the blog and in the wiki
> 
> as Karsten suggested in the first place, I did the diff-patch-workaround:
> 
> As far as I won't need access on both places this will work quite well.
> 
> on the first PC I run this script as root:
> 
> #!/bin/bash
> 
> cd /home/marc/gnumed/backups
> 
> pg_dump -C -v -U gm-dbo -f new.sql gnumed_v17 2>/dev/null
> 
> diff old.sql new.sql > diff.sql
> 
> su marc -c "scp -P 10022 diff.sql
> destinationserver:/home/marc/gnumed/backups/"
> 
> mv new.sql old.sql
> 
> 
> on the remote side (or via ssh in the same script, however you like it):
> 
> #!/bin/bash
> 
> cd /home/marc/gnumed/backups
> 
> patch old.sql diff.sql
> 
> cp old.sql /tmp/
> 
> su postgres -c "psql -c 'drop database gnumed_v17;'"
> 
> su postgres -c "psql < /tmp/old.sql"
> 
> gm-adjust_db_settings gnumed_v17
> 
> /etc/init.d/postgresql reload

You may want to consider throwing in a bit of sanity
checking. If you run

        gm-fingerprint_db.py

on both the first PC and - after restoring the patched SQL -
on the remote end, and then diff the output - them files
really should be identical.

Personally I would also sha512 both the dumped SQL from
which I create the patch to transfer and the remote SQL
after patching. Them hashes should also be identical. Such
could be foregone if one were to use rsync for transfer of
the full SQL.

All of this can be scripted, of course.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346