HP 3000 Manuals

ALLBASE/Replicate User's Guide

Other Configurations 

The following sections contain discussions of issues unique to these
configurations:

   *   Subset of a DBEnvironment to a Dedicated Slave

   *   Multiple Masters to One Slave

   *   Two-way Replication

   *   Conversion of an Existing DBEnvironment for ALLBASE/Replicate

Only those items that are significantly different from the discussion of
the replication of an entire DBEnvironment to a dedicated slave are
mentioned in the following sections.

Subset of a DBEnvironment to a Dedicated Slave 

This section discusses issues unique to the configuration in which a
subset of the master DBEnvironment is replicated to another dedicated
slave DBEnvironment that is identical in structure to the subset being
replicated.

For this discussion, assume the DBEnvironment is configured as shown in
Figure 5-2 .  It uses the sample DBEnvironment, PartsDBE. The majority
of the tables are in the NONE 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.  The
COMMENT audit element has been enabled.  Only one master and one slave
ALLBASE/Replicate application are used for the replication process.  The
slave DBEnvironment is a copy of the tables PurchDB.SupplyPrice and
PurchDB.Vendors, and is called PurchDBE.

The purpose of this slave is to offload read-only applications for a
group of users who will make no entries in the DBEnvironment and are
interested in only the SupplyPrice and Vendors tables.  This allows OLTP
activities on the master to be more efficient.  There are no partitions
set up on the slave, and the slave has no tables that are being
replicated to another DBEnvironment.


          Figure 5-2.  Configuration #2 - Subset of DBEnvironment to Dedicated Slave 

Step 1 \ - Creating the Master DBEnvironment.   

In the START DBE NEW statement, include all the necessary audit
parameters except the AUDIT LOG clause.  When replicating a subset of a
master to a dedicated slave that is a copy of the subset, do not specify
the AUDIT ELEMENTS that replicate DDL activity from the master to the
slave (DEFINITION, STORAGE, AUTHORIZATION, SECTION or ALL). These audit
elements would cause replication of changes to tables in the master that
are not associated with the replicated partition.  This could cause
errors on the slave or halt the replication process if DDL audit elements
are specified as partitions to replicate, when starting REPSLAVE.

Have a process in place to guarantee that when you make changes to the
schema of the master affecting tables in the replicated partition, those
changes are made immediately to the slave.


NOTE  You cannot use the slave to completely recover the master in case
      of master failure because you are replicating only a subset to the
      slave.  (You can use the slave to recover the partition being
      replicated).  Use archive mode logging on the master to avoid
      manually reentering transactions lost since the last backup of the
      master.


Step 8 \ - Creating the Slave DBEnvironment.   

The most efficient way to create the slave DBEnvironment depends on how
large a subset of the original DBEnvironment you are replicating to the
slave.  If you are replicating most of the master DBEnvironment to the
slave, restore a copy of the master using SQLUtil RESTORE (if you are
doing non-archive logging) or use the restore commands associated with
STOREONLINE (if you are doing archive mode logging).  Then, delete those
parts that are not replicated.

If the subset of the DBEnvironment you are replicating is small, modify
the creation scripts and load files used to create the DBEnvironment on
the master.  Create only the replicated portion of the DBEnvironment.

Since you probably will not use this slave to back up the master, specify
only the CHECKPOINT audit element.  Then no audit log records are
produced on the slave.

Step 10 - Starting the Slave DBEnvironment.   

If you are creating the slave by copying the master, the majority of the
audit log related clauses in the START DBE NEWLOG statement were
specified when the master was created.  If you create the slave by using
a modified copy of the master creation script, you can make changes to
the START DBE NEW statement before creating the DBEnvironment.

It is imperative that you specify the AUDIT LOG clause in the START DBE
NEWLOG statement so that you do not lose the SCR information (if any is
present).  You must specify the ARCHIVE LOG clause to continue in that
mode on the slave.  To continue dual logging on the slave, you must
specify the DUAL LOG clause.

You must specify a new, unique AUDIT NAME for the slave DBEnvironment.

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

Soft resynchronization is initiated as described in Step 15 of chapter 3,
"Soft Resynchronization." In this configuration you should not replicate
DDL. Do not specify the default partition numbers for the DDL partitions
when you answer the startup prompts for the ALLBASE/Replicate slave
application.

Multiple Masters to One Slave 

This section discusses issues unique to the configuration where several
master DBEnvironments or their subsets are replicated to one slave
DBEnvironment.  The slave is identical in structure to the collection of
master DBEnvironments or subsets being replicated.

For this discussion, assume the DBEnvironment is configured as shown in
Figure 5-3 .  Three master DBEnvironments, each at a different site,
are replicating committed transactions to a slave at the headquarters
location.

For all tables, except the RecDB tables, there is a one-to-one
correspondence between each table in a master and some table on the
slave.

At each master site, the RecDB tables contain information only about
clubs and activities at the local site.  The RecDB tables at the slave
site each receive information from all three master sites and reflect all
club activity throughout the entire enterprise.  Therefore, each RecDB
table at a given master site is a horizontal subset of the information
held in its corresponding table at the slave site.  (For example, all
three RecDB.Clubs tables at each of the three master sites replicate data
to the one RecDB.Clubs table at the slave site.  Each RecDB.clubs table
at a master site contains only clubs at that site, while the RecDB.Clubs
table at the slave site contains all the clubs for all three masters.)

The purpose of the slave in this example is to collect all information on
the operation of the entire enterprise from all remote sites.  It is a
read-only database for decision support purposes for management.

There are no partitions set up on the slave, and the slave has no tables
being further replicated to another DBEnvironment.

   *   Master A contains the tables PurchDB.SupplyPrice and
       PurchDB.Vendors.  Master A also contains horizontal subsets of the
       tables RecDB.Clubs, RecDB.Members, and RecDB.events.

   *   Master B contains the tables ManufDB.SupplyBatches,
       ManufDB.TestData, PurchDB.Parts, and PurchDB.Inventory.  Master B
       also contains horizontal subsets of the tables RecDB.Clubs,
       RecDB.Members, and RecDB.events.

   *   Master C contains the tables PurchDB.Orders, PurchDB.OrderItems
       and PurchDB.Reports.  Because long field data cannot be
       replicated, PurchDB.Reports is a read-only table for purposes of
       this example, and is not replicated.  Master C also contains
       horizontal subsets of the tables RecDB.Clubs, RecDB.Members, and
       RecDB.events.

   *   The slave DBEnvironment is identical to the sample DBEnvironment
       PartsDBE. It is a collection of all the tables contained in the
       three separate masters.


          Figure 5-3.  Configuration #3 - Multiple Master DBEnvironments to One Slave 

Step 1 \ - Creating the Master DBEnvironment.   

In the START DBE NEW statement include all the necessary audit parameters
with the exception of the AUDIT LOG clause.  Specify a unique audit name
for each of the three masters.

You cannot specify the DDL audit elements (DEFINITION, STORAGE,
AUTHORIZATION, SECTION or ALL) when replicating multiple masters to a
single slave.

Manually Replicated DDL Activities - Timing Issues.   

Have some process in place to guarantee that when you make changes to the
schema of the master affecting tables in the replicated partition, those
changes are also made immediately to the slave.  You must pay careful
attention to the timing of manually replicated DDL activities.

For example, consider a case where you drop a table and re-create it with
one less column on the master.  You should not execute the same DDL
change on the slave until all transactions on the master that use the old
record format have completed replication on the slave.  If you make the
changes prematurely, the replicated records of the old format will not
fit the new table definition, and an error will occur.

The best course of action is:

   1.  Quiesce the master so that no new changes are made to the data in
       the master table.
   2.  Wait until the slave has caught up with the master.
   3.  Make the appropriate DDL changes to the slave table.
   4.  Resume operations against the master.


NOTE  If you are replicating only a subset to the slave, you cannot use
      the slave to completely recover the master in case of master
      failure.  (You could use the slave to recover the partition being
      replicated.)  Consider using archive mode logging on the master to
      avoid manually reentering transactions lost since the last backup
      of the master.


Step 3 \ - Starting the Master DBEnvironments.   

For each of the three masters, all ALLBASE/Replicate related parameters,
except audit logging, 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.  If you are using archive mode
logging, you must specify ARCHIVE LOG, or it will revert to non-archive
logging.  If you are using dual logging, you must specify DUAL LOG, or it
will revert to single logging.

You can create the slave DBEnvironment in this configuration by
collecting all the appropriate DDL statements from each of the master
DBEnvironment creation scripts into one script.  Then execute that script
on the slave.

You can load each of the tables with the same load scripts and data you
used to load the tables originally on the masters.

You cannot use RESTORE or the restore commands associated with
STOREONLINE because you will not get correct DBECon file or SCR
information for the entire slave.

Do not use the slave as a backup for the master unless you replicate the
entire master to the slave.  Specify only the CHECKPOINT audit element
and no audit log records will be produced on the slave.

Step 10 - Starting the Slave DBEnvironment.   

When you create the slave by invoking a modified copy of the master
creation script for all three masters, you can make changes to the START
DBE NEW statement before DBEnvironment creation time.

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

You will have to invoke three instances of REPSLAVE on the slave, one for
each of the masters from which the slave will be receiving audit log
records.  Do not specify the default partition numbers for the DDL
partitions when you answer the startup prompts for the ALLBASE/Replicate
slave application.

You must specify a different, unique SocketName for each instance of
REPSLAVE, but use the same NodeName for each of the three application
instances.  Obtain the slave NodeName for use when initiating the soft
resynchronization process on the masters.

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

For each of the three masters, soft Resynchronization on the master is
started as described in Step 18 in chapter 3, "Soft Resynchronization."
Specify the appropriate SocketName you specified when you started each of
the three slave applications and the NodeName for the machine on which
the slave is running.

Using Soft Resynchronization to Recover the Master.   

For each of the masters, if you are replicating the entire master to the
slave (and if you specify the DATA audit element on the slave to generate
audit log records), you can recover the master data from the slave after
the master DBEnvironment has been recreated.

If you are only replicating a subset of the master to the slave, it is
unlikely that you will use the slave to recover the master.

Using Hard Resynchronization to Recover the Master.   

For each master that you are replicating entirely to the slave, only use
ISQL UNLOAD/LOAD to recover the master from the slave.  Be sure to
transfer the SCR information in an appropriate manner.

For each master that you are replicating only a subset to the slave, you
cannot recover the entire master from the slave.  In this case, consider
using archive mode logging, dual logging, or both to guarantee
recoverability for the master in case of failure.

UNLOAD/LOAD.   

If the entire master must be recovered, you can recreate the master
DBEnvironment from scripts and obtain the data from the slave using ISQL
UNLOAD/LOAD.

If the DBECon file and system tables are still intact on the master, you
can recreate any damaged tables from scripts, and obtain the data from
the slave using UNLOAD/LOAD.

You must also transfer the SCR information.  Use the SQLAudit GET
AUDITPOINT and MODIFY AUDITPOINT commands.

Two-Way Replication 

This section discusses issues unique to the configuration of two master
DBEnvironments in two-way replication.  A subset of the first
DBEnvironment is replicated to the second, and a separate, disjoint
subset of the second is replicated to the first.

In this configuration, both DBEnvironments have partitions containing
tables acting in a master role, and other partitions containing tables
acting in a slave role.  At no time is a cycle allowed between the two
DBEnvironments.  No single row can receive both direct and indirect
updates.

For this discussion, assume the DBEnvironment to be configured as shown
in Figure 5-4 .

The DBEnvironment MASLDBE4A has tables in partition 17 that are
replicating committed transactions to their counterparts in DBEnvironment
MASLDBE4B. At the same time, MASLDBE4B has tables in partition 18 that
are replicating committed transactions to their counterparts in
MASLDBE4A. DBEnvironment MASLDBE4A has some tables that are not being
replicated.  They have been placed in the NONE partition.  MASLDBE4B also
has tables which are not being replicated and have been placed in the
NONE partition in that DBEnvironment.  There are two pairs of
master/slave applications running between the two DBEnvironments.  Each
one is connected by a separate network connection, with its own, unique
SocketName.  There are no cycles.  No tables acting in the slave role are
sending transactions back to the table from which they are receiving
committed transactions.


          Figure 5-4.  Configuration #4 - Two Way Replication 

Creating the DBEnvironments.   


NOTE  Because you are replicating only a subset of one DBEnvironment to
      the other, you cannot use one DBEnvironment to completely recover
      the other.  You could use the slave tables in each DBEnvironment to
      recover the partition being replicated.


To recover the most recently committed transactions from the tables
acting in a master role, you are dependent on a viable and accessible set
of log records from the DBEnvironment containing the tables acting in a
master role.  Consider using archive mode logging, dual logging, or both
on each DBEnvironment to avoid manually reentering transactions lost
since the last backup of the master.

After you create the DBEnvironment, make a copy for backup using SQLUtil
STORE (if you are using non-archive logging) or SQLUtil STOREONLINE (if
you are switching to archive logging after initial loading).  This is
especially important in this configuration, where only a subset of the
DBEnvironment is being replicated.

Starting the Soft Resynchronization Process.   

Invoke one instance of REPSLAVE on each DBEnvironment for the tables that
will be receiving committed transactions from tables on the other
DBEnvironment.  Do not specify the DDL partitions when you answer the
startup prompts for the ALLBASE/Replicate slave application.  You must
specify a different, unique SocketName for each instance of REPSLAVE, and
on each machine there will be a unique NodeName.

Using Soft Resynchronization to Recover Tables Acting in the Master Role. 

For each of the tables acting in a master role, you can use the table
acting in the slave role in case the master fails.  You can recover the
master data from the slave after the master DBEnvironment has been
recreated.

There is a problem in recovering the transactions executed against master
role tables, but not yet committed on the slave role tables at the time
of the failure.  You can use a wrapper DBEnvironment to recover the log
files containing those transactions if either of the following is true:

   *   You used dual logging, and one log file is still intact.
   *   You used single logging, and the single log file is still intact.

After a wrapper DBEnvironment has been established (but before you use
slave role tables to temporarily assume the master role), you can
replicate the untransmitted log records from the wrapper DBEnvironment to
the slave role tables.  This avoids losing transactions that were
committed on the master role tables.

There will be additional transactions on the slave tables not yet applied
to the master, if both of the following are true:

   *   You have just used hard resynchronization to recover a subset of
       the master from slave tables that were acting as temporary
       masters.
   *   Those tables have been in operation (in the master role) during
       the hard resynchronization.

These transactions must be transferred to the old master tables before
they can resume their master role.  You can use soft resynchronization
from the slave tables (acting in the role of temporary master) to
transfer the remaining transactions from the slave tables to the master
tables before the master tables resume their master role.  Temporarily
stop activity on the slave tables (acting in the master role) so that the
original master tables (acting in the slave role) can catch up, then let
the tables resume their original role.

Conversion of an Existing DBEnvironment for ALLBASE/Replicate 

This section discusses issues related to converting existing
DBEnvironments for use as ALLBASE/Replicate DBEnvironments.  For this
example assume a configuration in which an existing, entire DBEnvironment
(PartsDBE) will be replicated to another existing, entire DBEnvironment
(PartsDBE) that is identical in structure to the first.

This section addresses only one aspect of ALLBASE/Replicate operation,
setting up soft resynchronization.  After soft resynchronization is set
up, the recovery from soft resynchronization interrupts and switching
master and slave roles will be identical to previous discussions.
Depending on the configuration of the DBEnvironments to be converted,
refer to one of the four previous sections.

For this discussion assume the DBEnvironment is configured as shown in
Figure 5-5 .  It uses the sample DBEnvironment, PartsDBE. The majority
of the tables are placed 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 has been
enabled.  Only one master and one slave ALLBASE/Replicate application are
being 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.  There are no partitions set up on the slave, and the slave
has no tables that are being replicated to another DBEnvironment.
Nevertheless, there is some discussion about how to set up partitions on
the slave when they are needed by your application.


          Figure 5-5.  Configuration #5 - Converting Existing DBE to ALLBASE/Replicate DBE 

Step 1 \ - Creating the Master DBEnvironment.   

In this example, the master schema is already created and the
DBEnvironment has been built and loaded by the execution of that schema.

Create the appropriate partition structure using the CREATE PARTITION
statement and use the ALTER TABLE statement to assign tables to the
appropriate partitions.

Step 3 \ - Starting the Master DBEnvironment.   

In the original START DBE NEW statement none of the necessary audit
parameters were specified.  Set them appropriately by using the START DBE
NEWLOG statement.

You must specify all necessary ALLBASE/Replicate parameters, including
AUDIT LOG, and a new, unique AUDIT NAME in the START DBE NEWLOG statement
in order to turn on audit logging.

You could replicate the DDL partitions in this example because the slave
DBEnvironment is an exact copy of the master.  Specify the appropriate
DDL AUDIT ELEMENTS in the START DBE NEWLOG statement (DEFINITION,
STORAGE, AUTHORIZATION, and SECTION) if you plan to replicate DDL
actions.

To continue archive mode logging, you must specify ARCHIVE LOG. To
continue dual logging, you must specify DUAL LOG.

When you have completed execution of the START DBE NEWLOG statement, use
the SQLUtil ADDLOG command to add at least one additional log file.

Step 8 \ - Creating Slave DBEnvironment.   

If the DBEnvironment intended as the slave is identical to the master in
both the structure and the data entries, you can directly convert an
existing DBEnvironment for use a slave.

If you have made modifications as suggested in the previous topics, or if
the data is not consistent between the two DBEnvironments, the most
efficient way to create the slave DBEnvironment is to restore a copy of
the master.  Use SQLUtil RESTORE (if you are doing non-archive logging)
or use the appropriate restore commands associated with SQLUtil
STOREONLINE (if you are doing archive mode logging).

If you are modifying an existing DBEnvironment to convert it to a slave
instead of using a copy from the master, consider how you plan to use the
slave.

If the slave contains tables replicated to some DBEnvironment, create the
necessary partitions to support that activity.  Use the CREATE PARTITION
statement and associate the existing tables with the appropriate
partitions using the ALTER TABLE statement.

If you are using a copy of the master DBEnvironment, again consider its
use.  If the slave is a backup for the master, retain the same partition
structure that exists on the master DBEnvironment.  This will cause the
generation of audit log records on the slave DBEnvironment.  The log
records will be needed later, if you switch master and slave roles.

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

Step 10 - Starting the Slave DBEnvironment.   

Unless you are using a copy of the master to create the slave, none of
the audit log related clauses in the START DBE NEWLOG statement will have
been specified when the master DBEnvironment was created.

You must use the START DBE NEWLOG statement to insure that all
appropriate audit log related parameters are set.  It is imperative that
you specify the AUDIT LOG clause, or you will lose the SCR information,
if it is present.  Specify the ARCHIVE LOG clause to continue in that
mode.  Specify the DUAL LOG clause to continue dual logging on the slave.

Specify a new, unique AUDIT NAME for the slave DBEnvironment.

Specify a value for MAXPARTITIONS to accommodate all partitions involved.
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 (for master role
       tables).
   *   Each audit element being replicated from the slave (for master
       role tables).

If this DBEnvironment contains tables that are being replicated to some
other DBEnvironment, specify the appropriate AUDIT ELEMENTS to support
the generation of the desired audit log records.

Add at least one new log file using the SQLUtil ADDLOG command.  If the
DBEnvironment will be used as the backup for the master in the event the
master fails, or 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.

MPE/iX 5.0 Documentation