db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Trivial Update of "ReplicationWriteup" by narayanan
Date Mon, 10 Mar 2008 11:43:57 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by narayanan:
http://wiki.apache.org/db-derby/ReplicationWriteup

------------------------------------------------------------------------------
  commit notification until sufficient number of copies of the database have been updated
  
  Adv
+ 
  Guarantees straightforward consistency
  
  Disadv
+ 
  Expensive because of message overhead and response time.
  
  === Lazy  (Asynchronous) ===
@@ -34, +36 @@

  back to the client.
  
  Adv
+ 
  Wide variety of optimizations since it allows to bundle changes of different transactions
and
  propagate updates on an interval basis to reduce communication overhead.
  
  Disadv
+ 
  Inconsistencies might result because of the delay in the propagation of the update information.
  
  == Who can perform updates ==
@@ -48, +52 @@

  All clients contact the same server for updates.
  
  Adv
+ 
  Simplifies the replica control, since updates take place in the primary and the replicas
apply
  only the changes that are propagated.
  
  Disadv
+ 
  The master copy is a bottleneck since all the transactions result in updates here.
  
  === Update Anywhere ===
@@ -59, +65 @@

  Update any server for updates.
  
  Adv
+ 
  Speeds up access since multiple masters can be updated simultaneously.
  
  Disadv
+ 
  Establishing agreement among different replicas in complex, since, conflicting transactions
  might have executed on different replicas and might result in transactions not only being
  stale but inconsistent too. Reconciliation to decide which transactions are winners and
which
@@ -103, +111 @@

  
  === Master Controller ===
  
- The derby module that implements the master mode of replication. It boots the other master
sub-systems viz. 
+ The derby module that implements the master mode of replication. It boots the other master
sub-systems viz.
- Replication Log Buffer, Replication Log Shipper and the Replication Message Transmitter
and acts as the central 
+ Replication Log Buffer, Replication Log Shipper and the Replication Message Transmitter
and acts as the central
  co-ordinator between them.
  
  Related JIRA Issue(s)
@@ -113, +121 @@

  
  === Replication Log Buffer ===
  
- All log records that are written to the local log file are also appended to the Replication
log buffer. The Derby 
+ All log records that are written to the local log file are also appended to the Replication
log buffer. The Derby
  logging system passes the log records to the Replication log buffer through the master controller.
The log buffer
  is needed for the following reasons
  
@@ -131, +139 @@

  
  === Replication Log Shipper ===
  
- Does asynchronous shipping of log records from the master to the slave being replicated
to. The implementation 
+ Does asynchronous shipping of log records from the master to the slave being replicated
to. The implementation
  does not ship log records as soon as they become available in the log buffer (synchronously),
instead it does log
  shipping in the following three-fold scenarios
  
@@ -139, +147 @@

  
  2) when a request is sent from the master controller (force flushing of the log buffer).
  
- 3) when a notification is received from the log shipper about a log buffer element becoming
full and the load on 
+ 3) when a notification is received from the log shipper about a log buffer element becoming
full and the load on
     the log buffer so warrants a ship.
  
  
@@ -170, +178 @@

  
  The Derby module that implements the slave mode of replication. It starts the Replication
log receiver and writes the log
  records that are received from the master to the derby logs. It also initiates recovery
upon receiving the failover command
- resulting in the eventual booting of the slave database. 
+ resulting in the eventual booting of the slave database.
  
  Related JIRA Issue(s)
  
@@ -181, +189 @@

  
  What follows below is the series of steps taken to configure replication on a local machine
in a client/server environment.
  
- Assumptions: 
+ Assumptions:
  
  1) The user knows how to start and stop the derby network server
     http://db.apache.org/derby/docs/dev/adminguide/tadmincbdjhhfd.html
  2) The user knows to use ij (the command line jdbc tool that comes with derby).
     http://db.apache.org/derby/docs/dev/tools/ctoolsij34525.html
  
- Step 1. 
+ '''Step 1.'''
  
  Create a master and the slave directories. (Assuming that the master directory is called
"master" and the slave directory
  is called "slave".
  
- Step 2.
+ '''Step 2.'''
  
  Start the derby network server that will house the replication master. Let this network
server run on port 1527.
  
@@ -202, +210 @@

  Where REPLICATION_SOURCE will point to the directory that contains the master and the slave
directory.
  portno in this case will be 1527.
  
- Step 3.
+ '''Step 3.'''
  
  start ij
  
  java org.apache.derby.tools.ij
  
- Step 4.
+ '''Step 4.'''
  
  Create the database that will be used during replication. Let this database be called replicationdb.
  
  ij> connect 'jdbc:derby://localhost:1527/replicationdb;create=true';
  
- Step 5.
+ '''Step 5.'''
  
  Freeze this database
  
  call SYSCS_UTIL.SYSCS_FREEZE_DATABASE();
  
- Step 6.
+ '''Step 6.'''
  
  Open another terminal, move to the slave directory, copy the master database from the master
directory.
  
  cd slave
  cp -rf ../master/replicationdb ./
-    
- Step 7.
+ 
+ '''Step 7.'''
  
  Start the network server that will house the replication slave. Let this network server
run on port 1528.
  
@@ -236, +244 @@

  Where REPLICATION_SOURCE will point to the directory that contains the master and the slave
directory.
  portno in this case will be 1528.
  
- Step 8.
+ '''Step 8.'''
  
  start ij
  
  java org.apache.derby.tools.ij
  
- Step 9.
+ '''Step 9.'''
  
  Start the slave.
  
@@ -250, +258 @@

  
  The connection attempt will hang until a successful connection from the master has been
received.
  
- Step 10.
+ '''Step 10.'''
  
  Move to the terminal in which the master database has been frozen and start the master
  
@@ -260, +268 @@

  
  ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: Replication slave
mode started successfully for database 'replicationdb'. Connection refused because the database
is in replication slave mode.
  
- Step 11.
+ '''Step 11.'''
  
  Excecute a few inserts and updates on the master
  
- Step 12.
+ '''Step 12.'''
  
  Attempt a failover on the master now
  
@@ -276, +284 @@

  
  Indicating that the master database has been shutdown after a failover attempt.
  
- Step 13.
+ '''Step 13.'''
  
  Now try connecting to the slave database (failed-over database, or the new master database)
  
  connect 'jdbc:derby://localhost:1528/replicationdb';
  
- Step 14.
+ '''Step 14.'''
  
  Verify that the transacations performed on the master were reflected on the slave also.
  

Mime
View raw message