HP 3000 Manuals

ALLBASE/Replicate User's Guide

Entire DBEnvironment to Dedicated Slave 

This section discusses issues related to replicating an entire master
DBEnvironment to another entire, dedicated slave DBEnvironment.  In this
case the slave is identical in structure to the master.

Three aspects of ALLBASE/Replicate operation are addressed in this
section:

   *   Setting up Soft Resynchronization.
   *   Recovering from Soft Resynchronization Interrupts.
   *   Switching Master and Slave Roles.


          Figure 5-1.  Configuration #1 - Entire DBEnvironment to Dedicated Slave 

For this discussion, assume the DBEnvironment is configured as shown in
Figure 5-1 .  It uses the sample DBEnvironment, PartsDBE. The majority
of the tables are in the DEFAULT partition (although not all of them are
shown in the figure).  Two tables, PurchDB.SupplyPrice (T1) and
PurchDB.Vendors (T2), are in a separate partition, partition 10.  No
tables are in the NONE partition, and the COMMENT audit element is
enabled.  Only one master and one slave ALLBASE/Replicate application are
used for the replication process.

The purpose of the slave in this example is to offload read-only
applications so that OLTP activities on the master may proceed more
efficiently.  No partitions are set up on the slave, and the slave has no
tables that are being replicated to any other DBEnvironment.
Nevertheless, there is some discussion about how to set up partitions on
the slave when they are needed by your application.

Setting up Soft Resynchronization 

The activities involved in the setting up of soft resynchronization are
addressed in the same order as you perform them:

   1.  Creating the Master DBEnvironment.
   2.  Loading the Master.
   3.  Starting the Master DBEnvironment.
   4.  Adding Log Files to the Master.
   5.  Verifying Master Startup Parameters.
   6.  Backing up the Master DBEnvironment.
   7.  Making Preparations on the Master for Slave Creation.
   8.  Creating the Slave DBEnvironment.
   9.  Loading the Slave.
  10.  Starting the Slave DBEnvironment.
  11.  Adding Log Files to the Slave.
  12.  Verifying Slave Startup Parameters.
  13.  Backing up the Slave DBEnvironment.
  14.  Setting Soft Resynchronization Options on the Slave.
  15.  Starting the Soft Resynchronization Process on the Slave.
  16.  Obtaining the Slave Nodename.
  17.  Setting Soft Resynchronization Options on the Master.
  18.  Starting the Soft Resynchronization Process on the Master.
  19.  Testing the Process on the Master.
  20.  Testing the Process on the Slave.
  21.  Removing Test Transactions from the Master.
  22.  Verifying Removal of Test Transactions from the Slave.
  23.  Terminating the Soft Resynchronization Process.

Step 1 \ - Creating the Master DBEnvironment.   

The master schema is created in the same way you would create a schema
for a non-ALLBASE/Replicate DBEnvironment.  In either a command file or
an application, begin with the START DBE NEW statement and follow it with
all statements necessary to create the entire DBEnvironment including
DBEFileSets, DBEFiles, tables, indexes, constraints, security and
whatever elements you wish to include.

In the START DBE NEW statement, include all the necessary audit
parameters except the AUDIT LOG clause.  When replicating an entire
master to a dedicated slave that is an exact copy of the master, consider
specifying the AUDIT ELEMENTS that replicate DDL activity from the master
to the slave (DEFINITION, STORAGE, AUTHORIZATION, SECTION or ALL).

As you create the master schema, create partitions using the CREATE
PARTITION statement before creating tables, then include your partition
assignments in the appropriate CREATE TABLE statements.  This eliminates
the need to use the ALTER TABLE statement after the DBEnvironment is
created.

Step 2 \ - Loading the Master.   

Include statements to load the tables with initial data at this step so
you will have a complete DBEnvironment for copying to the slave.

After you have created the schema, execute the command file through ISQL
or execute the application.

If you did not create partitions in the previous step, create them now.
Use the ALTER TABLE statement to assign tables to the appropriate
partitions.

Step 3 \ - Starting the Master DBEnvironment.   

All ALLBASE/Replicate related parameters, except AUDIT LOG, should have
been set in the START DBE NEW statement.  You must specify AUDIT LOG in
the START DBE NEWLOG statement in order to turn on audit logging.  In
addition, if you are using archive mode logging, you must specify ARCHIVE
LOG or else the DBEnvironment will revert to non-archive logging.  If you
are using dual logging, you must specify DUAL LOG or the DBEnvironment
will revert to single logging.

Step 4 \ - Adding Log Files to the Master.   

Remember to add at least one new log file.  If the DBEnvironment is going
to be used as the backup for the master in the event the master fails, or
is used to replicate transactions to another DBEnvironment, consider the
value of using dual logging to ensure that you do not lose log records
that would be vital during the hard resynchronization process.

Step 5 \ - Verifying Master Startup Parameters.   

Use the SQLUtil SHOWDBE ALL and SHOWLOG commands to verify that all
parameters for the master DBEnvironment are set appropriately before you
invoke the ALLBASE/Replicate application on the slave.

Step 6 \ - Backing up the Master DBEnvironment.   

After you have created the DBEnvironment, make a copy for backup
purposes.  Use SQLUtil STORE (if you are using non-archive logging), or
use SQLUtil STOREONLINE (if you are switching to archive logging after
initial loading).  Keep a record of the ALLBASE/Replicate option values.

Step 7 \ - Making Preparations on the Master for Slave Creation.   

Review Step 7 in chapter 3, "Soft Resynchronization."

Step 8 \ - Creating the Slave DBEnvironment.   

The most efficient way to create the slave DBEnvironment in this
configuration is to restore the copy you made of the master.  Use SQLUtil
RESTORE if you are doing non-archive logging, or use the restore commands
associated with STOREONLINE if you are doing archive mode logging.

You can instead use the same creation scripts and load files that created
the DBEnvironment.

You may want to change the table type for tables that are being used in a
read-only mode.  These tables may have been type PUBLICROW in the master
DBEnvironment to increase concurrency in an OLTP environment.  However,
in a read-only environment this granularity of locking is excessive and
will cause more locking overhead than necessary.  Changing the table type
to PUBLIC or PUBLICREAD will greatly decrease the locking overhead
without increasing the occurrence of deadlocks if the Read Uncommitted
(RU) isolation level is used.  If the Repeatable Read (RR) isolation
level is used on slave tables, it would increase the occurrence of
deadlocks.

If you plan to switch to the slave DBEnvironment in the event the master
fails, you may retain the same partition structure that exists on the
master DBEnvironment.  This causes the generation of audit log records on
the slave and uses additional log space.  However, you need those log
records later when you switch roles and use the slave as a master.

If you do not plan to use the slave as a backup for the master, you can
only specify the CHECKPOINT audit element when starting the slave
DBEnvironment, and no audit log records will be produced on the slave.

Step 9 \ - Loading the Slave.   

Load tables, create views and indexes, and specify security structures
for the DBEnvironment, if it is created using DDL statements.  Make
adjustments where needed to views, indexes, and security structures, if
the DBEnvironment was copied from the master.

Step 10 - Starting the Slave DBEnvironment.   

The majority of the audit log related clauses in the START DBE NEWLOG
statement were specified when the master DBEnvironment was created.

It is imperative that you specify the AUDIT LOG clause in the START DBE
NEWLOG statement, if SCR information exists.  If the master DBEnvironment
used archive mode logging, you must specify the ARCHIVE LOG clause if you
wish to retain archive logging on the slave.  You must specify the DUAL
LOG clause, if the master DBEnvironment used dual logging, and you wish
to continue dual logging on the slave.

If the DBEnvironment will be used as the backup for the master in the
event the master fails, or is used to replicate transactions to another
DBEnvironment, consider using dual logging to ensure that you do not lose
log records that would be vital during the hard resynchronization
process.

You must also be sure to specify a new, unique AUDIT NAME for the slave
DBEnvironment.

Specify a value for MAXPARTITIONS that will accommodate all partitions
for the DBEnvironment.  Be sure to count as a partition:

   *   Each partition being replicated to the slave.
   *   Each audit element being replicated to the slave (except the DATA
       audit element).
   *   Each partition being replicated from the slave (if the slave is
       also serving as a master).
   *   Each audit element being replicated from the slave (if the slave
       is also serving as a master).
[REV BEG]

For example, if you specify that the partitions to be replicated are 1,
2, -2, and -3 (DEFAULT and COMMENT partitions, and the DEFINITION and
STORAGE audit elements), you must set the value for MAXPARTITIONS to no
less than 4.

If, in addition, the slave is also serving as a master, and the DEFAULT
and COMMENT partitions on the slave (having different partition numbers
than those same partitions on the master) are being replicated to some
other DBEnvironment, you must set the value for MAXPARTITIONS to no less
than 6.[REV END]

Step 11 - Adding Log Files to the Slave.   

Remember to add at least one new log file, using the SQLUtil ADDLOG
command.

Step 12 - Verifying Slave Startup Parameters.   

Use the SQLUtil SHOWDBE ALL and SQLUtil SHOWLOG commands to verify that
all parameters for the slave DBEnvironment are set appropriately before
you invoke the ALLBASE/Replicate application on the slave.  Make sure
that you have made all changes needed to modify any parameters set on the
master that would be incompatible with slave operation.

Step 13 - Backing up the Slave DBEnvironment.   

After you have created the DBEnvironment, make a copy for backup
purposes.  Use SQLUtil STORE (if you are using non-archive logging) or
use SQLUtil STOREONLINE (if you are switching to archive logging after
initial loading).  Keep a record of the ALLBASE/Replicate option values.

Step 14 - Setting Soft Resynchronization Options on the Slave.   

If you want to insure that ALLBASE/Replicate transactions do not get
rolled back in deadlock situations, set the environment variable
RESYNCpriority so that ALLBASE/Replicate transactions have priority in
deadlock situations.  A value of 0 is the highest priority, 255 is the
lowest priority, and 127 is the default priority.  A value of 100 insures
that ALLBASE/Replicate transactions take priority if all other
transactions are running at the default priority of 127.

Huge transactions sometimes exceed the buffer space allocated in your
application, and you need to insure that the temporary overflow space
automatically created by ALLBASE/Replicate is created in a group large
enough to hold the overflow.

If you expect some huge transactions, set the environment variable
RESYNCtrxfile with a file name which is in a group large enough to handle
the overflow.

Step 15 - Starting the Soft Resynchronization Process on the Slave.   

Refer to Step 15 in chapter 3, "Soft Resynchronization."

If you are replicating DDL activities and have specified the DDL audit
elements in the START DBE NEW statement for the master, be sure to
specify the default partition numbers for the DDL partitions when you
answer the startup prompts for the ALLBASE/Replicate slave application
(DEFINITION -2, STORAGE -3, AUTHORIZATION -4, and SECTION -5).  (An
example is in the section, "Starting Slave Replication with DDL
Partitions," in Step 15 of chapter 3.)

Step 16 - Obtaining the Slave Node Name for Starting the Master.  [REV
BEG]

Be sure to obtain the slave nodename for use when initiating the soft
resynchronization process on the master.  You can determine this name by
running NMMGR.PUB.SYS on the slave system at the operating system
prompt.[REV END]

Step 17 - Setting Soft Resynchronization Options on the Master.   

By default, the master resynchronization application sleeps for 3 seconds
if it cannot find committed transactions to send to the slave.  Then it
looks again for transactions.  To change the default, set the RESYNCsleep
environment variable before invoking the ALLBASE/Replicate master
application, REPMAST. The application can sleep from 1 to 60 seconds.

Step 18 - Starting the Soft Resynchronization Process on the Master.   

Soft resynchronization is started on the master as described in Step 18
of chapter 3, "Soft Resynchronization." Specify the same SocketName you
specified when you started the slave application, and the NodeName for
the machine on which the slave is running.

Step 19 - Testing the Soft Resynchronization Applications on the Master. 

Apply some UPDATE or INSERT test transactions to the master that can
easily be removed after testing is complete.  Commit work.

Step 20 - Testing the Soft Resynchronization Applications on the Slave.   

Verify on the slave that the transactions were successfully applied using
appropriate SELECT statements.  As you verify your results, commit your
transactions so you do not hold any locks that would keep the
ALLBASE/Replicate applications from applying replicated transaction to
the slave.

Step 21 - Removing Test Transactions from the Master.   

Remove the test transactions from the master using the appropriate UPDATE
or DELETE statements.  Commit work.

Step 22 - Verifying Removal of Test Transactions from the Slave.   

Use appropriate SELECT statements to verify that the test transactions
have been removed from the slave.  Commit test transactions to release
locks that would impede the replicate applications.

Step 23 - Terminating the Soft Resynchronization Process.   

Use BREAK from the active terminal or ABORTJOB from another terminal.

Recovering from Soft Resynchronization Interruptions 

Use either soft resynchronization or hard resynchronization to recover
from soft resynchronization interruptions.  If it is possible, soft
resynchronization is usually preferable because it is simpler, less time
consuming, and disrupts operations less.  In those cases where soft
resynchronization is impossible, or would take longer than hard
resynchronization, use hard resynchronization.  Refer to the section,
"Type of Resynchronization Used for a Specific Failure Mode," in chapter
2 for more details.

Using Soft Resynchronization to Recover the Slave.   

For short interruptions, restart the soft resynchronization process.  At
the time of interruption, check that the master adds additional log space
if necessary.  This insures that log records for transactions not yet
been committed on the slave are not overwritten on the master before soft
resynchronization restarts.

Using Soft Resynchronization to Recover the Master.   

If you have used hard resynchronization to recover the master from the
slave, and if the slave has been in the master role during hard
resynchronization, there will be additional transactions on the slave not
yet applied to the master.  These transactions must be transferred to the
old master before it can resume its master role.  You can use soft
resynchronization from the slave (acting in the role of master) to
transfer the remaining transactions from the slave to the master before
the master resumes its master role.  Temporarily stop activity on the
slave (acting as master) so that the original master (acting as slave)
can catch up.  Then switch roles and have the old master and slave resume
their original roles.

Using Hard Resynchronization to Recover in a Static Environment.   

If you are using non-archive logging, there are two methods available to
you for hard resynchronization of the DBEnvironment:

   *   ISQL UNLOAD/LOAD

   *   SQLUtil STORE/RESTORE

Using the ISQL UNLOAD/LOAD commands is the only method that allows you to
keep a non-archive DBEnvironment in operation while you store the data
needed for hard resynchronization.  The SQLUtil STORE/RESTORE commands
require you to stop the operation of the DBEnvironment.

You must lock the tables while they
are being stored and until you obtain the necessary SCR information for
the associated partition.  You can allow the remainder of the source
DBEnvironment to remain in operation while the UNLOAD is taking place.
(This assumes that the problem on the slave is such that you can remove
old data from the tables on the slave, and reload them with the new
data.)

If the actual DBEnvironment is so damaged that the table structure itself
is damaged, or you can no longer access the target DBEnvironment, then
STORE/RESTORE must be used as the hard resynchronization method.  The
source DBEnvironment operation must be halted during the STORE process.

Using Hard Resynchronization to Recover in a Dynamic Environment.   

If you are using archive logging, the methods available to you for hard
resynchronization of the slave are:

   *   ISQL UNLOAD/LOAD

   *   SQLUtil STOREONLINE and associated restore commands

If you are dealing with only one or a few tables, you can use ISQL
UNLOAD/LOAD. However, you must lock the tables while the UNLOAD on the
source is taking place and until you obtain the correct SCR information.

If you need to hard resynchronize the entire DBEnvironment, you can use
SQLUtil STOREONLINE and its associated restore commands.  STOREONLINE
will obtain the appropriate SCR information for you, and users can
continue to access the master DBEnvironment for both reading and writing
activities.

Switching Master and Slave Roles 

When switching master and slave roles, you must be certain to replicate
all transactions committed on the DBEnvironment currently acting as
master to the DBEnvironment currently acting as slave before the roles
are switched.

If you are switching from a failed master (and will be using the current
slave as a temporary master), use a wrapper DBEnvironment.  Use it to
transfer to the slave the transactions contained in the master log files,
not yet replicated to the slave.

If you are switching from the slave (used as a temporary master) back to
the repaired master, you can use soft resynchronization.  Use it to
insure that the most recently committed transactions on the slave
(temporary master) are transferred to the original master (before it
resumes its original role).

MPE/iX 5.0 Documentation