postgresql/contrib/rserv
Peter Eisentraut 264f8f2b6c Install dynamically loadable modules into a private subdirectory
under libdir, for a cleaner separation in the installation layout
and compatibility with binary packaging standards.  Point backend's
default search location there.  The contrib modules are also
installed in the said location, giving them the benefit of the
default search path as well.  No changes in user interface
nevertheless.
2001-09-16 16:11:11 +00:00
..
ApplySnapshot.in
CleanLog.in
GetSyncID.in Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00
InitRservTest.in
Makefile Install dynamically loadable modules into a private subdirectory 2001-09-16 16:11:11 +00:00
master.sql.in Install dynamically loadable modules into a private subdirectory 2001-09-16 16:11:11 +00:00
MasterAddTable.in
MasterInit.in Install dynamically loadable modules into a private subdirectory 2001-09-16 16:11:11 +00:00
MasterSync.in Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00
PrepareSnapshot.in
README.rserv Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00
regress.sh Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:28:05 +00:00
Replicate.in
rserv.c pgindent run. Make it all clean. 2001-03-22 04:01:46 +00:00
RServ.pm
RservTest.in
slave.sql.in
SlaveAddTable.in
SlaveInit.in Rename undocumented utility SyncSyncID to MasterSync. 2000-12-21 15:26:04 +00:00

erServer demonstration implementation
(c) 2000, Vadim Mikheev and Thomas Lockhart, PostgreSQL Inc.

Version 0.1:
  Replicates a master database to a single slave database.
  Tested under Linux (Mandrake 7.2).

Requirements:

- PostgreSQL >= 7.0.X
  A separate Makefile is required for PostgreSQL 7.0.x and earlier
- Perl5 and the PostgreSQL perl interface
- TCL and the PostgreSQL tcl interface (for demo only)


How to compile:

- make all
- make install

Scripts and libraries are installed in places which are consistant
with the way other contrib/ code is installed; underneath the core
items in a contrib/ directory.


The toolset:

MasterInit dbname
  sets up structures and user-defined functions for a master
  database. 

SlaveInit dbname
  sets up structures for a slave database. Does not include triggers,
  but only bookkeeping tables. 

MasterAddTable dbname table column
  sets up triggers for the specified table and column. Note that this
  column must be updated for replication to occur. 

SlaveAddTable dbname table column
  sets up bookkeeping for the specified table and column.

Replicate masterdb slavedb
  actually replicate changes from a master to single slave. Note that
  this must be repeated to replicate to multiple slaves, but the
  bookkeeping for each slave is handled separately so each can be
  updated at different times and with different sets of changes.

GetSyncID [--noverbose] slavedb
  returns the last syncid the specified slave has seen. May be used
  in conjunction with SyncSyncID and CleanLog using the --noverbose
  option.

MasterSync masterdb syncid
  registers a syncid with the specified master database. Used to
  propagate replication success back to the master database.

CleanLog masterdb syncid
  removes obsolete entries in the master database replication log
  table up to the specified replication sequence number.

Other utilities:

PrepareSnapshot
  build a file of replication information from the specified masterdb.

ApplySnapshot
  use a file of replication information to apply to the specified
  slavedb. 


How to run a demo:

Run the InitRservTest script. It will create two local databases
'master' & 'slave' with table 'test' in them. It accepts the following
arguments:
  --help
    Print a usage message and quit.
  --user name
    Access the database with another username.
  --host name
    Access a remote database. Note that the shared library *must* be
    visible in the same path as installed on the build machine.
  masterdb
  slavedb
    Names of test databases. Defaults to 'master' and 'slave',
	respectively.

Once the test databases are set up, simply updating the master table
is sufficient to log a replication event. You can update the table
test then run "Replicate master slave", or you can use the demo
program RservTest.

Run the tcl/tk GUI demo program, RservTest. It has a single window,
which has four buttons and three data entry boxes.

  --------------------------------------------------
 |   PostgreSQL Asynchronous Replication            |
 |        Master          Slave                     |
 |      < master    >   < slave      >              |
 |                                                  |
 |  [ Update    ]   <                         >     |
 |  [ Replicate ]                                   |
 |  [ Show      ]   ____________                    |
 |                                                  |
 |            [ Quit ]                              |
 |                                                  |
  --------------------------------------------------

The demo has the following behaviors:

If you enter a string into the data entry field to the right of
[Update], then that string will be used to either update the master
database or to query the slave database.

If you click [Update], then the string in the data entry box will be
entered into the master database.

If you click [Replicate], then all changes since the last replication
will be propagated to the slave database.

If you click [Show], then the slave database will be queried to find
the string in the data entry box to the right of the [Update]
button. If the string does not (yet) exist in the slave database, then
"n/a" will appear to the right of the [Show] button. If the string
does exist in the slave database, then it will be printed to the right
of the [Show] button.


Todo:
1. Support for multiple slave servers.
2. Explicit support for master/slave failover.
3. More docs.