HP 3000 Manuals HP 3000 Manuals
Setting Up Soft Resynchronization
This section discusses the steps in setting up soft resynchronization.
Regular ALLBASE/SQL statements are used for the creation of an
ALLBASE/Replicate DBEnvironment. Some ALLBASE/SQL statements have been
enhanced for use with ALLBASE/Replicate.
You may create an ALLBASE/SQL DBEnvironment in the following ways:
* Entering DDL (Data Definition Language) statements one at a time
through ISQL.
* Placing DDL statements in a single command file and executing that
file through ISQL.
* Creating several smaller command files, each of which groups
certain SQL DDL statements together for a common purpose, and
executing those files sequentially through ISQL.
In the following discussion, commands are grouped according to purpose.
You can use any of the three above techniques to generate the schema and
create the DBEnvironment. The following order for the creation of
DBEnvironment elements is useful, but not mandatory.
Step 1 \ - Creating the Master DBEnvironment
1. Use the START DBE NEW statement to specify all of the
ALLBASE/Replicate parameters with the exception of the AUDIT LOG
clause. You want to create the DBEnvironment and load it before
log records are generated. Therefore, do not specify AUDIT LOG
until START DBE NEWLOG is issued, because AUDIT LOG turns on the
generation of audit log records.
2. Specify a temporary log file name in the DBELogDefinition clause
of the START DBE NEW statement because permanent log files will be
created when START DBE NEWLOG is issued. The log file created in
this step (TempLog1) is a temporary log file that will later be
purged.
3. Create user-defined partitions, if used, with the CREATE PARTITION
statement.
4. Create tables using the CREATE TABLE statement. If you want to,
assign tables to partitions other than the default partition.
For example, use the following statements to create a part of an
ALLBASE/Replicate master DBEnvironment (MADBE1):
isql=> START DBE 'MADBE1' NEW
BUFFER = (240, 120),
TRANSACTION = 50,
DEFAULT PARTITION = 1,
COMMENT PARTITION = 2,
MAXPARTITIONS = 10,
AUDIT NAME = 'MAAUDIT1',
ALL AUDIT ELEMENTS,
DBEFILE0 DBEFILE MADBEF0
WITH PAGES = 300,
NAME = 'MADBEF0',
LOG DBEFile TEMPLOG1
WITH PAGES = 500,
NAME = 'TEMPLOG1';
isql=> CREATE PARTITION PARTSPARTITION WITH ID = 10;
isql=> CREATE PUBLIC TABLE PURCHDB.PARTS
(PARTNUMBER CHAR(16) NOT NULL,
PARTNAME CHAR(30),
SALESPRICE DECIMAL(10,2) )
IN PARTITION PARTSPARTITION
IN WAREHFS;
Step 2 \ - Loading the Master
Complete the following DBEnvironment creation activities:
* Do initial loading of the tables.
* Create views, and indexes.
* Specify the security structure for the DBEnvironment.
For example, statements similar to the following load data and create
indexes:
isql=> LOAD FROM INTERNAL DATA1 TO PURCHDB.PARTS;
isql=> CREATE INDEX ...
:
Statements similar to the following specify the security structure:
isql=> GRANT CONNECT TO MGR@PARTS;
isql=> GRANT SELECT ON PURCHDB.PARTS TO VISITORS;
Step 3 \ - Starting the Master DBEnvironment
Start the master DBEnvironment by using the START DBE NEWLOG statement.
Specify the AUDIT LOG clause to generate audit log records for the
DBEnvironment.
When you execute the START DBE NEWLOG statement for a DBEnvironment that
already has AUDIT LOG enabled, most ALLBASE/Replicate related options not
specifically changed will remain unchanged. The AUDIT LOG option is an
exception. If AUDIT LOG was specified earlier, and you execute START DBE
NEWLOG without specifying AUDIT LOG again, audit logging is disabled for
the entire DBEnvironment. Transaction information stored in the SCR
array would be removed. Avoid this situation because loss of the SCR
information will require a hard resynchronization.
For creating most DBEnvironments, the AUDIT LOG clause should be
specified through the START DBE NEWLOG statement only after the
DBEnvironment has been set up and initial data loaded. Using this method
ensures that audit log records are not generated during the initial data
load. Load performance is improved and log file space is decreased.
Enabling Audit Logging on the Master.
The following example illustrates the use of the START DBE NEWLOG
statement with the options for enabling audit logging.
isql=> START DBE 'MADBE1' MULTI NEWLOG
AUDIT LOG,
LOG DBEFILE LOG1
WITH PAGES=1000,
NAME='LOG1';
isql=> RELEASE;
Step 4 \ - Adding Log Files to the Master
ALLBASE/Replicate also requires that at least one additional log file be
added. The additional log file is created using the SQLUtil command,
ADDLOG. The temporary log file created earlier for the master
DBEnvironment, using START DBE NEW, is purged with the SQLUtil PURGEFILE
command.
isql=> SQLUTIL;
>> ADDLOG
DBEnvironment Name: MADBE1
Maintenance Word:
Enter Log File Name(s) Separated by a Blank? LOG2
New Log File Size? 1000
Add Log File (y/n)? y
Log file `LOG2' Was Added.
Log Identifier Is: 2
>> PURGEFILE
DBEFile Name: TEMPLOG1
Purge DBEFile (y/n): YES
>> EXIT
isql=> EXIT;
Add several additional log files to the master DBEnvironment. This
decreases the chances of encountering a log lock conflict error condition
or reaching the moving log lock point that ALLBASE/Replicate maintains.
This lock is maintained to prevent the overwriting of master log files
for transactions that have not yet committed on the slave. A log lock
does not prevent a log file from being backed up.
Step 5 \ - Verifying Master Startup Parameters
The values specified in START DBE NEW and START DBE NEWLOG statements for
ALLBASE/Replicate databases are stored in the DBECon file. Use the
SQLUtil SHOWDBE command to verify the parameters of a DBEnvironment. For
example, when you enter the SHOWDBE command after creation of the master
DBEnvironment, you might see the following:
isql=> SQLUTIL
>> SHOWDBE
DBEnvironment Name: MADBE1
Maintenance Word: Return
Output File Name (opt): Return
-> STARTPARMS
DBEnvironment Language: NATIVE 3000
AutoStart: ON
Audit Logging Is: ON
Audit Logging Name is: MAUDIT1
Default Partition ID is: 1
Maximum Number of Partitions Is: 10
Comment Partition ID Is: 2
Audit Elements Are: CHKPT, DATA, CMNT, DEFN, AUTH, STOR, SECT
user Mode: MULTI
DBEFile0 Name: MADBEF0
DDL Enabled: NO
No. of Runtime Control Block Pages: 128
No. of Data Buffer Pages: 240
No. of Log Buffer Pages: 200
Max. Transactions: 100
Maximum Timeout: NONE
Default Timeout: MAXIMUM
Authorize Once per session: OFF
Verify that the parameters displayed by the SQLUtil SHOWDBE command are
in agreement with your design requirements. If the parameters are
incorrect, correct them using an additional START DBE NEWLOG statement.
NOTE Be sure that you specify the AUDIT LOG clause and the correct
options for ARCHIVE LOG and DUAL LOG, if they are needed. Failure
to specify these options will turn off audit logging, dual logging,
and archive logging.
Step 6 \ - Backing up the Master DBEnvironment
NOTE After initializing the DBEnvironment, make a backup of the initial
state of the DBEnvironment. Make the backup from the master, or
from the slave DBEnvironment if the master DBEnvironment cannot
afford to delay the start of operations. An initial backup is
useful if you need to perform a hard resynchronization of the
DBEnvironment back to its original state. It is essential if you
are going to use a copy made with STOREONLINE to restore the
DBEnvironment.
Keep a record of the ALLBASE/Replicate option values.
Step 7 \ - Making Preparations on the Master for Slave Creation
After the master DBEnvironment is created, it can be used as a resource
for the creation of the slave DBEnvironment. There are several ways to
generate the slave from the master.
Use one of these methods if the entire master DBEnvironment is to be
replicated to a dedicated slave:
* Use the SQLUtil STORE or STOREONLINE commands to store an image of
the master DBEnvironment. With this method, the necessary SCR
information is automatically transferred to the slave in the copy
of the DBECon file created by this process. This is the most
efficient way to create the slave.
_________________________________________________________________
NOTE If you use STOREONLINE to do the store, when you restore the
DBEnvironment, you must reapply the log files containing the
transactions that were active on the master during the
STOREONLINE.
_________________________________________________________________
* Use SQLGEN to generate the schema for the master DBEnvironment.
Also use the UNLOAD command to unload the data from the desired
tables to later load, using the LOAD command, on the slave.
* Save the creation script that created the master, to use for
creating the slave. Use the same load files you used to load the
master or unload the data from the master DBEnvironment and load
it on the slave.
* Write a user-defined application to unload the desired data from
the tables.
* Transfer the SCR information (if it exists).
_________________________________________________________________
NOTE [REV BEG]
You must transfer the SCR information from the master to the
slave if all of the following conditions are true:
* You use UNLOAD/LOAD.
* Audit logging has been enabled on the master prior to
doing the UNLOAD.
* Transactions have been committed against the
partitions to be replicated.
There is no SCR information to be transferred unless all the
above are true.
_________________________________________________________________
ALLBASE/Replicate does not create an entry in the SCR array for a
partition until audit logging is enabled and at least one
transaction has committed against that partition.
If you are creating a slave by any method, prior to starting
activity against the master DBEnvironment, there is no SCR
information to be lost. After audit logging has been enabled on
the master for the replicated partitions, there will be SCR
information for any partition transactions have committed against.
Use the SQLAudit GET AUDITPOINT command to determine if any audit
point information exists. (Use the Display Audit Point
Information option with GET AUDITPOINT.) If SCR information
exists, use the SQLAudit tool to store the SCR information to a
file.[REV END]
Use one of these methods if a subset of the master DBEnvironment will be
replicated on the slave:
* Save the portions of the creation script for the subset of the
master DBEnvironment to be replicated on the slave. Use the
UNLOAD command to unload the data from the desired tables to later
load on the slave, using the LOAD command.
* Use SQLGEN to generate the schema for the subset to be replicated.
You must also UNLOAD the data from the desired tables to later
LOAD on the slave.
* Create a user-written application to unload the data you wish to
transfer to the slave.
NOTE When the slave is a copy of a subset of the master, you are
responsible for transferring the SCR information to the slave.
UNLOAD does not copy the DBECon file or the SCR array. Use the
SQLAudit tool to obtain the SCR information (if SCR information
exists).
Step 8 \ - Creating the Slave DBEnvironment
You can create the slave using any of these methods:
* Entering DDL (Data Definition Language) statements one at a time
through ISQL.
* Placing DDL statements in a single command file and executing that
file through ISQL.
* Creating several smaller command files, each of which groups
certain SQL DDL statements together for a common purpose, and
executing those files sequentially through ISQL.
* Restoring a DBEnvironment copied with STORE or STOREONLINE.
* Generating the slave using an appropriate application program.
Regardless of the method used to create the slave, the following issues
need to be addressed:
1. If you generate the slave DBEnvironment from a copy of the
original creation script, the START DBE NEW statement needs
modification. You must specify a unique new name for the AUDIT
NAME.
If you are using STORE or STOREONLINE to copy over the
DBEnvironment image from the master, change the AUDIT NAME when
you later use the START DBE NEWLOG statement to enable audit
logging.
2. If a single master is replicated to a dedicated slave, it is more
convenient to have the identical partition schema for easier
switching to the slave in case of master failure.
With more complex ALLBASE/Replicate configurations, the partition
schema on the slave may need to be different from the master,
especially if the slave also has partitions that will be masters
to some other DBEnvironment. If the partition structure of the
slave DBEnvironment will be different from that of the master, it
needs to be adjusted. Use the DROP PARTITION, CREATE PARTITION,
and ALTER TABLE statements to make the adjustments.
3. Tables must have the same TableName and OwnerName as on the
master, and the column names should be identical. The columns
must be defined in the same order in the slave tables as they are
in the master tables, and they must have identical data types as
their respective master columns.
You may adjust table types on the slave. For example, in a master
DBEnvironment used in an on-line transaction processing (OLTP)
application, tables might be of type PUBLICROW in order to give
the greatest concurrency when using UPDATE. Yet those same tables
in a slave used to offload read-only applications from the master
(using the RU isolation level) may benefit from being of type
PUBLIC READ. This will greatly reduce locking overhead in a
read-only slave environment.
The brief example below illustrates the statements for creating the slave
DBEnvironment, SLDBE1:
isql=> START DBE 'SLDBE1' NEW
BUFFER = (240, 120),
TRANSACTION = 50,
DEFAULT PARTITION = 1,
COMMENT PARTITION = 2,
MAXPARTITIONS = 10,
AUDIT NAME = 'SLAUDIT1',
DBEFile0 DBEFILE SLDBE1F0
WITH PAGES = 300,
NAME = 'SLDBE1F0',
LOG DBEFile TEMPLOG2
WITH PAGES = 500,
NAME = 'TEMPLOG2',
isql=> CREATE PARTITION PARTSPARTITION with ID = 10;
isql=> CREATE PUBLIC TABLE PURCHDB.PARTS
(PARTNUMBER CHAR(16) NOT NULL,
PARTNAME CHAR(30),
SALESPRICE DECIMAL(10,2) )
IN PARTITION PARTSPARTITION
IN WAREHFS;
Step 9 \ - Loading the Slave
For DBEnvironments you create using DDL statements, complete the
following DBEnvironment creation activities:
* Do initial loading of tables.
* Create views and indexes.
* Specify the security structure for the DBEnvironment.
For DBEnvironments that are created by copying the master using the STORE
or STOREONLINE commands:
* Make adjustments to views.
* Create indexes, if needed. Depending on the use of the slave, you
may need additional or fewer indexes. Indexes that exist on the
master should remain on the slave, for switching to the slave if
the master fails. The ALLBASE/Replicate engine on the slave takes
advantage of any appropriate available indexes.
* Adjust the security structure on the slave.
For example, statements similar to these load data and create indexes:
isql=> LOAD FROM INTERNAL DATA1 TO PURCHDB.PARTS;
isql=> CREATE INDEX ...
:
Use statements similar to the following to adjust the security structure:
isql=> REVOKE SELECT ON PURCHDB.PARTS FROM VISITORS;
isql=> GRANT SELECT ON PURCHDB.PARTS TO MGR@PARTS;
Step 10 - Starting the Slave DBEnvironment
The slave DBEnvironment can be created with the same options as the
master except that a unique AUDIT NAME is needed. If the slave was
created using a copy made with STORE or STOREONLINE, you must specify a
new audit name when you use the START DBE NEWLOG statement to enable
audit logging on the slave. If the slave DBEnvironment is created from
scripts, the correct AUDIT NAME can be specified in the original START
DBE NEW statement.
WARNING It is your responsibility to ensure that the AUDIT NAME for the
slave DBEnvironment is unique because ALLBASE/Replicate makes no
check for uniqueness.
Enabling Audit Logging on the Slave.
The following example illustrates specification of audit log parameters
on the slave:
isql=> START DBE 'SLDBE1' MULTI NEWLOG
AUDIT LOG,
AUDIT NAME = 'SLAUDIT1'
COMMENT DATA AUDIT ELEMENTS
LOG DBEFILE LOG1
WITH PAGES=1000,
NAME='LOG1';
isql=> RELEASE;
Step 11 - Adding Log Files to the Slave
You must add one or more log files using the SQLUtil ADDLOG command. The
slave temporary log file can be purged using the SQLUtil PURGEFILE
command.
isql=> SQLUTIL;
>> ADDLOG
DBEnvironment Name: SLDBE1
Maintenance Word:
Enter Log File Name(s) Separated by a Blank? LOG2
New Log File Size? 1000
Add Log File (y/n)? Y
Log file `LOG2' Was Added.
Log Identifier Is: 2
>> PURGEFILE
DBEFile Name: TEMPLOG2
Purge DBEFile (y/n): YES
>> EXIT
isql=> EXIT;
Step 12 - Verifying Slave Startup Parameters
The values specified in START DBE NEW and START DBE NEWLOG statements for
ALLBASE/Replicate databases are stored in the DBECon file. Use the
SQLUtil SHOWDBE command to verify the parameters of a DBEnvironment. For
example, when you enter the SHOWDBE command after creation of the slave
DBEnvironment, you might see the following:
isql=> SQLUTIL
>> SHOWDBE
DBEnvironment Name: SLDBE1
Maintenance Word: Return
Output File Name (opt): Return
-> STARTPARMS
DBEnvironment Language: NATIVE 3000
AutoStart: ON
Audit Logging Is: ON
Audit Logging Name is: SLAUDIT1
Default Partition ID is: 1
Maximum Number of Partitions Is: 10
Comment Partition ID Is: 2
Audit Elements Are: CHKPT, DATA, CMNT, DEFN, AUTH, STOR, SECT
user Mode: MULTI
DBEFile0 Name: SLDBE1F0
DDL Enabled: NO
No. of Runtime Control Block Pages: 128
No. of Data Buffer Pages: 240
No. of Log Buffer Pages: 200
Max. Transactions: 100
Maximum Timeout: NONE
Default Timeout: MAXIMUM
Authorize Once per session: OFF
Verify that the parameters displayed by the SQLUtil SHOWDBE command are
in agreement with your design requirements. If the parameters are
incorrect, correct them using an additional START DBE NEWLOG statement.
NOTE Be sure that you specify the AUDIT LOG clause, and the correct
options for ARCHIVE LOG and DUAL LOG if they are needed. Failure
to specify these options will turn off audit logging, dual logging,
and archive logging.
Step 13 - Backing up the Slave DBEnvironment
NOTE After initializing the DBEnvironment, make a backup of the initial
state of the DBEnvironment. An initial backup is useful if you
need to perform a hard resynchronization of the DBEnvironment back
to its original state. It is essential if you are going to use a
copy made with STOREONLINE to restore the DBEnvironment.
Keep a record of the ALLBASE/Replicate option values.
Step 14 - Setting Soft Resynchronization Options on the Slave
The ALLBASE/Replicate soft resynchronization applications are designed
with options that allow you to customize how the applications execute.
All of these options have default settings that reflect the most likely
values. These options can be changed using environment variables. Table
3-1 shows the options you can set and their respective values.
In order to use an option, you must set the appropriate environment
variable before starting the soft resynchronization application. For
example, to set the transaction priority to be used, issue the following
commands before executing the slave resynchronization application:
: SETJCW RESYNCpriority 100
: RUN REPSLAVE.PUB.SYS
Slave Soft Resynchronization Application Options
Table 3-1.
-----------------------------------------------------------------------------------
| | | | |
| Env. Variable | Application | Value | Meaning |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCpriority | slave | 0 .. | Tells the slave resynchronization |
| | | 255 | application the transaction priority |
| | | | to use when it applies the |
| | | | transaction to its DBEnvironment. |
| | | | The default is 127. The value |
| | | | supplied must be in the range of 0 |
| | | | through 255 (inclusive). Refer to |
| | | | the ALLBASE/SQL Reference Manual for |
| | | | the BEGIN WORK statement for more |
| | | | information on this option. |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCdebug | slave or | 1 | Tells either resynchronization |
| | master | | application to print progress |
| | | | messages. This is especially useful |
| | | | for debugging. The default of 0 is |
| | | | to work silently. |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCtrxfile | slave | 1 | Tells the slave resynchronization |
| | | | application to prompt for a |
| | | | transaction file name. This |
| | | | transaction file is used when |
| | | | transactions are too large to fit |
| | | | into the allocated buffers of the |
| | | | application. The default of 0 |
| | | | automatically creates a temporary |
| | | | file. This option is only needed |
| | | | when you expect extremely large |
| | | | transactions and need to create the |
| | | | file where there is sufficient disk |
| | | | space. |
| | | | |
-----------------------------------------------------------------------------------
Step 15 - Starting the Soft Resynchronization Process on the Slave
To start the soft resynchronization process, run the slave
resynchronization application, REPSLAVE, against the slave DBEnvironment.
The slave application needs to know:
* The name of the DBEnvironment serving as slave.
* The partitions you want to resynchronize.
* The name of the network socket that will be used to transfer
information from the master to the slave.
Starting the Replicate Application on the Slave.
The slave application is started first with the following command:
: RUN REPSLAVE.PUB.SYS
The following shows the prompts issued by the slave application and the
syntax for the respective parameters:
Enter Slave DBE Name >> SlaveDBEName
Enter Partition Number (RETURN to finish): PartitionNumber (or RETURN)
Enter the Socket Name you wish to use (max 16 chars) >> SocketName
where:
SlaveDBEName is the name of the slave DBEnvironment.
PartitionNumber is the Partition Number you want to replicate as it is
or RETURN defined on the master. This parameter tells REPSLAVE
which partitions need to be soft resynchronized. This
prompt continues asking for partition numbers until you
enter a carriage return.
Issue the SQLUtil command SHOWDBE for the master
DBEnvironment to determine the default and comment
partition numbers if you want to replicate the default
and comment partitions. These values were set when the
START DBE NEW or the START DBE NEWLOG statement was
executed.
The partition numbers for the DEFINITION, STORAGE,
AUTHORIZATION, or SECTION partitions, respectively, are
as follows:
-2 DEFINITION
-3 STORAGE
-4 AUTHORIZATION
-5 SECTION
For example, if you want to resynchronize the DEFINITION
and SECTION partitions, then -2 and -5 must be entered.
SocketName is the socket name needed by the NET IPC networking
software to assign a name to the connection between the
master and slave resynchronization applications. You
must enter this same socket name when you run the master
resynchronization application (REPMAST). The maximum
length of this name is 16 characters.
Starting Slave Replication with DDL Partitions.
In the following example, the DEFAULT PARTITION, the COMMENT PARTITION,
the PartsPartition (with ID = 10), and the partitions that replicate DDL
information are the partitions to be synchronized. The DEFAULT and
COMMENT partition numbers were assigned by the START DBE NEW statement
executed earlier. The partition "purchptn" with a PartitionNumber of 10
was created with the CREATE PARTITION statement, and the tables
PurchDB.SupplyPrice and PurchDB.Vendors were associated with purchptn
using the ALTER TABLE statement. The default PartitionNumbers for the
partitions that replicate DDL information are defined on the previous
page.
The sample prompts and their respective replies are as follows:
: RUN REPSLAVE.PUB.SYS
Enter Slave DBE Name >> SLDBE1
Enter Partition Number (RETURN to finish): 1
Enter Partition Number (RETURN to finish): 2
Enter Partition Number (RETURN to finish): 10
Enter Partition Number (RETURN to finish): -2
Enter Partition Number (RETURN to finish): -3
Enter Partition Number (RETURN to finish): -4
Enter Partition Number (RETURN to finish): -5
Enter Partition Number (RETURN to finish): Return
Enter the Socket Name you wish to use (max 16 chars) >> MA1TOSL1
Step 16 - Obtaining the Slave Nodename
You can determine the slave nodename for the master by running
NMMGR.PUB.SYS on the slave system. Consult your network administrator
for help.
Step 17 - Setting Soft Resynchronization Options on the Master
The ALLBASE/Replicate soft resynchronization applications are designed
with options that allow you to customize how the applications execute.
All of these options have default settings that reflect the most likely
values. These options can be changed using environment variables. Table
3-2 shows the options you can set and their respective values.
In order to use an option, you must set the appropriate environment
variable before starting the soft resynchronization application. For
example, to set the transaction priority to be used, issue the following
commands before executing the slave resynchronization application:
: SETJCW RESYNCpriority 100
: RUN REPSLAVE.PUB.SYS
Master Soft Resynchronization Application Options
Table 3-2.
-----------------------------------------------------------------------------------
| | | | |
| Env. Variable | Application | Value | Meaning |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCsleep | master | 1 .. 60 | Tells the master resynchronization |
| | | | application how many seconds to |
| | | | sleep if it is unable to find |
| | | | transactions to send to the slave. |
| | | | The default setting for this option |
| | | | is 3 seconds. |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCdebug | slave or | 1 | Tells either resynchronization |
| | master | | application to print progress |
| | | | messages. This is especially useful |
| | | | for debugging. The default of 0 is |
| | | | to work silently. |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCrptnotrx | master | 1 | Tells the master resynchronization |
| | | | application to print a message when |
| | | | it is unable to find any |
| | | | transactions for the slave. The |
| | | | default of 0 is to handle this |
| | | | silently. |
| | | | |
-----------------------------------------------------------------------------------
| | | | |
| RESYNCstoplog | master | 1 | Tells the master application to stop |
| | | | the soft resynchronization process |
| | | | when it runs out of transactions to |
| | | | send to the slave. This option is |
| | | | useful when you run soft |
| | | | resynchronization only periodically |
| | | | at a predetermined time rather than |
| | | | continuously, such as when the log |
| | | | records retrieved by a wrapper |
| | | | DBEnvironment are being applied to |
| | | | the slave. This option works well |
| | | | when used in conjunction with |
| | | | RESYNCrptnotrx option that prints a |
| | | | message when the master cannot find |
| | | | any transactions for the slave. The |
| | | | default of 0 is to run soft |
| | | | resynchronization continuously. |
| | | | |
-----------------------------------------------------------------------------------
Step 18 - Starting the Soft Resynchronization Process on the Master
In the following examples, the master application is called REPMAST and
the slave application is called REPSLAVE.
To start the soft resynchronization process, run the master
resynchronization application REPMAST against the slave DBEnvironment.
The master application needs to know:
* The name of the DBEnvironment serving as master.
* The name of the socket which was specified on the slave.
* The node name for the slave DBEnvironment.
For testing purposes, you may start the replication application
interactively, but later develop a batch job script to run the program.
Start the master ALLBASE/Replicate soft resynchronization application by
executing the following command:
: RUN REPMAST.PUB.SYS
The following shows the prompts issued by the master application and the
syntax for the respective parameters:
Enter Master DBE Name >> MasterDBEName
Enter the Socket Name you wish to use >> SocketName
Enter the Node Name of the Slave DBE >> SlaveNodeName
where:
MasterDBEName is the name of the master DBEnvironment.
SocketName must be the same socket name that you entered when
starting the slave resynchronization application.
Because the reply to the slave application prompt named
the socket, the same SocketName must be specified so the
master can find the connection on the slave system.
SlaveNodeName is the system where the slave resynchronization
application is running. The SlaveNodeName tells the
master resynchronization application where to search for
the connection specified by the SocketName.
You can determine this name by running NMMGR.PUB.SYS on
the slave system. Consult your network administrator
for help.
For example, the prompts and their respective replies might be as
follows:
Enter Master DBE Name >> MADBE1
Enter the Socket Name you wish to use >> MA1TOSL1
Enter the Node Name of the Slave DBE >> CALVIN
Establishing a Network Connection.
When you start REPMAST and REPSLAVE, the master and slave applications
communicate with each other by establishing a network connection using
the NET IPC network communication interface.
While the two applications are connecting with each other, you may see a
message similar to, "Attempting to establish connection." This usually
means that the other application is not started, or the application is
not able to locate the connection.
When the master and slave applications are connected with each other, you
should see a message similar, to "Have established connection with Slave
(or Master) Resynchronization Application." The soft resynchronization
applications should then start running against both the master and slave
DBEnvironments.
The most common problems encountered with starting the soft
resynchronization process relate to networking. Some possible problems
are as follows:
* The node name of the slave system is inaccurate.
* The socket name specified for the master is not the same as the
socket name specified for the slave.
* AUDIT LOG has not been specified on either the master or the
slave.
* The master and slave applications are running on the same system,
and the system has not been configured to allow a loop-back for
the network. In a loop-back configuration, the network is used to
access the same system where the network command originated.
Consult your network administrator for setting up a loop-back
configuration.
* The DBEnvironment was specified with an incorrect group or
account.
For most networking problems, consult the network administrator for help.
Step 19 - Testing the Process on the Master
Connect to the master DBEnvironment, perform some transactions (UPDATE or
INSERT statements), and commit them to test whether the resynchronization
applications are successfully applying transactions to the slave
DBEnvironment.
Step 20 - Testing the Process on the Slave
Connect to the slave DBEnvironment and use appropriate SELECT statements
to check whether the changes that were made to the master were replicated
to the slave DBEnvironment. Commit work to ensure that locks are not
being held that impede the master and slave applications from replicating
transactions.
If the transactions are not being successfully replicated, check that the
following are true:
* The transactions are committed on the master (only committed
transactions are replicated.)
* The list of partitions given to the slave resynchronization
application is correct. For example, if you have committed
changes against a table belonging to partition number 10 on the
master, then to replicate the changes, you must enter 10 as one of
the partition numbers given to the slave. (The partition numbers
given to the slave identify the partitions that are replicated
from the master, and have no connection with the partitions that
the table may be associated with on the slave.)
* The resynchronization applications did not encounter a hard
resynchronization situation for the given partition. For example,
if the log files did not go far enough back to contain the last
master transaction committed for partition number 10, no
transactions would be replicated. See the section, "Type of
Resynchronization Used for a Specific Failure Mode", in chapter 2,
for a list of hard resynchronization situations.
* No process or user is holding locks on slave DBEnvironment tables
that would prevent the slave resynchronization application from
applying the transactions to the DBEnvironment. (This is
particularly important for ISQL users who often forget to
frequently commit work.)
Step 21 - Removing Test Transactions from the Master
Remove the test transactions from the master DBEnvironment using the
appropriate UPDATE or DELETE statements to reverse the action of the test
transactions. Remember to commit work.
Step 22 - Verifying Removal of Test Transactions from the Slave
Execute appropriate SELECT statements against the slave DBEnvironment to
verify that the action of the test transactions has been undone.
Remember to commit work.
Step 23 - Terminating the Soft Resynchronization Process
To shut down the soft resynchronization process, terminate either the
master or slave application. The other application will automatically
terminate itself. In some cases, the other application may take a while
to terminate, but it should eventually finish. One exception to this is
if the slave application is waiting on locks to apply the transactions to
the slave DBEnvironment. In this case, you may need to terminate the
slave application explicitly, if the locks are not being released quickly
enough.
You can stop the application on the master or the slave using BREAK from
the active terminal, or ABORTJOB for the appropriate process number from
another terminal.