Message-ID: <696349285.786630.1386539014295.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_786629_1689330496.1386539014294" ------=_Part_786629_1689330496.1386539014294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This document should get you up and running with a replicated PostgreSQL= database in just a few steps. We'll gloss over many details in the interes= t of getting you up and running as quickly as possible. To make things simp= le, this document will use the sample cluster configuration found in the &q= uot;bruce/sample" directory of the distribution. The example uses a si= ngle PostgreSQL installation with 4 databases.=20
bruce_config- This database contains the cluster configur= ation metadata. This includes cluster names and identifiers, master databas= e uri's and descriptive names, slave database uri's and descriptive names, = and regular expression patterns to determine which tables are replicated.= li>=20
bruce_master- The master database. All modifications to r= eplicated tables are made to this database and subsequently replicated to e= ach slave.
bruce_slave_1- A slave database. All modifications to the= master database are replicated here.
bruce_slave_2- A slave database. All modifications to the= master database are replicated here.
The master and each slave have a
replication_test schema an=
replication_test.replicate_this table that we will replica=
te across the cluster.
Note: This demonstration makes the assumption that = all replicated clusters in the schema contain identical data.=20
The steps in this guide are loosely followed in test/src/com/netblue/bru= ce/SetupClusterFromExistingDbAcceptanceTest.java=20
tar xvzf bruce-0.1a.tgz
chmod 755 *.sh
vi config.xml(change db urls to point to your databases f= or each node)
./admin.sh -data ../sample/config.xml -initnodeschema -initsnapsh= ots MASTER -loadschema -operation CLEAN_INSERT -url jdbc:postgresql://local= host:5432/bruce_config?user=3Dbruce -pass bruce
-data ../sample/config.xml tells us what data file to load. the sample f= ile contains 1 master and 2 slaves with replication patterns to recognize t= he replication_test.* tables.=20
-initnodeschema tells us to install the replication schema on each node,= along with the triggers for each replicated table. If the schema is alread= y installed, then only the replication triggers are installed for each repl= icated table. For master nodes, if there is no data in the snapshotlog tabl= e (as in this case) a snapshot of the db is taken.=20
-initsnapshots MASTER tells us to set the slave snapshot status to the l= ast snapshot in the master database. Since the -initnodeschema option initi= alizes this for us, we'll use that.=20
-loadschema tells us to install the replication node topology schema on = the configuration database. This is only really useful the first time you r= un the admin tool for a given configuration database.=20
-operation CLEAN_INSERT tells us to drop everything from the node topolo= gy configuration database before inserting these new nodes=20
-url is the URL for the configuration database=20
-pass is the password for the configuration database=20