Rocket Software UniVerse 11.2.3 U2 Data Replication User Guide
Below you will find brief information for U2 Data Replication UniVerse 11.2.3. The U2 Data Replication UniVerse 11.2.3 is a feature that helps UniVerse databases to be synchronized across multiple systems. This allows you to have a standby system that can take over in case of a failure, or to create a reporting backup.
Advertisement
Advertisement
Rocket UniVerse
U2 Data Replication for UniVerse
Version 11.2.3
April 2014
UNV-1123-REP-1
2
Notices
Edition
Publication date: April 2014
Book number:
UNV-1123-REP-1
Product version: Rocket UniVerse V11.2.3
Copyright
© Rocket Software, Inc. or its affiliates 1985-2014. All Rights Reserved.
Trademarks
Rocket is a registered trademark of Rocket Software, Inc. For a list of Rocket registered trademarks go to: www.rocketsoftware.com/about/legal . All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names of their respective owners.
Examples
This information might contain examples of data and reports. The examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
License agreement
This software and the associated documentation are proprietary and confidential to Rocket
Software, Inc., are furnished under license, and may be used and copied only in accordance with the terms of such license.
Note: This product may contain encryption technology. Many countries prohibit or restrict the
use, import, or export of encryption technologies, and current use, import, and export regulations should be followed when exporting this product.
Contact information
Website: www.rocketsoftware.com
Rocket Software, Inc. Headquarters
77 4 th
Avenue, Suite 100
Waltham, MA 02451-1468
USA
Tel: +1 781 577 4321
Fax: +1 617 630 7100
Contacting Global Technical Support
If you have current support and maintenance agreements with Rocket Software, you can access the Rocket Customer Portal to report and track a problem, to submit an enhancement request or question, or to find answers in the U2 Knowledgebase. The Rocket Customer Portal is the primary method of obtaining support.
To log in to the Rocket Customer Portal, go to: www.rocketsoftware.com/support
If you do not already have a Rocket Customer Portal account, you can request one by clicking
Need an account? on the Rocket Customer Portal login page.
Alternatively, you can contact Global Technical Support by email or by telephone:
Email:
Telephone:
North America
United Kingdom/France
Europe/Africa
Australia
New Zealand
+1 800 729 3553
+44 (0) 800 773 771 or +44 (0) 20 8867 3691
+44 (0) 20 8867 3692
+1 800 707 703 or +61 (0) 29412 5450
+0800 505 515
3
Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta
Table of
Contents
Table of Contents
Chapter 1
Chapter 2
Chapter 1: Introduction and terminology
Terminology . . . . . . . . . . . . . . . . . . . .
1-3
Replication objects . . . . . . . . . . . . . . . .
1-3
Replication system . . . . . . . . . . . . . . . .
1-3
Replication group . . . . . . . . . . . . . . . . .
1-4
Group distribution . . . . . . . . . . . . . . . .
1-4
Replication . . . . . . . . . . . . . . . . . . .
1-4
Types of replication . . . . . . . . . . . . . . . .
1-5
Replication log . . . . . . . . . . . . . . . . . .
1-6
Replication messages. . . . . . . . . . . . . . . .
1-7
Replication buffer . . . . . . . . . . . . . . . . .
1-8
Replication log reserve file . . . . . . . . . . . . . .
1-8
Transaction control record . . . . . . . . . . . . . .
1-9
Transaction control area . . . . . . . . . . . . . . .
1-10
Publisher process . . . . . . . . . . . . . . . . .
1-10
Publisher-syncing tool . . . . . . . . . . . . . . .
1-10
Publisher listener process . . . . . . . . . . . . . .
1-10
Subscriber process. . . . . . . . . . . . . . . . .
1-10
Replication writer process . . . . . . . . . . . . . .
1-11
Replication manager daemon . . . . . . . . . . . . .
1-11
Replication system definition . . . . . . . . . . . . .
1-12
Replication configuration file . . . . . . . . . . . . .
1-12
Chapter 2: Installing and configuring U2 Data Replication for UniVerse
Files created by the installation process . . . . . . . . . . .
2-3
Configuring U2 Data Replication . . . . . . . . . . . . .
2-4 uvconfig parameters . . . . . . . . . . . . . . . .
2-4
Replication system definition (repsys) . . . . . . . . . .
2-7
Replication configuration file . . . . . . . . . . . . .
2-12
Defining replication on a publishing system . . . . . . . . .
2-23
C:\Users\awaite\Documents\U2Doc\UniVerse\11.2\Source\REPLICATION\REPTOC.fm (bookTOC.template)
March 21, 2014 10:01 am
Chapter 3
Chapter 4
Chapter 5
Defining publishing groups from U2 Extensible Admin . . .
2-27
Defining publishing groups from the command line . . . .
2-33
Defining replication on a subscribing system . . . . . . . . .
2-35
Defining subscribing groups from the command line . . . .
2-43
Changing a replication group definition . . . . . . . . . .
2-45
Change replication group definition from the command line. .
2-47
Processes added for U2 Data Replication . . . . . . . . . .
2-48
Chapter 3: How U2 Data Replication works
Data propagation procedure . . . . . . . . . . . . . .
Suspending live replication . . . . . . . . . . . . . . .
3-3
3-5
Data synchronization of suspended live replication . . . . .
3-6
Deferred replication . . . . . . . . . . . . . . . . .
3-10
Transaction handling . . . . . . . . . . . . . . . . .
3-12
Indexed virtual attributes . . . . . . . . . . . . . . .
3-14
File triggers . . . . . . . . . . . . . . . . . . . .
3-15
Partition algorithm check . . . . . . . . . . . . . . .
3-16
File-level operations . . . . . . . . . . . . . . . . .
3-17
File-level commands . . . . . . . . . . . . . . .
3-20
Chapter 4: Failover and recovery
Failing over a system . . . . . . . . . . . . . . . . .
4-3
Step-by-Step instructions for hard failover in case of primary system crash . . . . . . . . . . . . . . . . . .
4-3
Step-by-step instructions for soft failover . . . . . . . .
4-4
Step-by-step instructions for failback . . . . . . . . . .
Data recovery . . . . . . . . . . . . . . . . . . .
Recovery of a subscribing system . . . . . . . . . . .
4-5
4-6
4-6
Resynchronization after recovery from subscribing system or network failure . . . . . . . . . . . . . . . . .
4-6
Database refreshing . . . . . . . . . . . . . . . .
4-6
Chapter 5: Administering U2 Data Replication for UniVerse
Administering U2 Data Replication through U2 Extensible Admin .
Defining replication systems . . . . . . . . . . . . .
5-3
5-4
Adding a publishing group . . . . . . . . . . . . .
5-9
Adding a subscribing group . . . . . . . . . . . . .
5-14
Using the replication tool . . . . . . . . . . . . . .
5-18
Diagnosis utility . . . . . . . . . . . . . . . . .
5-20
Monitoring replication . . . . . . . . . . . . . . .
5-21
5 U2 Data Replication for UniVerse
Chapter 6
Chapter 7
uv_repadmin tool . . . . . . . . . . . . . . . . . . 5-29 suspend command . . . . . . . . . . . . . . . . 5-30 sync command . . . . . . . . . . . . . . . . . . 5-31 failover command . . . . . . . . . . . . . . . . . 5-33 reconfig command. . . . . . . . . . . . . . . . . 5-34 reset command . . . . . . . . . . . . . . . . . . 5-35 report command . . . . . . . . . . . . . . . . . 5-36
Replication action trigger . . . . . . . . . . . . . . . . 5-39
Replication action trigger example . . . . . . . . . . . 5-41
Listing replication files . . . . . . . . . . . . . . . . . 5-43
Replication files with multiple VOC pointers . . . . . . . . . 5-45
Chapter 6: Restrictions
File types . . . . . . . . . . . . . . . . . . . .
6-2
Changing inode or device numbers . . . . . . . . . . .
6-2
One replication object can only belong to one group . . . . .
6-2
System files not supported as replication objects . . . . . .
6-3
No cascading replication . . . . . . . . . . . . . .
6-3
Writeable subscriber files . . . . . . . . . . . . . .
6-3
Other command replication . . . . . . . . . . . . .
6-3
Virtual field definitions . . . . . . . . . . . . . . .
6-4
Sequence of updates . . . . . . . . . . . . . . . .
6-4
Transaction limitations . . . . . . . . . . . . . . .
6-4
System crashes during failover . . . . . . . . . . . .
6-5
Dictionary and data portions of a file . . . . . . . . . .
6-5
Multiple locks . . . . . . . . . . . . . . . . . .
6-6
Other limitations . . . . . . . . . . . . . . . . .
6-6
Chapter 7: Disabling U2 Data Replication
Disabling U2 Data Replication . . . . . . . . . . . . . .
7-1
Replication DISABLE mode . . . . . . . . . . . . . . .
7-2
Replication ENABLE mode . . . . . . . . . . . . . . .
7-4
Runtime error handling . . . . . . . . . . . . . . . .
7-5
Enabling or disabling U2 Data Replication . . . . . . . . . .
7-6
Enabling or disabling U2 Data Replication through XAdmin . .
7-6
Exception action script . . . . . . . . . . . . . . . . .
7-8
Error messaging . . . . . . . . . . . . . . . . . . .
7-9
Table of Contents 6
Chapter 1: Introduction and terminology
Terminology . . . . . . . . . . . . . . . . . . . .
Replication objects . . . . . . . . . . . . . . . .
Replication system . . . . . . . . . . . . . . . .
Replication group . . . . . . . . . . . . . . . .
Group distribution . . . . . . . . . . . . . . . .
Replication . . . . . . . . . . . . . . . . . . .
Types of replication . . . . . . . . . . . . . . . .
Replication log . . . . . . . . . . . . . . . . .
Replication messages . . . . . . . . . . . . . . .
Replication buffer . . . . . . . . . . . . . . . .
Replication log reserve file . . . . . . . . . . . . .
Transaction control record. . . . . . . . . . . . . .
Transaction control area . . . . . . . . . . . . . .
Publisher process. . . . . . . . . . . . . . . . .
Publisher-syncing tool . . . . . . . . . . . . . . .
Publisher listener process . . . . . . . . . . . . . .
Subscriber process . . . . . . . . . . . . . . . .
Replication writer process. . . . . . . . . . . . . .
Replication manager daemon . . . . . . . . . . . .
Replication system definition . . . . . . . . . . . .
Replication configuration file . . . . . . . . . . . .
Chapter
1
Rocket U2 Data Replication provides an automatic way to deliver read-only copies of UniVerse files to other UniVerse systems. You can use the replicated data as a standby system in case of system failure, or as a reporting system.
The system where the source data resides is called the publisher. A system receiving copies of file updates from the publisher is called a subscriber.
1-2
Terminology
This section describes terminology used throughout this manual.
Replication objects
The following objects are used in the U2 Data Replication system:
Replication object
A U2 Data Replication Object can be any UniVerse database file, including static files, dynamic files, directory files, or multilevel files. Each replication object has a unique object name and an account in which it is defined. The object name is the VOC name in the account.
Publishing object
A Publishing Object is the replication object being replicated. One publishing object may have multiple corresponding subscribing objects on multiple replication sites.
Subscribing object
A Subscribing Object is a replica of the publishing object. The subscribing object does not have to have the same physical structure as the publishing object. For example, a subscribing object could be a dynamic file, while its publishing object is a static hashed file. A subscribing object must have the same object name as the publishing object.
Replication system
A Replication System is a UniVerse system in a replication environment. The replication system replicates data from one system (Publishing System), to other systems (Subscribing Systems), or both.
1-3 U2 Data Replication for UniVerse
Replication group
In a replication environment, a Replication Group is a group of replication objects belonging to one UniVerse account. The replication group is the basic unit of replication. Organizing related database objects into a replication group makes it easier to administer many objects together.
You can create and use a replication group to organize the database objects necessary to support a particular database application. You can define multiple replication groups in the same account, but one replication object can belong to only one replication group.
You can replicate one replication group from one publishing account to multiple subscribing accounts.
On a publishing system, a Publishing Group is the replication group defined in a publishing account of a local system and replicated to remote replication systems.
On a subscribing system, a Subscribing Group is a replication group defined on a remote replication system and replicated to a local subscribing account.
Group distribution
Group Distribution defines a copy or replica of objects in a Replication
Group. A Replication Group must have one publisher distribution and one or more subscriber distributions. A publisher distribution defines the replication system where the group is published. A subscriber distribution defines the replication system that the group subscribes to and the replication type.
Replication
In a replication environment, a Replication is the data replication from a publishing system to a subscribing system. You may have multiple replication groups in one replication.
On a specific system, you usually use a remote system name to represent the replication from a local system to the remote system, or from the remote system to the local system.
Terminology 1-4
Standby replication
A standby replication is a replication used to support a standby failover system.
Non-standby replication
A non-standby replication is a replication used to support report applications only.
Types of replication
The following types of replication are available:
Real-time replication
Real-time Replication
is a type of U2 Data Replication where transactions on the publishing server do not commit until all logs of the transaction arrive at the subscriber. With this type of replication, should the publishing server failover to the real-time subscribing system, all committed transactions on the publishing system are guaranteed to apply to the standby system.
Immediate replication
Immediate Replication
is a type of U2 Data Replication where UniVerse sends a transaction log to the subscribing system immediately after it is ready to commit. The publishing system does not wait for the log to arrive on the subscriber before committing the transaction. Should the publishing server failover to the immediate subscribing system, there is a slight chance that some committed transactions on the publisher will not arrive on the failover system. Administrator intervention may be necessary to recover the system.
Note:
Immediate Replication has better performance than real-time replication.
1-5 U2 Data Replication for UniVerse
Deferred replication
Deferred Replication
saves transaction logs in a file rather than sending them to the subscriber. At a predefined period of time, the subscribing system connects to the publishing server, retrieves all of the logs, and synchronizes its database to the publishing database. Deferred replication can only be used in non-standby replication.
Replication log
A replication log is a log representing a transaction or update on a publishing object. UniVerse transfers this log to the subscribing system to propagate data.
In a replication group, each replication log has a unique Replication Log
Sequence Number (RepLSN).
Data update log
A Data Update log is a log representing a data update, and contains the following information:
Log header:
RepLSN
Length of log
Transaction ID
Operation flag
Pub-Commit flag
Sub-Commit flag
Log body
File ID
Record ID
Record as well as indexed I-descriptor values
Terminology 1-6
Transaction log
A transaction log is a special log representing a transaction other than data updates. Each transaction generates a pair of transaction logs in the replication group, a Transaction Begin Log and a Transaction End Log.
Replication failover log
A Replication Failover Log is a replication log generated by the subscriber process when it is failing over to a standby system. UniVerse then sends these logs to the original primary system as part of the resynchronization process.
The Failover End Log is generated at the end of the failover process.
Replication messages
The following types of messages are used with U2 Data Replication:
Pub-commit notification
Pub-Commit Notification is a notification message sent from the publisher to the subscriber to notify the subscriber that a specific transaction has been committed on the publishing system.
Sub-got notification
A Sub-Got Notification is a notification message sent from the subscriber to the publisher verifying that it received the replication logs of a specific transaction.
Sub-commit notification
A Sub-Commit Notification is a notification message sent from the subscriber to the publisher verifying that a specific transaction was committed on the subscribing system.
1-7 U2 Data Replication for UniVerse
Replication buffer
When UniVerse starts, the replication system allocates replication buffers for all replication groups. A replication buffer is a buffer in shared memory that transfers replications logs between the “reader” and “writer” processes. For a publishing group, the writers are the uvsh and its child processes, and the reader is the publisher process. For subscribing groups, the writer is a subscriber process and readers are replication writer processes.
Replication buffer extension file
The Replication Buffer Extension (LEF) file is an extension of the replication buffer, used to store very large logs and other log files when the replication buffer is full.
The Replication Buffer Extension file is a directory with part files.
Replication log reserve file
The Replication Log Reserve File (LRF) is a log file residing on the publishing system to save replication logs when replication is suspended because of a network failure, a subscribing system crash, or when an administrator issues the SUSPEND command.
UniVerse sends reserved logs to the subscribing system at a later time to synchronize the data between the publishing and subscribing systems. For deferred replication, UniVerse uses the Replication Log Reserve File to save replication logs on the publishing system. These logs are sent to the subscribing system periodically, or manually, for synchronization.
When replication is suspended on a subscribing system, the subscriber process saves the logs without Pub-Commit notification from the publisher and writes them to the Replication Log Reserve File. UniVerse then reloads these logs in the Replication Buffer when the subscribing group fails over.
The Replication Log Reserve file is a directory with a control file and part files.
Terminology 1-8
Replication sub packet store
The Replication Sub Packet Store stores data packets sent from the publisher before the uvsub process loads and processes the data. The Replication Sub
Packet Store consists of the Sub Packet File and the Sub Packet Buffer.
UniVerse creates or truncates the Sub Packet File each time the uvsub process starts a sync operation. This file has the same format as the Replication Log
Reserve file, with a .spf file extension.
The Sub Packet Buffer consists of two parts to store the log info and log body, respectively. The log info portion of the buffer has a fixed size of 2300 bytes, while the body buffer size is 128K.
While U2 Data Replication is running, the Sublistener thread saves data packets to the Sub Packet Buffer first. If this buffer is full, it saves the data packets in the Sub Packet File.
If you suspend Replication, the uvsub process dumps all unsaved replication logs from the Sub Packet Buffer to the Sub Packet file in case of a failover. If a failover command is issued, UniVerse loads all data logs from the Sub
Packet file to the Replication buffer and processes them during the failover process. If no failover command is issued, UniVerse discards the unloaded data logs in the next sync operation.
Transaction control record
A Transaction Control Record is a record in a shared memory buffer used to control a cross-group transaction. A cross-group transaction is a transaction involved in multiple replication groups.
For each cross-group transaction that occurs on the publishing system,
UniVerse creates a transaction control record on the subscribing system to synchronize the multiple processes dealing with the transaction to enforce the consistency of the transaction. The transaction control record contains the following information:
Transaction ID
Total number of replication groups involved in the transaction
Number of groups that have received all log files
Number of groups that have committed the transaction
1-9 U2 Data Replication for UniVerse
Number of groups that have aborted the transaction
A list of Replication Writers waiting on the transaction
Transaction control area
The Transaction Control Area is a shared memory buffer used for Transaction
Control Records. Each replication system contains one transaction control area.
Publisher process
A Publisher Process (uvpub) is a process running on the publishing system that reads logs of a specific replication group from the replication buffer and sends them to the subscribing system.
Publisher-syncing tool
The Publisher-syncing Tool (uvpubsyncer) is a process the publisher process creates to send synchronizing data logs from the Replication Log Reserve File to the subscribing system to synchronize subscriptions to their publishers.
Publisher listener process
The Publisher Listener Process (uvpublistener) is a process the publisher process creates to listen to a remote subscriber process for a feedback control package.
Subscriber process
A Subscriber (uvsub) is a process running on the subscribing system that receives logs of a replication group from the publishing system and writes them to replication buffer.
Terminology 1-10
The Subscriber Process consists of two major threads. The sublistener thread receives data packets from the publishing system through a socket connection, then stores the data packets in the Sub Packet Store and sends an acknowledgment back to the publishing system. The Sub Main thread loads the replication logs from the Sub Packet Store to the replication buffer and coordinates with replication writer processes to apply the logs on the subscribing database.
Replication writer process
The Replication Writer Process (uvrw) runs on the subscribing system. This process reads data logs from the replication buffer and applies the updates to the subscribing objects. More than one replication writer can exist for one subscribing group.
UniVerse also uses replication writer processes to load replication objects at system start up.
Replication manager daemon
The Replication Manager (uvrepmanager) is a UniVerse daemon that must be running on the replication system. The publishing system and the subscribing system each have one replication manager. The replication manager performs the following tasks:
Reads and loads replication configuration information when
UniVerse starts
Creates replication processes for each replication group
Monitors and controls the replication processes
Handles commands from Replication Admin and U2 Extensible
Admin
Dynamically reconfigures the replication environment
Handles failover replication, recovery, and synchronization of replication data
1-11 U2 Data Replication for UniVerse
Replication system definition
The Replication System Definition file, repsys, located in the uvhome directory, defines all replication systems in a replication environment. This file contains definitions for the local system and all remote replication systems that replicate data from or to the local system. Each system definition contains the user-defined system name, network address, UniVerse version, and other information related to the system and replication from or to the system.
Replication configuration file
The Replication Configuration File (repconfig), located in the uvhome directory, is maintained by an administrator on each system and defines all replication groups on the system and their distributions. Each replication group has a unique global name, a list of objects in the group, a local account location, a publishing system from which it replicates, and all subscribing systems to which it replicates.
The Replication Configuration File contains a section for each replication group, and contains the following information:
Group Name
Replication Level
Local account location
All replication objects belonging to the group
Publishing system from which it replicates and all subscribing systems to which it replicates
System tunable parameters for the replication group
Data link compression
Beginning at UniVerse 11.2.3, the U2 Replication process allows data to be compressed during the network transfer phase, in a process called data link compression. When data link compression is turned on, the publisher compresses the data packets before sending them out. The subscriber then decompresses the packets after they are received. This reduces the amount of data being transferred, mitigating the overhead brought out by slow network connections.
Terminology 1-12
Chapter 2: Installing and configuring U2 Data Replication for UniVerse
Files created by the installation process . . . . . . . . . .
Configuring U2 Data Replication . . . . . . . . . . . .
uvconfig parameters . . . . . . . . . . . . . . .
Replication system definition (repsys) . . . . . . . . .
Replication configuration file . . . . . . . . . . . .
Defining replication on a publishing system . . . . . . . . .
Defining publishing groups from U2 Extensible Admin . . .
Defining publishing groups from the command line . . . .
Defining replication on a subscribing system . . . . . . . .
Defining subscribing groups from the command line . . . .
Changing a replication group definition . . . . . . . . . .
Change replication group definition from the command line. .
Processes added for U2 Data Replication . . . . . . . . . .
Chapter
2
This chapter describes how to install and configure U2 Data Replication for
UniVerse.
2-2
Files created by the installation process
When you install U2 Data Replication for UniVerse, the installation process installs the following components:
The default configuration parameters in the uvconfig file.
The default data replication log directory (replog) in the UVHOME directory.
A default Replication System Definition file (repsys) in the
UVHOME directory.
An empty Replication Configuration file (repconfig) in the
UVHOME directory.
A U2 Replication Service (uvsub) and Replication Manager
Connection Service (uvrmconn) in the system RPC service table.
A default Account-Level Replication file (repacct.def).
If you configure U2 Data Replication for UniVerse, UniVerse starts the following daemons:
Daemon
uvsmm uvrepmanager uvcleanupd
Function
Manages shared memory segments for U2 Data Replication for UniVerse.
The UniVerse Data Replication Manager.
The UniVerse cleanup daemon. UniVerse starts this daemon when you start the UniVerse system. New functions clean up dead users for U2 Data Replication.
U2 Data Replication for UniVerse Daemons
2-3 U2 Data Replication for UniVerse
Configuring U2 Data Replication
UniVerse supports dynamic configuration of U2 Data Replication. A system administrator can edit the Replication System Definition file (repsys) and the
Replication Configuration File (repconfig), to define and configure the replication groups. UniVerse loads the new configuration parameters when you execute the RECONFIG command.
uvconfig parameters
The following uvconfig parameters pertain to U2 Data Replication:
REP_FLAG (replication flag)
The REP_FLAG parameter turns U2 Data Replication on or off.
If you choose the install UniVerse with the Replication System, you must manually set the REP_FLAG uvconfig parameter to 1 to enable U2 Data
Replication. The following table describes the REP_FLAG options:
Value
0 (zero)
Any positive integer
Description
The U2 Data Replication System is off.
The U2 Data Replication System is on.
REP_FLAG Values
TCA_SIZE
The maximum number of entries in the Transaction Control Area (TCA).
TCA is only used when there is more than one replication group configured, and there are transactions across replication groups. The default value is
2048.
If you are not using transaction processing, this parameter is irrelevant. If you are using transaction processing, set the value of TCA_SIZE to at least the number of users on the system.
Configuring U2 Data Replication 2-4
MAX_LRF_FILESIZE
The maximum Log Reserve File Size, in bytes. The default value is
1,073,741,824 (1 GB).
The maximum value is 2,147,483,136.
N_REP_OPEN_FILE
The maximum number of open replication log files for a uvsh process. The default value is 8.
MAX_REP_SHMSZ
The maximum shared memory buffer segment size. The default value is
1073741824
.
REP_LOG_PATH
The full path to the location of the replication log files. The default value is
uvhome/replog.
MAX_RW_INGRP
The maximum number of Replication Writer processes that can be configured in a replication group. The default value is 8.
Configuration parameters for shared memory
The following uvconfig parameters added for shared memory management at UniVerse 11.l.
NUSERS
The number of user sessions. The recommended value is twice the number of licensed users.
SHM_MAX_SIZE
The maximum size of a shared memory segment.
2-5 U2 Data Replication for UniVerse
SHM_ATT_ADD
The starting address for attaching shared memory segments.
SHM_LBA
Reserved for future use. Do not change.
SHM_MIN_NATT
Number of shared memory segments to keep attached.
SHM_GNTBLS
Number of global memory tables for shared memory segments.
SHM_GNPAGES
Number of pages in each shared memory segment.
SHM_GNPAGESZ
The page size of each shared memory segment.
SHM_LPINENTS
The number of processes in each user session.
SHM_LMINENTS
The number of memory entries in each user session.
SHM_LCINENTS
The number of memory control entries in each user session.
Configuring U2 Data Replication 2-6
SHM_LPAGESZ
The local page size.
SHM_FREEPCT
The percentage of free shared memory to keep.
SHM_NFREES
The number of free shared memory segments to keep.
Replication system definition (repsys)
The Replication System Definition defines local and all remote host system locations in a replication environment. This file, called repsys, resides in the
uvhome directory.
Each line of the repsys file is either a definition phrase or a comment. A definition phrase defines a component of replication systems in the replication environment, such as replication system names or host names. A definition phrase starts with the phrase name that indicates the type of phrase.
U2 Data Replication can include the following types of phrases:
System phrase
A system phrase starts a system definition section. The system definition section defines a replication system in the replication environment. One system section ends when another system phrase is defined, or at the end of the repsys file.
You must specify a user-defined name for the local system in the repsys file.
UniVerse adds the local definition to the repsys file, as shown in the following example:
# Definition of system shire
SYSTEM=shire
HOSTNAME=shire
VERSION=111
2-7 U2 Data Replication for UniVerse
You must define a system phrase for each system location in the replication environment. When defining a remote system location, you also define the replication from or to the local system.
The system phrase has the following syntax:
SYSTEM
=<system_name> where system_name is the name you define for the replication system. This name should be unique on a system. system_name can contain a combination of alphabetic characters, number, and any of the following character: ~ ! @ $
% ^ & * - + . / \.
Hostname phrase
The hostname phrase is a required entry in the repsys file to define the host name of the replication system location. A system can have only one host name.
The hostname phrase has the following syntax:
HOSTNAME
=<host_name or network_address>
Version phrase
The version phrase defines the version of UniVerse on the system location.
The version number must be 111 or higher.
The version phrase has the following syntax:
VERSION
=<version_no>
AUTORESUME phrase
The AUTORESUME phrase determines if replication from the remote system you specify will be synchronized and resume automatically when UniVerse starts, or after a reconfiguration.
The AUTORESUME phrase has the following syntax:
AUTORESUME
=<flag> where flag is 1 for true, or 0 for false.
Configuring U2 Data Replication 2-8
DHCP phrase
The DHCP phrase specifies that a remote or local system has a dynamic IP address. If you define a remote system as a DHCP system, U2 Data Replication automatically updates the IP address of the remote system when it receives a SYNC request from that system. If you define a local system as a
DHCP system, UniVerse Data Replication automatically sends the current IP address in the SYNC request to the remote server.
The DHCP phrase has the following format:
DHCP=1
If the remote system is a DHCP system, you should always set AUTORE-
SUME to false to avoid a SYNC request failure.
AUTHORIZATION phrase
For remote systems with a static IP address, the publishing system can always trust the subscribing system because the IP address is defined in the repsys file. However, if the remote system is a DHCP system, the publishing system cannot verify the IP address.
In order to verify the subscribing system, set the AUTHORIZATION phrase value to 1 on the subscribing system location. U2 Data Replication performs an authorization check when a SYNC request is received from that subscribing system.
If you define a subscribing system location with an AUTHORIZATION phrase, you must define a connection user name and password on the remote subscribing system in order for the SYNC request to succeed. You can define or change the connection user and password through U2 Extensible Admin, or the repadmin tool with the following command: uv_repadmin setconnect <replication> where replication is the remote system location defined in the repsys file.
The repadmin tool prompts for the connection user name and password.
2-9 U2 Data Replication for UniVerse
SYNCINTVAL phrase
The SYNCINTVAL phrase defines the time interval, in minutes, in which the replication system automatically synchronizes replication to the remote system.
The SYNCINTVAL phrase has the following syntax:
SYNCINTVAL
=<sync_interval>
U2 Data Replication automatically synchronizes subscribing systems with their publisher every period defined by sync_interval. A sync_interval of 0 indicates a manual synchronization system, where the system does not automatically synchronize the systems.
The SYNCINTVAL phrase applies only to those subscribing groups that have deferred replication on the remote system. It does not apply to publishing groups.
TIMEOUT phrase
The TIMEOUT phrase defines the the number of seconds to wait if no packets are received from the remote system before suspending replication.
The publishing system sends a packet to the subscribing system approximately every 4 seconds when replication is idle. The subscribing system then sends a packet back to the publishing system. If the subscribing system location has the TIMEOUT phrase defined, the publistener process counts the time that has elapsed between packets being received. If the amount exceeds the value of the TIMEOUT phrase, replication is suspended.
In the value of TIMEOUT is 0, no timeout occurs.
We recommend that you not set the value of the TIMEOUT phrase to less than 2 minutes.
Configuring U2 Data Replication 2-10
EXCEPTION_ACTION phrase
The replication exception action is a shell script on UNIX platforms, or a batch program on Windows platforms. Define the full path to the exception action using the EXCEPTION_ACTION phrase in the repsys file. For example, if you define a replication exception action as UVRepException-
Action.sh in the /usr/uv directory, set the EXCEPTION_ACTION clause as:
EXCEPTION_ACTION=/usr/uv/UVRepExceptionAction.sh
For more information about replication action triggers, see
in Chapter 5, “Chapter 5: Administering U2 Data Replication for
Example
The following examples show a replication system involving three systems,
Server 1, Server 2, and Server 3. Each platform is running one UniVerse system.
repsys File for Server1
#Define local system
SYSTEM=System_A
HOSTNAME=Server1
VERSION=111
#Define Remote System B
SYSTEM=System_B
HOSTNAME=Server2
VERSION=111
AUTORESUME=1
TIMEOUT=300
#Define Remote System C
SYSTEM=System_C
HOSTNAME=Server3
VERSION=111
2-11 U2 Data Replication for UniVerse
repsys file for server2
#Define local system
SYSTEM=System_B
HOSTNAME=Server2
VERSION=111
#Define Remote System A
SYSTEM=System_A
HOSTNAME=Server1
VERSION=111
AUTORESUME=1
TIMEOUT=300
#Define Remote System_C
SYSTEM=System_C
HOSTNAME=Server3
VERSION=111
repsys file for server 3
#Define local system
SYSTEM=System_C
HOSTNAME=Server3
VERSION=111
#Define Remote System A
SYSTEM=System_A
HOSTNAME=Server1
VERSION=111
SYNCINTVAL=3
#Define Remote System_B
SYSTEM=System_B
HOSTNAME=Server2
VERSION=111
SYNCINTVAL=3
Replication configuration file
The Replication Configuration File (repconfig), located in uvhome, defines all replication groups and their configuration parameters.
Configuring U2 Data Replication 2-12
Each line of the repconfig file is either a definition phrase or a comment. A phrase defines a component of replication, such as a replication group or a replication object.
A phrase entry begins with the phrase name that indicates the type of phrase.
UniVerse supports the following eight types of phrases:
GROUP phrase – defines a replication group name
LEVEL phrase – defines the replication level of a replication group
ACCOUNT phrase – defines a local replication account
FILE phrase – defines a replication object
EXCLUDED_FILE phrase – defines an excluded file for a replication account
DISTRIBUTION phrase – defines distribution of a replication group
Configuration phrases – define configurable parameters for a replication group
RW configuration phrases – define configurable parameters for replication writer processes
GROUP phrase
A GROUP phrase starts a group definition section. The group definition section defines contents, distributions, and configurable parameters of a replication group. One group section ends when another group phrase is defined, or at the end of the repconfig file.
The group phrase has the following syntax:
GROUP
=<group_name> where group_name is the user-defined name for the group.
LEVEL phrase
The LEVEL phrase defines the replication level of a replication group. By default, a replication group is a file-level group.
LEVEL=[ACCOUNT | FILE]
2-13 U2 Data Replication for UniVerse
Account-level replication replicates updates to all files in an account, except those defined in the Excluded File phrase. You can define multiple file-level groups in an account, and one account-level group. If a file is defined in a filelevel group, UniVerse replicates updates through the replication group where the file is defined. If you do not explicitly define the file in a group,
UniVerse replicates the updates through the account-level group.
ACCOUNT phrase
Each replication group section must contain an ACCOUNT phrase, which defines the local account where the replication group resides.
The account phrase has the following syntax:
ACCOUNT
=<account_path> where account_path is the full path to the directory where the account resides.
FILE phrase
Each group section can contain multiple file sections. A file section defines a replication object in a replication group, and a FILE phrase defines the file name.
The file phrase has the following syntax:
File
=[SUB_WRITEABLE] [DICT | DATA] <filename> [,subfile]
If you specify SUB_WRITEABLE, you can write to the file you specify on the subscribing system. On the publishing system, this does not take effect until system failover.
If you specify DICT, only the dictionary portion of the file is replicated. If you specify DATA, only the DATA portion of the file is replicated. Otherwise,
UniVerse replicates both the dictionary and data portion of the file.
If the filename you specify is a multilevel file and you do not specify a subfile name, UniVerse replicates the multilevel file and all its part files. It does not include newly created part files after UniVerse starts.
When defining UniVerse distributed files in a file phrase, you must explicitly define each part file you want to replicate. If you define only the distributed file name, no updates to the distributed file will be replicated.
Configuring U2 Data Replication 2-14
An account-level group can also have file sections. You may want to define a file explicitly in an account-level group if the file has a symbolic link or VOC pointer and you want to clearly define the primary replication file, or you want to define the file with special options.
By default, UniVerse automatically adds the VOC file to the account-level group.
Warning
: If you define a file in more than one replication group, UniVerse will use one, and only one, file definition. The file UniVerse chooses is arbitrary.
EXCLUDED_FILE phrase
The EXCLUDED_FILE phrase defines an excluded file for a replication account.
EXCLUDED_FILE=[DICT | DATA] filename[,subfile]
U2 Data Replication allows you to use wildcard patterns in the EXCLUD-
ED_FILE phrase. This is helpful if your application creates temporary files that you may not know the exact name of in advance.
In the repconfig or repacct.def files, define the pattern for the files you want to exclude using the EXCLUDED_FILE phrase.
EXCLUDED_FILE={DICT | DATA} [<wildcard>]<filename> [<wildcard>] in which <wildcard> is "..."
If wildcard exists in the EXCLUDED_FILE phrase, it describes an excluded pattern rather than an excluded file. For example, the phrase
"EXCLUDED_FILE= ...WORK.FILE..." specifies any file containing
"WORK.FILE" to be excluded.
"EXCLUDED_FILE=WORK..." specifies an excluded pattern for WORK.*.
'EXCLUDED_FILE=WORK.FILE,..." specifies an excluded pattern that matches all subfiles of the level file "WORK.FILE"
In account-level replication, the RESERVED_FILE_SPACE parameter defines the number of dynamic objects for both included and excluded objects. Each dynamic excluded object created for a file will consume one slot in the dynamic object table.
2-15 U2 Data Replication for UniVerse
The default repacct.def file now contains the following excluded file phrase:
EXCLUDED_FILE=VI.TMP...
DISTRIBUTION phrase
Each group section can contain multiple distribution phrases. A
DISTRIBUTION phrase defines a distribution of a replication group. A distribution of a replication group is either the publishing system from which it replicates, or a subscribing system to which it replicates.
The distributions of a replication define all replications in which the group is involved. Each group section must contain one distribution phrase defining the publishing system, and at least one distribution phrase defining a subscribing system.
The distribution phrase has the following syntax:
DISTRIBUTION
=<replication_type>:<system_name>
<replication_type> defines the distribution and replication type. The following table describes the valid replication types:
Type
P
R[B]
I[B]
D
C
Description
Publishing system.
Real-time replication subscribing system. If you specify B, it is also a standby subscribing system.
Immediate subscribing system. If you specify B, it is also a standby subscribing system.
Deferred subscribing system.
Optional. Turns on Data link compression . When C is specified in the
Subscribing Type, the data transfer from publisher to this subscriber is compressed.
Replication Types
system_name is one of the systems previously defined in the repsys file. One replication group must have one, and only one, local system distribution.
Optionally, you can use the LOCAL keyword to represent the local system name.
Configuring U2 Data Replication 2-16
Configuration phrases
Configuration phrases define configurable parameters for the replication group. The following table describes the configurable parameters.
Parameter Description
N_LOGINFO
REP_BUFSZ
LARGE_RECSZ
The maximum number of replication logs that can be loaded in the shared memory buffer. If the number of logs in the replication buffer exceeds this value,
UniVerse stores the logs in the Replication Buffer
Extended File. The default value is 4096.
The shared memory buffer size used to hold the log body for the replication group. The default value is
1048576.
When a record is larger than the value of
LARGE_RECSZ, UniVerse stores it in the LEF instead of the Replication buffer. The default value is 64K.
RESERVED_FILE_SPACE Defines the number of file slots to reserve for an account-level group. The default value is 500.
Configuration Phrase Parameters
Note
: If the RESERVED_FILE_SPACE is full, the CREATE.FILE command will fail with an error similar to the following example:
Replication object table is full: Enable Replication object TEST3 failed.
Creating file TEST3 failed.
============>>>> NOTE: CREATE.FILE failed! <<<<<<==============
Not - file created but cannot be replicated. Table full = fatal error.
Note
: You can reload the Replication File Table and provide fresh reserve slots
without stopping UniVerse by running the uv_repadmin reconfig command.
Replication writer configuration phrases
Replication writer configuration phrases define configurable parameters for replication writers. These parameters are used only by a subscribing group.
We recommend that you define this for the publishing group if you want to failover the publishing group to a standby subscribing system. The group is treated as a subscribing group after the failover.
2-17 U2 Data Replication for UniVerse
The following table describes the replication writer configurable parameters.
Parameter Description
N_REPWRITER
RW_UID=<user_ID>
RW_GID=<group_ID>
RW_REEVALUATE_VF
RW_SKIP_TRIGGER
The number of replication writer processes for the replication group.
The user ID of the replication writer process. By default, UniVerse starts the replication writers as root.
If you define RW_UID, the replication writer process changes the user ID to the one you specify. UniVerse only supports this parameter on UNIX systems.
The group ID of the replication writer process. If you define RW_GID, the replication writer process changes the group ID to the one you specify. UniVerse only supports this parameter on UNIX systems.
UniVerse evaluates indexed virtual fields on the publishing system before writing the results to the database, then transfers these values to the subscribers along with the record. You can choose to use these values directly from the publisher, or have the replication writer processes reevaluate these values. By default, the replication writer process reevaluates the virtual field on the subscribing system. If you want to use the values without reevaluating them, set this parameter to 0.
If this value is set to 1, the default, the replication writer process ignores a trigger, even if a trigger exists on the subscribing file. If you do not want to ignore the trigger, set this value to 0.
RW_IGNORE_ERROR If a replication writer process encounters inconsistency in a replication log, it writes an error message to the rm.errlog, but continues processing. If you set this value to 0, UniVerse will suspend replication if it finds inconsistency in a replication log.
RW_VERIFY_PAR-
TITION
If this value is set to 1, the replication writer processes verify the partition algorithm of distributed files part files. If the publishing system and the subscribing system have exactly the same definition for distributed files, you can set this value to 0 to skip partition verification. The default value is 1.
Replication Writer Configurable Parameters
Configuring U2 Data Replication 2-18
Examples
The following example illustrates a repconfig file for account-level replication. In these examples, the CUSTOMER and \U2\uv\demo on System A to \U2\uv\test on System B in real-time, standby replication mode, and to
/disk1/demo on System C in deferred replication. Also assume that a
STUDENT2 VOC pointer exists in /usr/uv/demo2 pointing to the
STUDENT file in /usr/uv/demo.
The following example illustrates the repconfig file on System A:
GROUP=SAMPLE_ACCT
LEVEL=ACCOUNT
ACCOUNT=\U2\uv\test
FILE=SUB_WRITEABLE VOC
FILE=CUSTOMER
FILE=STUDENT
EXCLUDED_FILE=_XML_
EXCLUDED_FILE=_EDA.MAP_
EXCLUDED_FILE=ENGLISH.MSG
DISTRIBUTION=P:SystemA
DISTRIBUTION=IB:SystemB
DISTRIBUTION=D:SystemC
#Define tunable parameters
RESERVED_FILE_SPACE=500
N_LOGINFO=5120
REP_BUFSZ=163840
N_REPWRITER=2
RW_IGNORE_ERROR=1
RW_REEVALUATE_VF=0
RW_SKIP_TRIGGER=1
2-19 U2 Data Replication for UniVerse
The next example illustrates the repconfig file on System B:
GROUP=SAMPLE_ACCT
LEVEL=ACCOUNT
ACCOUNT=\U2\uv\demo
FILE=SUB_WRITEABLE VOC
FILE=CUSTOMER
FILE=STUDENT
EXCLUDED_FILE=_XML_
EXCLUDED_FILE=_EDA.MAP_
EXCLUDED_FILE=ENGLISH.MSG
DISTRIBUTION=IB:SystemB
DISTRIBUTION=P:SystemA
DISTRIBUTION=D:SystemC
#Define tunable parameters
RESERVED_FILE_SPACE=500
N_LOGINFO=5120
REP_BUFSZ=163840
N_REPWRITER=2
RW_IGNORE_ERROR=1
RW_REEVALUATE_VF=0
RW_SKIP_TRIGGER=1
Configuring U2 Data Replication 2-20
The next example illustrates the repconfig file on System C:
#Define the group name
GROUP=SampleGroup
#Define Local Account Path
ACCOUNT=/disk1/demo
#Define replication objects
FILE=SUB_WRITEABLE VOC
FILE=CUSTOMER
FILE=STUDENT
EXCLUDED_FILE=_XML_
EXCLUDED_FILE=_EDA.MAP_
EXCLUDED_FILE=ENGLISH.MSG
#Define distributions from System A to LOCAL
DISTRIBUTION=D:SystemC
DISTRIBUTION=P:SystemA
DISTRIBUTION=IB:SystemB
#Define configurable parameters
#Log info buffer size
N_LOGINFO=512
#Log buffer size
REP_BUFSZ=16384
#Define number of replication writer processes
N_REPWRITER=2
Default account-level replication file
The repacct.def file, located in the UVHOME directory, includes a default list of files to be included or excluded for each account-level replication group.
2-21 U2 Data Replication for UniVerse
Following is an example of the repacct.def file:
# Definition of default excluded objects for account replication
EXCLUDED_FILE=DICT.DICT
EXCLUDED_FILE=DICT.VOC
EXCLUDED_FILE=SQL.HELP
EXCLUDED_FILE=BCI.HELP
EXCLUDED_FILE=BASIC.HELP
EXCLUDED_FILE=HELP.FILE
EXCLUDED_FILE=ERRMSG
EXCLUDED_FILE=SYS.HELP
EXCLUDED_FILE=SYS.MESSAGE
EXCLUDED_FILE=SYS.TERMINALS
EXCLUDED_FILE=REVISE.DISCUSSIONS
EXCLUDED_FILE=REVISE.PROCESSES
EXCLUDED_FILE=STAT.FILE
EXCLUDED_FILE=UNIVERSE.STAT.FILE
EXCLUDED_FILE=TESTQ
EXCLUDED_FILE=&SAVEDLISTS&
EXCLUDED_FILE=&PARTFILES&
EXCLUDED_FILE=&COMO&
EXCLUDED_FILE=&PH&
EXCLUDED_FILE=&UFD&
EXCLUDED_FILE=&DEVICE&
EXCLUDED_FILE=UV;ACCESS
EXCLUDED_FILE=UV.ACCOUNT
EXCLUDED_FILE=UV.FLAVOR
EXCLUDED_FILE=UV_LOGS
EXCLUDED_FILE=UV.TRANS
EXCLUDED_FILE=UV_UDRPUB
EXCLUDED_FILE=UV_UDRSUB
EXCLUDED_FILE=UDRSYS
EXCLUDED_FILE=UV_SCHEMA
EXCLUDED_FILE=UV_ASSOC
EXCLUDED_FILE=UV_COLUMNS
EXCLUDED_FILE=UV_TABLES
EXCLUDED_FILE=UV_VIEWS
EXCLUDED_FILE=UV_USERS
FILE=SUB_WRITEABLE DATA VOC
FILE=SUB_WRITEABLE AE_DOC
FILE=SUB_WRITEABLE &MAP&
FILE=SUB_WRITEABLE &KEYSTORE&
FILE=SUB_WRITEABLE &SAVEDLISTS&
FILE=SUB_WRITEABLE PTERM.FILE
FILE=SUB_WRITEABLE UNIVERSE.MENU.
FILE FILE=SUB_WRITEABLE UV.SAVEDLISTS
Configuring U2 Data Replication 2-22
Defining replication on a publishing system
You must define each subscribing system location and each of the replication groups on the publishing system before you can start U2 Data Replication.
You can define publishing systems from the command line or from U2 Extensible Admin. From the Admin Tasks pane of the U2 Extensible Admin window, double-click Replication.
A dialog box similar to the following example appears:
2-23 U2 Data Replication for UniVerse
Define subscribing systems
To define remote replication systems, from the Replication dialog box, click the System Definition tab. A dialog box similar to the following example appears:
Defining replication on a publishing system 2-24
To add a system location, click Add. A dialog box similar to the following example appears:
Enter system ID
In the System ID box, enter the name of the subscribing system. The name of the subscribing system is the name given when you installed U2 Data Replication on your system. By default, this name is <hostname>_version.
Enter host name
In the Host Name box, enter the host network name or network address of the replication system.
2-25 U2 Data Replication for UniVerse
Enter UniVerse version
In the Version box, enter the UniVerse version running on the system. The version must be 111 or higher.
Define DHCP system
Select the DHCP check box if the remote system has a dynamic IP address.
For more information, see “DHCP phrase” on page 2-9.
Choose to auto resume
Auto Resume determines if replication to the system you specify will be synchronized and resume automatically when UniVerse starts, or after a reconfiguration. Select Yes if you want UniVerse to automatically resume processing, or No if you want to manually synchronize data and resume processing.
Define sync interval
In the Sync Interval box, select the time interval, in minutes, in which the replication system automatically synchronizes replication.
U2 Data Replication automatically synchronizes subscribing systems with their publisher every period defined by sync_interval. A sync_interval of 0 indicates a manual synchronization system, where UniVerse does not automatically synchronize the systems.
The synchronization interval is only valid when using deferred replication.
Choose connect authorization
If you select the Connect Authorization check box for a subscribing system,
U2 Data Replication verifies the login name and password when the subscribing system issues a SYNC request.
Define timeout interval
The timeout interval defines the number of seconds to wait if no packets are received before suspending replication.
Defining replication on a publishing system 2-26
The publishing system sends a packet to the subscribing system approximately every 4 seconds when replication is idle. The subscribing system then sends a packet back to the publishing system. If you define a timeout interval on the subscribing system, the publistener process counts the time that has elapsed between packets being received. If the amount exceeds the timeout interval, replication is suspended.
If you set the timeout value to 0, U2 Data Replication does not time out.
We recommend that you not set the timeout interval to less than 2 minutes.
Define exception action
The Exception Action is a shell script on UNIX platforms, or a batch program on
Windows platforms. Enter the full path to the trigger in the EXCEPTION_ACTION box. For example, if you define an exception action trigger as
UDRepExceptionAction.sh in the /usr/uv directory, set the full path as:
EXCEPTION_ACTION=/usr/uv/UVRepExceptionAction.sh
If you define an Exception Action on a subscribing system, whenever an exception occurs and suspends replication, U2 Data Replication invokes the
Exception Action script.
When you finish defining the subscribing system requirements, click OK to return to the Replication Admin dialog box.
Defining publishing groups from U2 Extensible Admin
Complete the following steps to define a publishing replication group from
U2 Extensible Admin.
2-27 U2 Data Replication for UniVerse
Adding a publishing group
To add a publishing group, click the Replication Group tab in the Replication dialog box, then click Add next to the Publishing Group area of the
Replication
dialog box. A dialog box similar to the following example appears:
Defining replication on a publishing system 2-28
Defining group name
In the Group ID box, enter a unique name for the publishing group.
Defining replication level
In the Level box, select the level of replication. Valid values are FILE or
ACCOUNT.
Specifying publishing account
In the Account box, select the local account where the replication group resides. U2 Extensible Admin automatically populates the Account Path box.
2-29 U2 Data Replication for UniVerse
Select files to publish
In the Files area of the Publishing Group Details dialog box, click Add to select the files you want to publish. A dialog box similar to the following example appears:
Click the file you want to publish.
Defining replication on a publishing system 2-30
When you have selected all the files you want to publish, click
OK
, or click
Cancel
to exit without saving changes. The Files area of the Publishing
Group Details
dialog box is populated, as shown in the following example: :
By default, both the data portion and the dictionary portion of the file are selected. If you do not want to publish the data portion of the file, clear the
Data
check box. If you do not want to publish the dictionary portion of the file, clear the Dict check box. If you want to be able to update the file on the subscribing system, select the Sub Writable check box.
2-31 U2 Data Replication for UniVerse
Select files to exclude
If you are using account-level replication, you can select files to exclude from
U2 Data Replication. In the Excluded Files area of the Publishing Group
Details
dialog box, click Add. A dialog box similar to the following example appears:
Select the files you want to exclude. When you finish selecting all the files you want to exclude, click OK to return to the Publishing Group Details dialog box.
Defining replication on a publishing system 2-32
Set configuration parameters
Set any of the configuration parameters necessary for your environment in the Configuration area of the Publishing Group Details dialog box, as shown in the following example:
For detailed information about these configuration parameters, see
“Configuration phrases” on page 2-17.
Defining publishing groups from the command line
Complete the following steps to define a publishing replication group from the command line:
1.
2.
Log on to the publishing system.
Edit the repsys file, located in the uvhome directory. Define all replication systems in the replication environment to which U2 Data
Replication may connect.
2-33 U2 Data Replication for UniVerse
3.
Edit the repconfig file, located in the uvhome directory. For each replication group, define the following information:
Assign a unique replication group name.
Define the replication level.
Define the location of the publishing account.
Define excluded files for account-level replication.
Define all files belonging to the file-level replication group.
Define the distribution for the group, including the publishing system and all subscribing systems to which it replicates.
Define the replication type for each of the distribution systems.
Set the replication group configurable parameters.
Restart UniVerse, or execute the uv_repadmin reconfig command.
Defining replication on a publishing system 2-34
Defining replication on a subscribing system
You must define the publishing system location and import the replication group definitions from that location. If the subscribing system you are defining is a standby system, you also need to define other subscribing systems, if any.
You can define publishing systems from the command line or from U2 Extensible Admin. From the Admin Tasks pane of the U2 Extensible Admin window, double-click Replication.
A dialog box similar to the following example appears:
2-35 U2 Data Replication for UniVerse
Define the publishing system location on subscribing system
To define remote replication systems, from the Replication dialog box, click the System Definition tab. A dialog box similar to the following example appears:
Defining replication on a subscribing system 2-36
Click Add. A dialog box similar to the following example appears:
Enter system ID
In the System ID box, enter the publishing system name.
Enter host name
In the Host Name box, enter the host network name or network address of the publishing system.
2-37 U2 Data Replication for UniVerse
Enter UniVerse version
In the Version box, enter the UniVerse version running on the system. The version must be 111 or higher.
Choose auto resume
Auto Resume determines if replication from the publishing system you specify will be synchronized and resume automatically when UniVerse starts, or after a reconfiguration. Select Yes if you want UniVerse to automatically resume processing, or No if you want to manually synchronize data and resume processing.
Define sync interval
If you are using deferred replication, in the Sync Interval box, select the time interval, in minutes, in which the replication system automatically synchronizes replication.
U2 Data Replication automatically issues a SYNC request to the publishing system every period defined by sync_interval. A sync_interval of 0 indicates a manual synchronization system, where UniVerse does not automatically synchronize the systems.
Define Ttmeout interval
The timeout interval defines the number of seconds to wait if no packets are received before suspending replication.
The publishing system sends a packet to the subscribing system approximately every 4 seconds when replication is idle. If the publishing system has the a timeout interval defined, the udsub process counts the time that has elapsed between packets being received. If the amount exceeds the timeout interval, replication is suspended.
We recommend that you not set the timeout interval to less than 2 minutes.
Define exception action
The Exception Action is a shell script on UNIX platforms, or a batch program on
Windows platforms. Enter the full path to the trigger in the EXCEPTION_ACTION
Defining replication on a subscribing system 2-38
box. For example, if you define an exception action trigger as
UDRepExceptionAction.sh in the /usr/uv directory, set the full path as:
EXCEPTION_ACTION=/usr/uv/UVRepExceptionAction.sh
Define connection user name and password to publishing system
If you select Connect Authorization on the subscribing system location definition on the publishing system, you must define the connection user name and password to the publishing system location. To define the connection user name and password to the publishing system, select the publishing system in the Replication System Definition dialog box, then click
Set Connection
. The Set Rep System Connection dialog box appears, as shown in the following example:
Enter the login name and the corresponding password. Re-enter the password. Click OK to return to the Replication System Definition dialog box.
2-39 U2 Data Replication for UniVerse
Define subscribing groups
In the Subscribing Groups area of the Replication dialog box, click Add. The
Subscribe Group Details
dialog box appears, as shown in the following example:
Defining replication on a subscribing system 2-40
Select publishing system
In the From System box, select the publishing system from which this subscribing system is receiving data.
Select group ID
Select the Group ID from the publishing system in the Group ID list.
When you select the Group ID, U2 Extensible Admin populates the file list and configuration parameters from the same Group ID on the publisher.
Select into account
Select the account to which you want to replicate data in the Into Account dialog box. U2 Extensible Admin automatically populates the Account Path box.
2-41 U2 Data Replication for UniVerse
Define type of replication
In the Distributions area of the Subscription Group Details dialog box, click the value in the Type box. The following list of replication types appears:
Select the type of replication you want for the subscriber.
Select hot standby
If the subscribing system will be used as a standby system, select the Hot
Standby
check box.
Defining replication on a subscribing system 2-42
The following example illustrates a completed definition for a subscribing system:
Click OK to save the subscribing group definition, or click Cancel to exit without saving changes.
Verify distribution information
In the Replication dialog box, select a subscribed group, then click Detail.
U2 Extensible Admin displays the distribution information for the publishing group in the Distributions area of the Publishing Group Details dialog box, as shown in the following example:
For information about distribution types, see
“DISTRIBUTION phrase” on page 2-16.
Defining subscribing groups from the command line
Complete the following steps to define a subscribing replication group from the command line:
1.
2.
Log on to the subscribing system.
Edit the repsys file, located in the uvhome directory. In this file, define all host systems to which the replication may connect.
2-43 U2 Data Replication for UniVerse
3.
4.
5.
Edit the repconfig file located in the uvhome directory. Define all the replication groups you want to replicate from the publisher. Make sure you use the same group name used on the publisher.
Copy the file list of the group from the publisher.
Define the publishing system according to the definition on the publisher.
Define the subscribing system, and define the replication type.
If you are going to use this system as a standby subscriber, define all other distributions of the group and their replication types, according to the definition on the publisher.
Set the replication group configurable parameters.
Define the subscribing account path in Replication.
Create the subscribing account, then copy all files from the publishing system to the subscribing system.
Restart UniVerse, or execute the uv_repadmin reconfig command to load the replication group definition and allocate system resources.
Defining replication on a subscribing system 2-44
Changing a replication group definition
You can change a replication group definition without having to stop and restart UniVerse.
2-45 U2 Data Replication for UniVerse
Change replication group definition from U2 Extensible Admin
To change a replication group definition, from the Replication dialog box, click the publishing group you want to update, then click Detail. A dialog box similar to the following example appears:
Make the appropriate changes, then click Finish.
Changing a replication group definition 2-46
After making your changes, you may need to resubscribe the group to update the subscriber system’s configuration.
Change replication group definition from the command line
The following steps describe reconfiguring U2 Data Replication from the command line:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Log on to the replication system you want to reconfigure.
Make your changes in the repsys and repconfig files.
Synchronize the reconfigured group from its publisher or to its subscriber.
Execute the RECONFIG command to request that the Replication
Manager reconfigure the replication group.
The Replication Manager executes the DBSetup -L command to block writes to the database. The Replication Manager requests that all replication groups suspend replication.
The Replication Manager reads the new repconfig and repsys files, and compares them to the original file.
The Replication Manager checks the consistency of the definition, and checks each of the groups that are changing to see if there are any replication logs not synchronized to its subscribers.
The Replication Manager reallocates shared memory segments, reloads the replication configurations, and the Inode and device number of each replication object.
The Replication Manager executes the DBSetup -U command to resume processing.
If you selected the AUTORESUME option, the Replication Manager synchronizes and resumes all real-time and immediate replication groups to its publishers and subscribers. If you did not select the
AUTORESUME option, you should synchronize manually.
2-47 U2 Data Replication for UniVerse
Processes added for U2 Data Replication
At UniVerse 11.1, daemons have been added for U2 Data Replication and cleaning up dead user processes.
A daemon is a background process that performs a specific task or set of tasks. Daemons wait in the background until they receive a request from their specific function. A number of standard UNIX daemons run on every UNIX platform to control system processes, schedule commands, handle print requests, and perform other similar functions. Refer to your host operating system documentation for detailed information about the UNIX daemons that run on your system.
On Windows platforms, services are used instead of daemons.
Shared memory manager
The Shared Memory Manager daemon, uvsmm, records all operating system resources, such as shm segments and semaphores, identifying which
UniVerse user holds each.
Replication manager daemon
The Replication Manager is a UniVerse daemon that must be running on the replication system. The publishing system and the subscribing system each have one replication manager. The replication manager performs the following tasks:
Reads and loads replication configuration information when
UniVerse starts
Creates replication processes for each replication group
Monitors and controls the replication process
Handles commands from Replication Admin and U2 Extensible
Admin
Dynamically reconfigures the replication environment
Handles failover replication, recovery, and synchronization of replication data
Processes added for U2 Data Replication 2-48
uvcleanupd daemon
The clean up daemon, uvcleanupd, detects terminated user processes at check time intervals. If uvcleanupd detects a terminated process, internal flags are set. The uvsmm daemon periodically checks to see if uvcleanupd has set internal flags. If it detects flags, uvsmm performs the necessary clean up, and resets its own flag to zero. The uvcleanupd daemon performs clean up that is not handled by uvsmm. When the uvsmm daemon has rest its flag to zero, the uvcleanupd daemon resets its flag to zero, makes the user signature available, an frees the local control table.
Both the uvlockd and uvcleanupd daemons are started when UniVerse starts.
Beginning at this release, the uvdlockd daemon only handles deadlocks.
uvcleanupd command
The uvcleanup command forces a clean up of resources owned by a terminated process. You must be a UniVerse administrator or the user that has the same signature as the terminated process to execute the uvcleanupd command.
Syntax
uvcleanupd {-p pid | -n sig}
Parameters
The following table describes each parameter of the syntax:
Parameter
-p pid
-n sig
Description
Instructs the uvcleanupd daemon to make the LCT entry for the pid you specify available, and allows the uvcleanupd daemon to clean up the entry.
Instructs the uvcleanupd daemon to make the LCT entry for the signature you specify available, and allows the uvcleanupd daemon to clean up the entry.
uvcleanupd Parameters
Note
: The -p and -n options should be used together. These two options are used to identify the matching LCT entry.
2-49 U2 Data Replication for UniVerse
Note: If the uvcleanupd daemon is cleaning up a terminated uvrw process, the information logged in the uvcleanupd.log file will contain additional information regarding the replication log being processed. This can be helpful in diagnosing unexpected 'uvrw' terminations.
Starting UniVerse daemons
Use one of the following commands to start the UniVerse daemons:
uv -admin -start [-init]
uv.rc start [init]
If you specify the -init option, U2 Data Replication clears the pending replication logs saved to synchronize the subscriber database. You can use this option for initial startup, or after refreshing a subscriber database.
Note
: Care should be taken when using the -init option, as improper use could cause the subscriber to be out of sync with the publisher.
Stopping UniVerse daemons
Use one of the following commands to stop the UniVerse daemons:
uv -admin -stop [-force]
uv.rc stop [force]
These commands check whether any users are still logged on to the system.
If users are logged on, UniVerse does not stop the system. If you specify the
-force option, UniVerse stops the system even if there are users logged on to the system.
Displaying UniVerse daemons
On UNIX systems, use the showuv command to display daemon processes currently running on the system. The following example illustrates output from the showuv command:
% /shire3/uv111/bin/showuv
USER PID TIME COMMAND
root 307326 0:00 /shire3/uv111/../unishared/unirpc/unirpcd
root 532674 0:01 /shire3/uv111/bin/uvcleanupd -t 15
root 618668 0:00 /shire3/uv111/bin/uvdlockd -config
root 549070 0:02 /shire3/uv111/bin/uvsmm -t 15Displaying smm
Processes added for U2 Data Replication 2-50
Use the uvsms command to display smm segment contents.
Syntax
uvsms
[options]
Options
The following table describes the options available for the uvsms command:
Option
-h
-G shm_id
-g shm_no
-L pid
-l lct_no
-S shm_id
Description
Displays the smm segment header.
Displays the specific shared memory segment you specify with shm_id.
Displays the specific shared memory segment you specify with shm_no.
Displays the specific LCT entry you specify with pid.
Displays the specific LCT entry you specify with lct_no.
Displays the LCT entry of the session where the shared memory segment is created.
uvsmm Options
Global control table
The Global Control Table (GCT) manages shared memory segments systemwide. This table is located in the Shared Memory Management segment. Each
GCT records the use of global pages in a shared memory segment. UniVerse determines the number of GCTs in the CTL by the configuration parameter
SHM_GNTBLS. SHM_GNTBLS must not exceed the kernel parameter shmmni.
2-51 U2 Data Replication for UniVerse
Local control tables
Each Local Control Table (LCT) records the shared memory activity of a
UniVerse process group. UniVerse determines the number of LCTs in the CTL by the NUSERS configuration parameter. Each LCT comprises four subtables:
Subtable Name
PI
CT
MI
CI
Description
Process Information table. Each PI table registers all processes within a process group.
Counter table. Each CT records information about the behavior of the process group.
Memory Information table. Each MI table records all global pages or self-created shared memory segments used by the process group.
Control Information table. Each CI table records all blocks allocated from shared memory for temporary buffers.
LCT Subtables
A process group related to a process group leader, or a user executing a
UniVerse system-level command from a UNIX prompt.
Terminology
The following table describes the UniVerse executable names for U2 Data
Replication for UniVerse.
Replication Component Executable Name
Shared Memory Manager Daemon
Stop Shared Memory Management Tool
Replication Manager Daemon
Show sms information uvsmm stopuvsmm uvrepmanager uvsms
Dead User Cleanup Daemon uvcleanupd
U2 Data Replication for UniVerse Executables
Processes added for U2 Data Replication 2-52
Replication Component Executable Name
Publisher Process
Subscriber Process
Replication Writer
Publisher Listener Process
Publisher Synching Tool
Replication Manager RPC Tool
Replication Diagnosis Tool
Stop Replication Manager Tool
Replication Admin Tool
Show UNIX daemons
Show format processing uvpub uvsub uvrw uvpublistener uvpubsyncer uvrmconn uvreptool stopuvrm uv_repadmin showuv psfmt
Test Process ID test_pid
Show host information hostinfo
U2 Data Replication for UniVerse Executables (continued)
The next table describes the U2 Data Replication for UniVerse services names.
Replication Service UniVerse Service Name
U2 Replication Service uvrep
Replication Manager Connection Service uvrmconn
UniVerse Data Replication Services
2-53 U2 Data Replication for UniVerse
The next table describes the U2 Data Replication for UniVerse daemon log files. These log files are located in the $UVHOME directory.
UV Replication Log File UniVerse System Log File
smm log file smm Error log file
Cleanup Daemon log file
Cleanup Daemon Error log file
Replication Manager log file
Replication Manager Error log file
Publisher Error log file uvsmm.log
uvsmm.errlog
uvcleanupd.log
uvcleanupd.errlog
uvrm.log
uvrm.errlog
uvpub<n>.errlog
Subscriber Error log file
Replication Writer Error log file uvsub<n>.errlog
uvrw.errlog
UV Dead Lock Daemon log file uvdlockd.log
U2 Data Replication for UniVerse Log Files
Processes added for U2 Data Replication 2-54
Chapter 3: How U2 Data
Replication works
Data propagation procedure . . . . . . . . . . . . . .
Suspending live replication . . . . . . . . . . . . . .
Data synchronization of suspended live replication . . . . .
Deferred replication . . . . . . . . . . . . . . . . .
Transaction handling . . . . . . . . . . . . . . . . .
Indexed virtual attributes . . . . . . . . . . . . . . .
File triggers . . . . . . . . . . . . . . . . . . . .
Partition algorithm check . . . . . . . . . . . . . . .
File-level operations . . . . . . . . . . . . . . . . .
File-level commands . . . . . . . . . . . . . . .
Chapter
3
UniVerse provides the following two types of live replication:
Real-time Replication is a type of U2 Data Replication where transactions on the publishing server do not commit until all logs of the transaction arrive at the subscriber. With this type of replication, should the publishing system failover to the real-time subscribing system, all committed transactions at the publishing system are guaranteed to apply to the standby system.
Immediate Replication is a type of U2 Data Replication where
UniVerse sends a transaction log to the subscribing system immediately after it is ready to commit. The publishing system does not wait for the log to arrive on the subscriber before committing the transaction. Should the publishing server failover to the immediate subscribing system, there is a slight chance that some committed transactions on the publisher will not arrive on the failover system.
Administrator intervention may be necessary to recover the system.
Note:
Immediate Replication has better performance than real-time replication.
For both types of live replication, the publishing system maintains network connections to its subscribers while it is running. UniVerse sends data updates on the publishing object to its subscribers through this connection immediately.
3-2
Data propagation procedure
The following steps describe the data propagation procedure for live replication.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Before UniVerse commits and updates, the uvsh process generates a replication log for the update and writes it to the replication buffer.
In real-time replication, the uvsh process waits for the response from the publisher process.
The publisher process reads the logs from the replication buffer and sends a package, through the network, to all subscribers.
When a subscriber receives a package, the subscriber process converts the data record, if necessary, and copies the logs to the replication buffer. It then sends a Sub-Got notification message to the publisher.
In real-time replication, the publisher process wakes up the waiting uvsh process after receiving the Sub-Got notification message.
The uvsh process commits the update to the database.
The uvsh process writes a Pub-Commit notification to the replication buffer. The publisher process sends the Pub-Commit notification to the subscribers in the next data package.
When the subscriber receives a Pub-Commit notification, it marks the Pub-Commit flag in the log in the replication buffer and wakes up the Replication Writer processes waiting for the log.
A Replication Writer process reads the log from the replication buffers once, and applies a logical lock for the record it is about to update. It then checks the Pub-Commit flag on the log and waits for the flag to be set by the subscriber. For the log of an update involved in a transaction, the Replication Writer process also has to wait for the arrival of the Transaction-end log.
Next, the Replication Writer process updates the subscribing objects according to the contents of the replication log.
The Replication Writer process then updates the Sub-Commit flag in the log to indicate that the log has been committed on the subscribing system, and releases the logical lock for the record.
3-3 U2 Data Replication for UniVerse
12.
13.
The subscriber sends back a Sub-Commit notification to the publishing system confirming that the update has been committed on the subscribing system.
When the publishing process receives the Sub-Commit notification message, it removes the logs from the replication buffer.
Data propagation procedure 3-4
Suspending live replication
System administrators can suspend live replication when subscribing systems shut down, crash, network failures occur, or for their own reason.
You can suspend replication by issuing the suspend command.
Note
: You can execute the suspend command from U2 Extensible Admin, or from the command line.
Syntax:
suspend
<targets>
If you do not specify a target, targets is assumed to be ALL, and UniVerse suspends all replications on the system. If you specify a replication, UniVerse suspends the replication from or to the system you specify. If you specify
target as a replication group, UniVerse suspends all distributions of the system you specify.
You typically use the suspend command before shutting down the publishing or subscribing system.
Note:
After UniVerse starts, the replications to all systems are suspended. You can
choose to set the AUTORESUME phrase in the repsys file to automatically resume
live replication.
The suspend command has no effect with deferred replication.
Example
In the following example, the suspend command is issued on SystemA to suspend replication on SystemB:
uv_repadmin suspend
SystemB
3-5 U2 Data Replication for UniVerse
To suspend a replication, the publishing system saves all replication logs without Sub-Commit notification to the Replication Log Reserve File. If the subscriber did not crash, it saves all logs without Pub-Commit notification to the Replication Log Reserve File. UniVerse then disrupts the connection between the publisher and the subscriber, and the subscriber process stops running.
When you suspend a replication, the publishing system runs in suspension mode. The uvsh process can read from or write to the database as usual.
Instead of sending replication logs to the subscriber, the publisher saves them in the Replication Log Reserve Files.
The following section describes how U2 Data Replication behaves in suspension mode:
1.
2.
3.
4.
5.
6.
7.
Before committing an update, the uvsh process generates replication logs for the update, and writes them to the replication buffer.
For real-time replication, the uvsh process waits for the response from the publisher process.
The publisher process reads the logs from the replication buffer and saves them to the Replication Log Reserve File.
For real-time replication, the publisher process wakes up the waiting uvsh process.
The uvsh process commits the update to the database.
The uvsh process writes the Pub-Commit notification to the replication buffer.
The publisher process removes the logs from the replication buffer.
Data synchronization of suspended live replication
You must synchronize suspended replication to resume replication to the running mode.
To synchronize the replication, use the SYNC command on the publishing or subscribing system. Your system administrator can configure a replication to automatically synchronize when UniVerse starts by defining AUTORESUME in the system definition.
Note
: You can execute the sync command from U2 Extensible Admin, or from the command line.
Suspending live replication 3-6
Syntax
sync
[-noresume | -wait | -force] <targets>
If you specify targets as ALL, UniVerse synchronizes replications on all systems. If you specify target as a replication system, UniVerse synchronizes replications from and/or to the replication system you specify. If you specify
target as a group, UniVerse synchronizes all replications of the group you specify.
The speed of the synchronization process depends on how many pending logs UniVerse must synchronize, and the speed of the network connection.
The sync command normally returns when all targets are in the synchronization mode.
By default, the sync command resumes a live replication. The following table describes the options available with the sync command.
Option Description
noresume UniVerse suspends a live replication when it finishes synchronizing the replication systems.
wait If you specify this option, the SYNC command does not return until all synchronizations you specify succeed or fail.
force The Replication Writer processes ignore the errors encountered during the synchronization process, if any. If you do not specify this option, the synchronization process fails if an error is encountered.
SYNC Command Options
Note:
After UniVerse starts, the replications to all systems are suspended. You can
choose to set the AUTORESUME phrase in the repsys file to automatically resume
live replication.
The sync command may fail if the network connection fails, or if the distribution of a replication conflicts between the publishing system and the subscribing system. UniVerse returns an error code to indicate the failure.
You can use the uv_repadmin report command to check the details of the error.
Note:
If you issue the sync command when a live replication is running, the command has no effect.
3-7 U2 Data Replication for UniVerse
When to issue the sync command
You should issue the sync command in the following circumstances:
After UniVerse starts on the subscribing system if you do not set the
AUTORESUME phrase in the repsys file.
After you suspend live replication from or to a system and you want to resume replication.
After failing over or reconfiguring a replication if you do not set the
AUTORESUME Phrase in the repsys file.
After UniVerse starts on the publishing system while some of the subscribing systems are running if you do not set the
AUTORESUME Phrase in the repsys file.
Example
In the following example, UniVerse resumes replication from SystemA to
SystemB:
uv_repadmin sync
-force SystemB
Note
: The -force option ignores any errors, if encountered.
How synchronization works
UniVerse completes the following steps when synchronizing suspended replication:
1.
2.
3.
4.
5.
The publishing system establishes a connection to the subscribing system and invokes the subscriber process.
The subscriber process creates the Replication Writer processes to read the logs from the replication buffer. The subscriber then begins listening for a data package.
The publishing system creates the Publisher Listener Process to listen to the return package from the subscriber process.
The publishing system creates the Publisher-syncing Tool process.
The Publisher-syncing Tool process reads the logs from the
Replication Log Reserve File and sends them to the subscriber.
Suspending live replication 3-8
6.
7.
8.
9.
10.
11.
12.
13.
When a package of replication log files arrive at the subscriber, the subscriber process converts the data record, if necessary, and copies the logs to the replication buffer. It then sends a Sub-Got notification message to the publisher.
A replication writer process reads the log from the replication buffers once, and applies a logical lock for the record it is about to update.
For the log of an update involved in a transaction, the Replication
Writer process also has to wait for the arrival of the Transaction-end log.
The replication writer process updates the database according to the contents of the replication log, and marks the Sub-Commit flag of the log to indicate the log has been committed on the subscribing system.
It then releases the logical lock for the record.
The subscriber process sends back the Sub-Commit notification message to the publishing system.
For every notification package received, the Publisher Listener
Process marks the Sub-Got and Sub-Commit flags of the logs.
When the Publisher-syncing Tool finishes sending all of the logs in the Replication Log Reserve File, it terminates.
After the Publisher-syncing Tool terminates, the publisher process checks to see if any new replication logs were generated during the synchronization process. If new replication logs exist, it begins at step 4 and repeats the synchronization process.
The publishing system now resumes replication in running mode.
3-9 U2 Data Replication for UniVerse
Deferred replication
In deferred replication, the publishing system does not keep connections to the subscribers active. UniVerse saves the data in the Replication Log Reserve
File instead of sending the data to the subscribers. Data synchronization is the only means of data propagation.
Deferred Replication has two types:
Periodic Replication has a predefined period of time when the replication system will automatically synchronize its data.
Manual-Sync Replication does not have a predefined synchronization period. Data propagation is achieved by the sync command.
Deferred replication is similar to the suspension mode of immediate replication. Following are the steps for data synchronization with deferred replication:
1.
2.
3.
4.
5.
6.
7.
The publishing system establishes a connection to the subscribing system and invokes the subscriber process.
The subscriber process creates the Replication Writer processes to read the logs from the replication buffer. The subscriber then begins listening for a data package.
The publishing system creates the Publisher Listener Process to listen to the return package from the subscriber process.
The publishing system creates the Publisher-syncing Tool process.
The Publisher-syncing Tool process reads the logs from the
Replication Log Reserve File and sends them to the subscriber.
When a package of replication log files arrive at the subscriber, the subscriber process converts the data record, if necessary, and copies the logs to the replication buffer. It then sends a Sub-Got notification message to the publisher.
A replication writer process reads the log from the replication buffers once, and applies a logical lock for the record it is about to update.
For the log of an update involved in a transaction, the Replication
Writer process also has to wait for the arrival of the Transaction-end log.
Deferred replication 3-10
8.
9.
10.
11.
12.
13.
The replication writer process updates the database according to the contents of the replication log, and marks the Sub-Commit flag of the log to indicate the log has been committed on the subscribing system.
It then releases the logical lock for the record.
The subscriber process sends back the Sub-Commit notification message to the publishing system.
For every notification package received, the Publisher Listener
Process marks the Sub-Got and Sub-Commit flags of the logs.
When the Publisher-syncing Tool finishes sending all of the logs in the Replication Log Reserve File, it terminates.
After the Publisher-syncing Tool terminates, the publisher process checks to see if any new replication logs were generated during the synchronization process. If new replication logs exist, it begins at step 4 and repeats the synchronization process.
The publishing system disconnects from the subscriber and returns replication to suspension mode.
3-11 U2 Data Replication for UniVerse
Transaction handling
The following section describes how U2 Data Replication handles transaction processing:
1.
2.
3.
4.
5.
6.
7.
At the beginning of the commit phase of a transaction, the uvsh process generates all replication logs for the updates of a replication object in the transaction. This process also generates a Transaction-
Begin and Transaction-End log for each of the replication groups involved in the transactions. A Transaction-Begin log contains the transaction ID, the number of replication groups involved in the transaction, and the number of updates within the replication group.
For each of the replication groups, the uvsh process writes the
Transaction-Begin log, the replication logs of all updates in the replication group, and the Transaction-End log to the replication buffer of the replication group. If you are using Real-time
Replication, the uvsh process waits for the Transaction-End log to ensure all logs of the transaction arrive at the subscribing system.
The publishing process sends the logs to the subscriber. In the case of deferred replication, UniVerse writes the logs to the Replication Log
Reserve File. When the publisher receives the Sub-Got notification message from the subscriber, it wakes up the uvsh process that is waiting.
The uvsh process commits the transaction.
The publishing process sends the Pub-Commit notification to the subscriber process.
When the subscriber process receives a Transaction-Begin log, it copies the log to the replication buffer. If the transaction is part of a cross-group transaction, it checks the Transaction Control Area for the Transaction Control Record for this transaction. If the Transaction
Control Record does not exist, it creates a new Transaction Control
Record and adds it to the Transaction Control Area.
When the subscriber process receives the data update logs of a transaction, it copies the logs to the replication buffer.
Transaction handling 3-12
8.
9.
10.
11.
12.
13.
When the subscriber process receives a Transaction-End log, it sets the Sub-Got flag in the Transaction-Begin log. If the transaction is part of a cross-group transaction, it increases the number of Sub-Got groups in the Transaction Control Record. If the number of Sub-Got groups is equal to the number of groups involved in the transaction, it then sets the Sub-Got flag in the Transaction Control Record and wakes all Replication Writer processes waiting for the Transaction
Control Record, then sends a Sub-Got notification message to the publishing system.
The Replication Writer process reads one data update log from the
Replication Buffer, applies a logical lock on the record it is about to update, then waits for the arrival of all of the replication logs involved in the transaction. It also waits for the Pub-Commit notification message from the publishing system.
The Replication Writer process updates the database according to the contents of the log files.
The Replication Writer process sets the Sub-Commit flag in the log, and increases the number of Sub-Commit logs in the Transaction-
Begin log. If the number of Sub-Commit logs equals the number of logs in the group for the transaction, it increases the number of Sub-
Commit groups involved in the transaction. If the number of Sub-
Commit groups equals the number of groups in the transaction, it sets the Sub-Commit flag in the Transaction Control Record to indicate the transaction has been committed on the subscribing system.
The subscriber process sends back a Sub-Commit notification message to the publishing system, and removes the Transaction
Control Record from the Transaction Control area.
The publishing system removes all logs related to the transaction from the replication buffer.
3-13 U2 Data Replication for UniVerse
Indexed virtual attributes
U2 Data Replication propagates the indexed virtual attribute values, as well as the record. The following two methods are available to propagate virtual attribute values:
Use the values evaluated on the publishing system. If the index is enabled, the uvsh process evaluates all indexed virtual attribute values before updating the record in the database. These values are also passed as a record to the subscribing systems. The Replication
Writer process then writes the values directly to the index file.
This method requires that the subscribing system have the same dictionary and index definition as the publishing system. It also requires that the indexes of the publishing system and the subscribing system be consistent. If one is enabled, the other must also be enabled.
Reevaluate indexed virtual attributes on the subscribing system.
This is the default setting. Before the Replication Writer process applies the replication log to the database, it evaluates all indexed virtual attribute values and saves them in the index file, if the index is enabled. If the index is disabled, it saves the record to the index log file, then the UPDATE.INDEX command evaluates the values.
Indexed virtual attributes 3-14
File triggers
If you set the value of RW_SKIP_TRIGGER to 1, if a subscribing object has triggers defined, the Replication Writer process will not execute the trigger when applying the replication log. Your database administrator can configure the replication group to execute the trigger by setting the value of
RW_SKIP_TRIGGER to 0 in the repconfig file. The default value is 0.
3-15 U2 Data Replication for UniVerse
Partition algorithm check
By default, when a replication writer applies the replication log to a distributed part file, it rechecks the partition algorithm. Your database administrator can configure the replication group to skip this check by setting the value of RW_VERIFY_PARTITION to 0 in the repconfig file.
Partition algorithm check 3-16
File-level operations
UniVerse supports the following file-level operations:
DIR file operations:
ED and VI
COPY
File-level commands
CREATE.FILE
DELETE.FILE
CLEAR.FILE
CNAME
SETFILE
Other commands:
BASIC
CATALOG
DECATALOG
DELETE.CATALOG
DELETE.LIST
COPY.LIST
SAVE.STACK
CREATE.ENCRYPTION.KEY
CREATE.ENCRYPTION.WALLET
GRANT.ENCRYPTION.KEY
REVOKE.ENCRYPTION.KEY
DELETE.ENCRYPTION.KEY
DELETE.ENCRYPTION.WALLET
WALLET.ADD.KEY
WALLET.REMOVE.KEY
SAVE.EDAMAP
3-17 U2 Data Replication for UniVerse
UniVerse does not support the following commands for replication at this release:
File-level commands
DEFINE.DF
DF.MODIFY
REBUILD.DF
CREATE.TRIGGER
DELETE.TRIGGER
RESIZE
CREATE.INDEX
DELETE.INDEX
BUILD.INDEX
SET.INDEX
DISABLE.INDEX
ENABLE.INDEX
ENCRYPT.INDEX
DECRYPT.INDEX
ENCRYPT.FILE
DECRYPT.FILE
EDA.CONVERT
CONFIGURE.FILE
UVFIXFILE
RECOVER.FILE
Note
: If you run the CREATE.INDEX, BUILD.INDEX, SET.INDEX, or
DELETE.INDEX commands against a published file, UniVerse writes a message to the rm.log file indicating the command that was run, the account where it was run, and the file it was run against.
File-level operations 3-18
SQL commands
ALTER TABLE
CREATE INDEX
CREATE SCHEMA
CREATE TRIGGER
CREATE VIEW
DROP INDEX
DROP SCHEMA
DROP TRIGGER
DROP VIEW
CONVERT.SQL
REVOKE
SET.SQL
Account Environment commands
SAVE.LIST
PREPARE.XML
INITIALIZE.CATALOG or init.catalog
CLEAN.ACCOUNT
CONVERT.VOC
D3RESTORE
DATE.FORMAT
MAKE.MAP.FILE
PASSWD
SET.CONVERT.TERM.EURO
SET.SYSTEM.EURO
SET.REMOTE.ID
SET.TELNET
UPDATE.ACCOUNT
XMLSETOPTIONS
Note
: The commands UniVerse does not support for replication can be executed on the subscribing system, they are not blocked.
3-19 U2 Data Replication for UniVerse
File-level commands
To replicate file-level commands, you must publish the target file. If the excluded file list contains that file, or if the file is disabled, UniVerse does not replicate the file-level command.
If a file-level command creates a new file, and UniVerse successfully enables the file for publication, UniVerse replicates the command to the subscriber.
If a file-level command automatically updates a VOC or dictionary file.
UniVerse replicates these updates, whether or not the VOC or dictionary file is published. These updates are also performed on the subscribing system when re-executing the command.
CREATE.FILE
When you execute the CREATE.FILE command, UniVerse enables the file for replication. If UniVerse successfully enables the file as a publishing file, it sends the command itself to the subscribing system for replication. When the subscribing system receives the CREATE.FILE log, the replication writer process applies an exclusive lock to the VOC entry for the file and re-executes the command.
After the replication writer process creates the file on the subscribing system, it enables the file for subscription. Updates on the file will also be replicated.
DELETE.FILE
When you execute the DELETE.FILE command, UniVerse checks if the file is published. If so, UniVerse sends the command to the subscribing system for replication.
The DELETE.FILE command automatically disables the publication and subscription of the file.
CNAME
The CNAME command changes both the physical name and VOC entry name for both the data file and its dictionary. The new file name must be an enabled publishing file or the CNAME command will not replicate on the subscribing system.
File-level operations 3-20
If you enable the new file as a replication file in a different replication group than the old file, UniVerse replicates the CNAME command in the group of the new file and does not synchronize it with other operations on the original file.
SETFILE
The SETFILE command creates a new VOC pointer, and also loads that pointer into the Replication File Table. If you delete the old VOC pointer using the DELETE.FILE command, the file may still replicate with the new
VOC pointer. UniVerse replicates SETFILE as a file-level operation, so the new pointer on the subscribing system is also loaded into the Replication File
Table.
UniVerse only replicates the Q-pointer itself.
Miscellaneous
If replication is between a UNIX platform and a Windows platform, UniVerse does not convert slashes contained in the path.
The replication of file-level operations may result in creation of a new operating-system level file on the subscribing system. UniVerse determines the owner of the file based on the following rules:
1.
2.
3.
If the replication writer process is impersonated by the RW_UID clause in the repconfig file, the owner of the new file is RW_UID.
If there is no RW_UID clause in the repconfig file, UniVerse carries the user login name from the publishing to the subscriber. UniVerse uses this login name as the owner of the new file if the login name exists on the subscribing system.
If there is no RW_UID clause in the repconfig file or the user login name does not exist on the subscribing system, UniVerse uses root for the owner of the file.
3-21 U2 Data Replication for UniVerse
Chapter 4: Failover and recovery
Chapter
4
Failing over a system . . . . . . . . . . . . . . . . .
Step-by-step instructions for soft failover . . . . . . . .
Step-by-step instructions for failback . . . . . . . . . .
Data recovery . . . . . . . . . . . . . . . . . . .
Recovery of a subscribing system . . . . . . . . . . .
Database refreshing . . . . . . . . . . . . . . . .
UniVerse Replication includes failover capabilities. Failover is a mechanism to convert a secondary standby subscribing system into a publishing system should the primary publishing system crash, supporting high availability of the database.
You can configure a subscribing system of a live replication as a standby system. Should the primary publishing system crash, your database administrator can choose to failover immediately to one of the standby systems. This system then becomes a publishing system after the failover.
Other subscribing systems must then subscribe from this system.
When the primary system restarts, the system should be failed over to a subscriber from the new publishing system.
Failover of real-time replication guarantees that all committed updates on the primary system commit on the standby system as well. For immediate replication, there is a chance that some updates committed on the primary system, but their logs may not have arrived on the standby system. You may need to refresh the database to keep the two databases consistent.
4-2 U2 Data Replication for UniVerse
Failing over a system
A database administrator can failover a system using the failover command.
This command converts a subscribing system to a publishing system, or a publishing system to a subscribing system.
Note
: You can execute the failover command from U2 Extensible Admin, or from the command line. For information about executing the suspend command from U2
Extensible Admin, see the
in Chapter 5, “Chapter 5: Administering U2 Data Replication for UniVerse.”
Syntax
failover
{-pub | -subto <system_name> | -back} <targets>
The following table describes the failover options.
Option
-pub
-subto
-back
Description
The failover command changes the replication to a publishing system on the local system. The local distribution of the replication must be a standby backup system.
If you specify the -subto option, UniVerse either changes a replication from a publishing system to a subscribing system, or changes the subscribing source to the system you specify with system_name.
UniVerse changes the replication back to the original configuration setting.
FAILOVER Options
If the failover process itself fails, it has to wait for the primary publishing system to recover before it can resume database functions. It may have to copy database files to the failed standby subscribing system to make its database consistent and synchronized.
Step-by-Step instructions for hard failover in case of primary system crash
Complete the following steps to failover a system:
Failing over a system 4-3
5.
6.
1.
2.
3.
4.
7.
When the primary publishing system crashes, UniVerse disrupts the connection between the publishing system and the subscribing system. The application running the publishing system stops, and the remote client application is disrupted.
Log on to the standby system as an administrator and issue the
“failover
–pub” command to fail over the current replication to become a publisher.
Client applications should log on to the standby system and start the server applications.
If there are other subscriber systems defined in the replication environment, log on to each of the systems as an administrator and issue the “failover
–subto standby_system” command to change them to subscribe from the standby system.
If AUTORESUME is not set, issue the “failover sync” command.
For real-time replication, recover the primary system with Transaction Logging or with file diagnostic and repair tools. Issue the
“failover
–subto standby_system” command to convert the system to a failed over subscriber.
For immediate replication, refresh the database following the steps in Database Refreshing.
Step-by-step instructions for soft failover
Complete the following steps for a soft failover:
1.
2.
3.
4.
Stop all applications running on the primary publishing system.
Monitor the standby system using U2 Extensible Admin to make sure it is in sync with the primary system.
Log on to the standby system as an administrator and issues the
“failover
–pub” command to convert it to a fail over publishing system.
Client applications should log on to the standby system and start the server applications.
4-4 U2 Data Replication for UniVerse
5.
6.
Log on to the primary system as an administrator and issue the
“failover
–subto standby_system” command to convert it to a failover subscriber system.
If there are other subscriber systems defined in the replication environment, log on to each system as an administrator and issue the
“failover
–subto standby_system” that changes them to subscribing systems from the standby system.
Step-by-step instructions for failback
Complete the following steps for a Failback system:
1.
2.
3.
4.
5.
6.
Stop all applications running on the standby system.
Monitor the standby system using U2 Extensible Admin to make sure it is in sync with the standby system.
Log on to the primary system as an administrator and issue the
“failover
–back” command to convert the system back to a publishing system.
Client applications should log on to the primary system and start the server applications.
Log on to the standby system as an administrator and issue the
“failover
–back” command to convert it back to a subscribing system.
If there are other subscribing systems defined in the replication environment, log on to each system as an administrator and issue the
“failover –back” command that changes them to a subscribing system from the primary system.
Failing over a system 4-5
Data recovery
Run UniVerse warmstart or file diagnostic and repair tools to recover the physical structure of the database. Failover to a real-time standby system can guarantee all committed transactions contain their full updates, and thus the consistency of the database. If failing over to an immediate replication system, you must refresh the database to synchronize the crashed database.
When you restart UniVerse, a publishing group always restarts as a publishing group, even if a failover occurred on the standby system. In this case, the database administrator must manually failover the replication group to a subscribing group using the failover command after UniVerse restarts.
Recovery of a subscribing system
Recovery of a subscribing system is the same as normal recovery of a
UniVerse system. The database administrator must manually start the system and run UniVerse’s warmstart or file diagnostic and repair tools to recover the physical structure of the database.
Resynchronization after recovery from subscribing system or network failure
If a subscribing system crashes or a network failure occurs, the publishing system saves replication logs that do not contain Sub-Commit notification logs to the Replication Log Reserve File. After recovery from this type of failure, the resynchronization process need only apply those saved logs to the subscribing system to make the subscribing database consistent with the publishing database.
The resynchronization process is same described in Chapter 2, “Chapter 2:
Installing and configuring U2 Data Replication for UniVerse.”
Database refreshing
Complete the following steps to refresh the database.
4-6 U2 Data Replication for UniVerse
1.
2.
3.
4.
5.
6.
Stop the subscribing system or failed over subscribing system.
Log on to the publishing system and issue the “reset –noresume” command to remove the pending log files.
Back up the published files using the uvbackup command.
Restore the files to the subscribing system.
Start the subscribing system. In case of crash recovery of the primary system, issue the “failover –subto standby_system” command to convert it to a subscribing system.
If AUTORESUME is not set, issue the “sync” command.
Data recovery 4-7
Chapter 5: Administering U2
Data Replication for UniVerse
Administering U2 Data Replication through U2 Extensible Admin .
Defining replication systems . . . . . . . . . . . . .
Adding a publishing group . . . . . . . . . . . . .
Adding a subscribing group . . . . . . . . . . . . .
Using the replication tool . . . . . . . . . . . . . .
Diagnosis utility . . . . . . . . . . . . . . . . .
Monitoring replication . . . . . . . . . . . . . . .
uv_repadmin tool . . . . . . . . . . . . . . . . . .
suspend command . . . . . . . . . . . . . . . .
sync command . . . . . . . . . . . . . . . . .
failover command . . . . . . . . . . . . . . . .
reconfig command . . . . . . . . . . . . . . . .
reset command . . . . . . . . . . . . . . . . .
report command . . . . . . . . . . . . . . . . .
Replication action trigger . . . . . . . . . . . . . . .
Replication action trigger example . . . . . . . . . . .
Listing replication files . . . . . . . . . . . . . . . .
Replication files with multiple VOC pointers . . . . . . . .
Chapter
5
This chapter describes administration tools for U2 Data Replication.
5-2
Administering U2 Data Replication through U2
Extensible Admin
To access the Replication dialog box, click Replication from U2 Extensible
Admin. A dialog box similar to the following example appears:
5-3 U2 Data Replication for UniVerse
Defining replication systems
To define replication systems, click the System Definition tab. A dialog box similar to the following example appears:
Administering U2 Data Replication through U2 Extensible Admin 5-4
To add a new system, click Add. The Replication System Definition dialog box appears, as shown in the following example:
Enter system ID
In the System ID box, enter the system name.
Enter host Name
In the Host Name box, enter the host network name or network address of the system.
5-5 U2 Data Replication for UniVerse
Enter UniVerse version
In the Version box, enter the UniVerse version on the system. The version must be 111 or higher.
Choose whether to auto resume
Auto resume determines if replication from the publishing system you specify will be synchronized and resume automatically when UniVerse starts, or after a reconfiguration. Select Yes if you want UniVerse to automatically resume processing, or No if you want to manually synchronize data and resume processing.
Define sync interval
In the Sync Interval box, select the time interval, in minutes, in which the replication system automatically synchronizes replication.
U2 Data Replication for Universe automatically issues a SYNC request to the publishing system every period defined by sync_interval. A sync_interval of 0 indicates a manual synchronization system, where UniVerse does not automatically synchronize the systems.
Define timeout interval
The timeout interval defines the number of seconds to wait if no packets are received before suspending replication.
The publishing system sends a packet to the subscribing system approximately every 4 seconds when replication is idle. If the publishing system had the timeout interval defined, the udsub process counts the time that has elapsed between packets being received. If the amount exceeds the timeout interval, replication is suspended.
We recommend that you not set the timeout interval to less than 2 minutes.
Define exception action
The Exception Action is a shell script on UNIX platforms, or a batch program on Windows platforms. Enter the full path to the trigger in the EXCEP-
TION_ACTION box, or click Browse to locate the path.
Administering U2 Data Replication through U2 Extensible Admin 5-6
Define account
To define an account for replication, click Add. The following window appears:
In the Account Name box, enter a name for the account.
Enter the full path to the account in the Account Path box, or click the arrow and select the full path to the account from the list.
The account information is written to the repsys file. You can refer to the account name in other areas of replication without having to specify the full path.
5-7 U2 Data Replication for UniVerse
Define connection user name and password to publishing system
If you select Connection Authorization on the subscribing system location definition on the publishing system, you must define the connection user name and password to the publishing system location. To define the connection user name and password to the publishing system, select the publishing system in the Replication System Definition dialog box, then click Set Connection. The following dialog box appears:
Enter the login name and the corresponding password. Reenter the password. Click Finish to return to the Replication System Definition dialog box.
Administering U2 Data Replication through U2 Extensible Admin 5-8
Adding a publishing group
To add a publishing group, from the Publishing Groups area of the Repli-
cation
dialog box, click Add. The Publishing Group Details dialog box appears, as shown in the following example:
In the Group ID box, enter the ID of the publishing group.
5-9 U2 Data Replication for UniVerse
Specify publishing account
Select the account where the files you want to publish reside from the
Account
list.
Define replication level
Select the level of replication you want from the Level list. You can select either account-level or file-level replication.
Administering U2 Data Replication through U2 Extensible Admin 5-10
Select files to publish
To add files to the publishing group, in the Files area of the Publishing
Group Details
dialog box, click Add. A dialog box similar to the following example appears, as shown in the following example:
Click the file you want to publish. You can select multiple files by clicking the file while holding down the CTRL key.
When you have selected all the files you want to publish, click Finish, or click
Cancel
to exit without saving changes.
UniVerse populates the Files portion of the Publishing Group Details dialog box, as
5-11 U2 Data Replication for UniVerse
shown in the following example:
By default, both the data portion and the dictionary portion of the file are selected. If you do not want to publish the data portion of the file, clear the
Data
check box. If you do not want to publish the dictionary portion of the file, clear the Dict check box. If you want to be able to update the file on the subscribing system, select the Sub Writable check box.
Administering U2 Data Replication through U2 Extensible Admin 5-12
Select files to exclude
If you are using account-level replication, you can select files to exclude from
U2 Data Replication. In the Excluded Files area of the Publishing Group
Details
dialog box, click Add. A dialog box similar to the following example appears:
Click the file you want to exclude. You can select multiple files by clicking the file while holding down the CTRL key.
When you finish select all the file you want to exclude, click Finish to return to the Publishing Group Details dialog box.
5-13 U2 Data Replication for UniVerse
Set configuration parameters
Set any of the configuration parameters necessary for your environment in the Configuration area of the Publishing Group Details dialog box, as shown in the following example:
Adding a subscribing group
Complete the following steps to define a subscribing replication group from
U2 Extensible Admin.
Administering U2 Data Replication through U2 Extensible Admin 5-14
In the Subscribed Groups area of the Replication dialog box, click Add. The
Subscribed Group Details
dialog box appears, as shown in the following example:
5-15 U2 Data Replication for UniVerse
In the From System list, select the publishing system from which this subscribing system is receiving data.
Select group ID
Select the Group ID from the publishing system in the Group ID list.
When you select the Group ID, U2 Extensible Admin populates the file list and configuration parameters from the same Group ID on the publishing system.
Select into account
Select the account to which you want to replicate data in the Into Account dialog box. U2 Extensible Admin automatically populates the Account Path box.
Select files to receive
Click the file you want to receive. You can select multiple files by clicking the file while holding down the CTRL key.
By default, both the data portion and the dictionary portion of the file are selected. If you do not want to receive the data portion of the file, clear the
Data
check box. If you do not want to receive the dictionary portion of the file, clear the Dict check box. If you want to be able to update the file on the subscribing system, select the Sub Writable check box.
If you do not want to receive one of the published files, select the file you do not want to receive, then click Delete.
Administering U2 Data Replication through U2 Extensible Admin 5-16
Define type of replication
In the Distributions area of the Subscription Group Details dialog box click the value in the Type box. The following dialog box appears:
Select the type of replication you want for the subscriber.
Select hot standby
If the subscribing system will be used as a standby system, select the Hot
Standby
check box.
5-17 U2 Data Replication for UniVerse
Set configuration parameters
Set any of the configuration parameters necessary for your environment in the Configuration area of the Subscribing Group Details dialog box, as shown in the following example:
Click Finish to save the subscribing group definition, or click Cancel to exit without saving changes.
Using the replication tool
From the Replication dialog box, click the Replication Tool tab. A dialog box similar to the following example appears:
You can execute the following administration options from the Replication
Tool
:
Administering U2 Data Replication through U2 Extensible Admin 5-18
Report – Reports the current status of a replication. This command is useful after a failure or failover occurs. For detailed information
about this command, see “report command” on page 5-36.
Sync – Synchronizes subscribing systems to their publishing systems. The publishing system establishes a connection to the subscribing system and invokes the subscribing process. UniVerse reads and transfers replication logs from the publishing system to the subscribing system. The subscribing system then applies the updates to the database. For detailed information about this commands, see
Reconfig – Reconfigures the replication configuration while
UniVerse is running. For detailed information about this command,
see “reconfig command” on page 5-34.
Suspend – Suspends a live replication. In a suspended mode,
UniVerse interrupts the connection between the publisher and the subscriber. The publishing system saves the replication log files to the Replication Logs Reserve File rather than transferring them to the subscribing systems. The subscribing system and all replication writer processes stop after they finish updating existing logs in the replication buffer. For detailed information about this command, see
“suspend command” on page 5-30.
Failover – Changes the replication direction on a local system, either from the local system to the publishing system or subscribing system, or changes the subscribing source distribution. For detailed
information about this command, see “failover command” on page 5-33.
Reset – The reset command clears saved replication logs in the
Replication Log Reserve File. Use the reset command after you copy or store database files, since the remaining replication logs are no longer useful. For detailed information about this command, see
Select targets
A target is a replication, a replication group, or a distribution of a replication group. A replication is all data replicated from a remote system to the local system, or from a local system to a remote system. A target definition of ALL represents all replications on the system. One command can have multiple targets.
5-19 U2 Data Replication for UniVerse
If you want to execute the command against all targets, select All in the
Targets
area of the Replication Tool dialog box.
If you want to select the replication to execute the command against, select the Selected option in the Targets area of the Replication Tool dialog box, then click Add. A dialog box similar to the following example appears:
Enter the target information, then click Finish, or click Cancel to exit without saving changes.
To execute a command, click the command you want to run, then click
Execute
. Any output from the command appears in the Status box.
Diagnosis utility
The Diagnosis Utility available from U2 Extensible Admin is used by U2
Engineering for diagnosing problems encountered with U2 Data Replication.
Administering U2 Data Replication through U2 Extensible Admin 5-20
Monitoring replication
The Replication Monitoring tool monitors connection status, data transferring, and whether or not the publisher and subscriber systems are synchronized.
To access the Replication Monitoring tool, from the Replication dialog box, click the Monitor Replications tab. The following dialog box appears:
The Replication Monitor can monitor two types of replication:
Publishing Replication – the data replication from the local system to a remote subscribing system, including all replication groups involved. A publishing system can have more than one Publishing
Replication defined.
Subscribing Replication – the data replication from a remote publishing system to the local system, including all replication groups involved. A subscribing system can have more than one
Subscribing Replication defined.
Replication name
Each UniVerse Replication is assigned a unique name on one system, consisting of the replication type and the remote system name. A replication type can be one of the following:
Immediate
Standby Immediate
5-21 U2 Data Replication for UniVerse
Realtime
Standby Realtime
Deferred
Choose the name of the replication you want to monitor from the Replica-
tions
list.
Note
: If a replication has failed over, it still belongs to the same Replication as it did before the failover, but the name changes.
Refreshing interval
You can define how often to refresh the Replication Monitor. The default interval is 3 seconds. Choose the number of seconds to refresh the monitor in the Interval in Seconds box.
Administering U2 Data Replication through U2 Extensible Admin 5-22
Starting the replication monitor
To start the Replication Monitor, click Start. The Replication Monitor starts, as shown in the following example:
Replication status
The Replication Status indicates whether the publisher and subscriber are connected. The status can be one of the following:
Green – The publisher and subscriber are connected for all groups involved in the replication.
Yellow – At least one of the replication groups has been suspended by an administrator.
Red – At least one of the replication groups has been terminated abnormally.
5-23 U2 Data Replication for UniVerse
Sync status
The Sync status indicates whether the subscribing database is synchronized with the publishing database. The status can be one of the following:
Green – The publishing and subscribing databases are synchronized.
Yellow – There are pending updates that have not been applied to the subscribing database.
Packet received
The number of packets received from the other party of the Replication.
Types of packets include data packets, confirmation packets, heartbeat packets and other control packets. Monitoring this information indicates whether the physical connection between the publishing database and the subscribing database is satisfactory. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
Packet sent
The number of packets that have been sent to the other party of the Replication. Types of packets include data packets, confirmation packets, heartbeat packets and other control packets. Monitoring this information indicates whether the physical connection between the publishing database and the subscribing database is satisfactory. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
Subscriber received
The number of data records that have been received by the subscriber. This number is cumulative from the last time UniVerse was started or U2 Data
Replication was reconfigured.
Note
: When monitoring a publishing replication this number may be out of date if the Replication Status is not green.
Administering U2 Data Replication through U2 Extensible Admin 5-24
Subscriber committed
The number of data records that have been committed on the subscribing database. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
Note
: When monitoring a publishing replication this number may be out of date if the Replication Status is not green.
Publisher committed
The number of data records that have been committed on the publishing database. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
TP total
The sum of all transactions committed in the replication groups on the local system. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
CGTPs resolved
The sum of all transactions committed across more than one replication group on the local system. This number is cumulative from the last time
UniVerse was started or U2 Data Replication was reconfigured.
Replication group status table
The Replication Group Status table displays the current status of each replication group belonging to the Replication you specify.
Group Name – The name of the replication group.
Status – The connection status between the publishing system and the subscribing system in the group. The status can be one of the following:
Green – The publisher and subscriber are connected in this group.
Yellow – The Replication group has been suspended by an administrator.
Red – The Replication group has terminated abnormally.
5-25 U2 Data Replication for UniVerse
In-Sync – Indicates whether the subscribing files are synchronized with the publishing files in the group. The In-Sync status can be one of the following:
Green – The publishing and subscribing databases are synchronized.
Yellow – There are pending updates in this Replication Group that have not been applied to the subscribing database.
Rep. Status – The current Replication Group status.
The status can be one of the following on the publishing system:
REP_RUNNING – The replication is running.
REP_SYNCING – The replication is performing synchronization.
REP_SUSPENDED – The replication is suspended.
REP_DO_SUSPEND – The replication is in the process of suspending.
REP_EXIT – The replication is suspended due to an abnormal termination.
The status can be one of the following on the subscribing system:
SUB_STOP – The replication is stopped.
SUB_EXIT – The subscribing system has exited abnormally.
SUB_SHUTDOWN – Replication on the subscribing system has been shut down.
SUB_RUNNING – Replication on the subscribing system is running.
SUB_DO_RECONFIG – A reconfiguration process is occurring on the subscribing system.
SUB_DO_SUSPEND – Replication is suspended on the subscribing system.
SUB_SYNCING – Replication is performing synchronization on the subscribing system.
SUB_RESYNCING – Replication is performing resynchronization on the subscribing system.
SUB_DO_FAILOVER – The subscribing system is performing a failover.
Administering U2 Data Replication through U2 Extensible Admin 5-26
Changed By – The event or reason that caused the Replication status to change. If the status changed due to an exception, this column displays the error category and error code. A detailed error string is available in the tool tips.
The following list describes the valid events or reasons that can cause a change in the Replication status:
PUB_STARTUP – The publishing system started.
SYS_STARTUP – The UniVerse system started.
AUTO_SYNC – Replication is automatically resuming.
PUB_REQUEST – A request was sent from the publishing system, or an event occurred on the publishing system resulting in a change of status.
SUB_REQUEST – A request was sent from the subscribing system, or an event occurred on the subscribing system resulting in a change of status.
DBA_ORDER – The system administrator issued a request resulting in a change of status.
RECONFIG – Replication is reconfiguring.
FAILOVER – A failover has occurred.
SCHEDULED – The repmanager process can only schedule a SYNC command for DEFERRED replication.
SYNCDONE – A sychronization process succeeded.
REMOTE_REQ – A subscribing system can request to execute a
SYNC command on the publishing system.
CGTP_SUSPEND – Cross-group transaction processing is suspended.
#Recv’d – The number of packets received in the group. Monitoring this number indicates if the physical connection between the publishing system and subscribing system is satisfactory.
#Sent – The number of packets sent in the group. Monitoring this number indicates if the physical connection between the publishing system and subscribing system is satisfactory. This number is cumulative from the last time UniVerse was started or U2 Data
Replication was reconfigured.
Data Replicated – The total amount of data, in bytes, replicated in the group. On a publishing system this field represents the total amount of
5-27 U2 Data Replication for UniVerse
data sent out. On a subscribing system, this field represents the total amount of data received from the publishing system. This number is cumulative from the last time UniVerse was started or UniData
Replication was reconfigured.
SubGot – The Log Sequential Number of the latest replication log received by the subscribing system. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
SubAvail – The log has been loaded into the replication buffer and is available for the replication writer processes.
SubDone – The Log Sequential Number of the latest replication log committed to the subscribing database. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
PubDone – The Log Sequential Number of the latest replication log committed to the publishing database. This number is cumulative from the last time UniVerse was started or U2 Data Replication was reconfigured.
#TP – The number of transactions resolved in this group, including cross-group transactions. This number is cumulative from the last time
UniVerse was started or U2 Data Replication was reconfigured.
Administering U2 Data Replication through U2 Extensible Admin 5-28
uv_repadmin tool
The uv_repadmin tool is an interface between the database administrator and the Replication Manager daemon. This tool sends commands to the
Replication Manager and receives feedback. Issue the uv_repadmin command from the operating system-level.
Syntax:
uv_repadmin
<command> [<options>] [<targets>]
The following table describes each parameter of the syntax.
Parameter Description
command The command to send to the replication manager. Each command is documented later in this chapter.
options The options you want to send with the command. One command can have multiple options, separated by a space. Details of each option are documented with the command later in this chapter.
targets
See “uv_repadmin targets” on page 5-29.
uv_repadmin Parameters
uv_repadmin targets
A target of the uv_repadmin tool is a replication, a replication group, or a distribution of a replication group. A replication is all data replicated from a remote system to the local system, or from a local system to a remote system.
A target definition of ALL represents all replications on the system. One uv_repadmin command can have multiple targets.
Targets are separated by commas, and have the following syntax:
ALL | {<replication> | <group>} [,<replication> | <group>...]
5-29 U2 Data Replication for UniVerse
The following table describes each parameter of the targets syntax.
Parameter
replication group
Value
The replication to or from the system you specify.
PUBLISHING
<system_name>
The replication from the system you specify to the local system.
SUBSCRIBING
<system_name>
system_name
The replication from the local system to the system you specify.
Replication to and from the system you specify.
The group that is the target of the command.
GROUP
<group_name>
The name of the replication group.
DISTRIB
<system_name>
The distribution of the group you specify.
none All distributions of the group.
targets Syntax Parameters
If the command you issue through the uv_repadmin tool is successful, uv_repadmin returns 0. If the command is not successful, uv_repadmin returns an error code.
You can specify the -verbose option with any uv_repadmin command you issue to provide more detailed information about the results or errors associated with the command.
suspend command
The suspend command suspends a live replication. In a suspended mode,
UniVerse interrupts the connection between the publisher and the subscriber.
The publishing system saves the replication log files to the Replication Logs rather than transferring them to the subscribing systems. The subscribing system and all replication writer processes stop after they finish updating existing logs in the replication buffer.
uv_repadmin tool 5-30
Syntax:
suspend
<targets>
If you specify targets as ALL, UniVerse suspends all replications on the system. If you specify a replication, UniVerse suspends the replication from or to the system you specify. If you specify target as a replication group,
UniVerse suspends all distributions of the group you specify.
You typically use the suspend command before shutting down the publishing or subscribing system.
Note:
After UniVerse starts, the replications to all systems are suspended. You can
choose to set the AUTORESUME phrase in the repsys file to automatically resume
live replication.
The suspend command has no effect with deferred replication.
Example
In the following example, the suspend command is issued on SystemA to suspend replication on SystemB:
uv_repadmin suspend
SystemB
sync command
The sync command synchronizes subscribing systems to their publishing systems. The publishing system establishes a connection to the subscribing system and invokes the subscribing process. UniVerse reads and transfers replication logs from the publishing system to the subscribing system. The subscribing system then applies the updates to the database.
Syntax
sync
[-noresume | -wait | -force] <targets>
If you specify targets as ALL, UniVerse synchronizes replications on all systems. If you specify target as a replication system, UniVerse synchronizes replications from and/or to the replication system you specify. If you specify
target as a group, UniVerse synchronizes all replications of the group you specify.
5-31 U2 Data Replication for UniVerse
The speed of the synchronization process depends on how many pending logs UniVerse must synchronize, and the speed of the network connection.
The sync command normally returns when all targets are in the synchronization mode.
By default, the sync command resumes a live replication. The following table describes the options available with the sync command.
Option Description
noresume UniVerse suspends a live replication when it finishes synchronizing the replication systems.
wait If you specify this option, the SYNC command does not return until all synchronizations you specify succeed or fail.
force The Replication Writer processes ignore the errors encountered during the synchronization process, if any. If you do not specify this option, the synchronization process fails if an error is encountered.
SYNC Command Options
Note:
After UniVerse starts, the replications to all systems are suspended. You can
choose to set the AUTORESUME phrase in the repsys file to automatically resume
live replication.
The sync command may fail if the network connection fails, or if the distribution of a replication conflicts between the publishing system and the subscribing system. UniVerse returns an error code to indicate the failure.
You can use the REPORT command to check the details of the error.
Note:
If you issue the sync command when a live replication is running, the command has no effect.
When to issue the sync command
You should issue the sync command in the following circumstances:
After UniVerse starts on the subscribing system if you do not set the
AUTORESUME phrase in the repsys file.
After you suspend live replication from or to a system and you want to resume replication.
After failing over or reconfiguring a replication if you do not set the
AUTORESUME Phrase in the repsys file.
uv_repadmin tool 5-32
After UniVerse starts on the publishing system while some of the subscribing systems are running and you do not set the
AUTORESUME phrase in the repsys file.
Example
In the following example, UniVerse resumes replication from SystemA to
SystemB:
uv_repadmin sync
-force SystemB
failover command
The failover command changes the replication direction on a local system, either from the local system to the publishing system or subscribing system, or changes the subscribing source distribution.
Syntax
failover
{-pub | -subto <system_name> | -back} <targets>
The following table describes the failover options.
Option
-pub
-subto
-back
Description
The failover command changes the replication to a publishing system on the local system. The local distribution of the replication must be a standby backup system.
If you specify the -subto option, UniVerse either changes a replication from a publishing system to a subscribing system, or changes the subscribing source to the system you specify with system_name.
UniVerse changes the replication back to the original configuration setting.
FAILOVER Options
5-33 U2 Data Replication for UniVerse
Example
Suppose that SystemA crashes, and you want to failover to SystemB. On
System B, execute the following command:
uv_repadmin failover
-pub
On SystemC, change the subscribing source from SystemA to SystemB with the following command:
uv_repadmin failover
-subto SystemB
On SystemC, you should change the replication from a publishing system to a subscribing system on SystemB using the following command:
uv_repadmin failover
-subto SystemB
If you want to revert to the original replication directions, execute the following command on SystemA and on SystemC:
uv_repadmin failover
-back SystemB
In this case, SystemB represents all replication groups replicating data from
SystemB to a local system (SystemA or SystemC).
On SystemB, you should execute the following command to change all groups currently publishing to SystemA to their original distribution setting:
uv_repadmin failover
-back SystemA
Note
: The failover command does not change the distribution definition in the repconfig file. Instead, it records the failover status in an internal group status file for all replication groups involved. Even after you stop and restart UniVerse, U2 Data
Replication maintains this failover status. Issue another failover command, or issue the reconfig command to change the failover status.
After UniVerse starts, the replications to all systems are suspended. You can choose to set the
in the repsys file to automatically resume live replication.
reconfig command
The reconfig command reconfigures the replication configuration while
UniVerse is running.
uv_repadmin tool 5-34
Syntax
reconfig
When you issue the reconfig command, the Replication Manager completes the following tasks:
Issues the DBsetup -L command to block any writes to the database
Stops all replications
Reloads the repconfig file
Reallocates system resources
Restarts the publishing system for each publishing group
Issues the DBsetup -U command to continue processing on the database
Note:
After UniVerse resumes processing, the replications to all systems are
suspended. You can choose to set the AUTORESUME phrase in the repsys file to
automatically resume live replication.
reset command
The reset command clears saved replication logs in the Replication Log
Reserve File.
Syntax
reset
[-noresume] <targets>
Use the reset command after you copy or store database files, since the remaining replication logs are no longer useful.
Use the reset command with a deferred replication, or a live replication in suspension mode. If the target you specify is running, the reset command has no effect.
Unless you specify the -noresume option, a live replication returns to running mode from suspension mode when the reset command finishes processing.
5-35 U2 Data Replication for UniVerse
report command
The report command reports the current status of a replication you specify.
This command is useful after a failure or failover occurs.
Syntax
report
[-detail | -xml] <targets>
Each line of the report represents the status of a replication. Each line has the following format:
[PUBLISHING | SUBSCRIBING] <system_name>=<Status>[:<Reason>]
The system_name is the name you specify in the repsys file.
Status is the current status of the replication. The following table describes valid statuses.
Status
RUNNING
SUSPEND
SUSPENDING
SYNCING
RECONFIGURING
SHUTDOWN
STOPPED
EXIT
Description
The replication is running.
The replication is in suspension mode.
The replication is in the process of suspending processing.
The replication is synchronizing data.
The replication is in the process of reconfiguring.
The replication is shutting down.
The replication has stopped normally.
The replication has exited abnormally.
Replication Statuses
uv_repadmin tool 5-36
If the replication status is SUSPEND, the report command also displays the reason that the replication is in suspension mode. The following table describes valid SUSPEND reasons.
Reason Description
STARTUP
DBA_ORDERED
REMOTE_REQUEST
SYS_RECONFIG
The local system is just starting or restarting.
The administrator suspended replication.
A remote system requested that replication be suspended.
The system is in suspension mode after a reconfiguration.
The remote system has shut down.
The connection is lost and cannot be reestablished.
REMOTE_SYS_DOWN
RPC_FAILURE
RPC_TIMEOUT The sending or receiving process has timed out.
SUBSCRIBER_FAILURE The subscriber failed to write a replication log. The detailed error message appears in the rm.errlog.
TRANSACTION_ABORT A transaction aborted on the subscribing system. The detailed error message appears in the rm.errlog.
FATAL_ERROR A internal or fatal error occurred from which the system is unable to recover.
SUSPEND Reasons
If the replication status is EXIT, UniVerse also displays the reason for the publishing system exit. The following table describes the valid reasons.
Reason Description
HAS_FAILOVER
DISTRIBUTION_MISMATCH A mismatch exists between the distribution on the publishing system and the subscribing system.
FATAL_ERROR
The subscribing system failed over to the publishing system.
A internal or fatal error occurred from which the system is unable to recover.
EXIT Reasons
5-37 U2 Data Replication for UniVerse
If you specify the -detail option, UniVerse reports the status of all replication groups after the replication status lines. The syntax of the replication group status is:
<group_name>=<status>:<reason> where group_name is the replication group name defined in the repconfig file.
The <status> and <reason> are the same as those for the replication status.
The -xml option reports detailed replication status information in XML format, regardless of whether you specify -detail.
The following example illustrates a replication status report in XML format:
<? Xml version=”1.0”?>
<REP_REPORT LOCAL_SYSTEM=“Trigger_71” DATE=“Thu Oct 5 16:02:46 2006”>
<REPLICATION REMOTE_SYSTEM = “Juneau_71”REPTYPE = “STANDBY IMMEDIATE
PUBLISHING” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” >
<GROUP NAME = “reptest1” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” />
<GROUP NAME = “reptest2” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” />
<GROUP NAME = “reptest3” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” />
</REPLICATION>
<REPLICATION REMOTE_SYSTEM = “Pinto_71” REPTYPE = “FAILOVER IMMEDIATE
PUBLISHING” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” >
<GROUP NAME = “reptest1” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” />
<GROUP NAME = “reptest2” SATUS = “REP_RUNNING” REASON = “Sync Succeeded” />
</REPLICATION>
</REP_REPORT>
The following example shows the DTD for the XML report shown above:
<!—REP_REPORT.DTD -->
<! ELEMENT REP_REPORT (REPLICATION*)>
<! ATTLIST REP_REPORT
LOCAL_SYSTEM CDATA #REQUIRED
DATE CDATA #REQUIRED>
<! ELEMENT REPLICATION (GROUP*)>
<! ATTLIST REPLICATION
REMOTE_SYSTEM CDATA #REQUIRED
REPTYPE CDATA #REQUIRED
STATUS CDATA #IMPLIED
REASON CDATA # IMPLIED >
<! ELEMENT GROUP EMPTY>
<! ATTLIST GROUP
NAME CDATA #REQUIRED
STATUS CDATA #IMPLIED
REASON CDATA #IMPLIED>
uv_repadmin tool 5-38
Replication action trigger
A replication action trigger allows you to define an action to take should replication abnormally terminate, making the Replication Status Indicator
Red. The repmanager process initializes the action defined in the trigger whenever it receives a replication exception notice.
The replication action trigger is a shell script on UNIX platforms, or a batch program on Windows platforms. Define the full path to the trigger using the
EXCEPTION_ACTION clause in the repsys file. For example, if you define a replication action trigger as UDRepExceptionAction.sh in the /usr/uv directory, set the EXCEPTION_ACTION clause as:
EXCEPTION_ACTION=/usr/uv/UVRepExceptionAction.sh
U2 Data Replication passes parameters to the replication action trigger through environment variables. You can use the following environment variables in the replication action trigger program:
UNIREP_REMOTESYS – the remote system name of the Replication.
UNIREP_REPTYPE defines the type of Replication.
UNIREP_GRPNAME – the replication group name where the exception occurred.
UNIREP_ERRCODE – the exception error code.
UNIREP_ERRSTRING – the exception error string.
If a Replication contains multiple replication groups, U2 Data Replication treats the interruption of each group as a separate event, and executes the trigger for that group. If a single group belongs to multiple Replications, each interruption of the Replication triggers the replication action trigger to run.
UNIREP_REMOTESYS and UNIREP_REPTYPE define the Replication where the exception occurred.
We recommend using the replication action trigger to automatically ping or email the system administrator to advise that an exception occurred. We do not recommend using it to automatically failover to a standby system.
Note that the replication action trigger only executes if an unexpected event that suspends U2 Data Replication occurs. If a system administrator executes a command that suspends U2 Data Replication, the replication action trigger is not invoked.
5-39 U2 Data Replication for UniVerse
When the replication action trigger is executed, the repmanager process writes a message similar to the following example in the rm.log:
Execute Replication Exception Action program <program_path>
Replication action trigger 5-40
Replication action trigger example
The following example illustrations a replication action trigger shell script:#
Replication Status Code that returned by ud_repadmin report command
#
# Publishing group Status Codes
PUB_STOP=1 #/* group is normally stopped */
PUB_EXIT=2 #/* group has quit abnormally.*/
PUB_SHUTDOWN=3 #/* group is doing shutdown */
PUB_RUNNING=4 #/* group is in running mode */
PUB_DO_RECONFIG=5 #/* group is doing reconfigure */
PUB_DO_FAILOVER=7 #/* group is doing failover */
# Publishing Replication Status Codes
REP_RUNNING=11 #/* replication is in running mode */
REP_SUSPENDED=12 #/* replication is in suspension mode */
REP_SYNCING=13 #/* replication is in syncing mode */
REP_DO_SUSPEND=14 #/* replication is doing suspend */
REP_DO_SYNC=15 #/* replication is doing sync */
REP_EXIT=16 #/* replication exit */
# Subscribing Replication/group status codes.
SUB_STOP=21 #/* group is normally stopped */
SUB_EXIT=22 #/* group has quit abnormally.*/
SUB_SHUTDOWN=23 #/* group is doing shutdown */
SUB_RUNNING=24 #/* replication is in running mode */
SUB_DO_RECONFIG=25 #/* group is doing reconfigure */
SUB_DO_SUSPEND=27 #/* replication is suspending */
SUB_SYNCING=28 #/* replication is doing sync */
SUB_DO_FAILOVER=29 #/* group is doing failover */
SUB_RESYNCING=30 #/* group is doing re-syncing */
# Defines Replication Groups
REP_GROUPS=”inventory_acct_g0 inventory_file_g1 payroll_acct_g2 payroll_file_g3 inv_acct_g4 inv_file_g5 pay_acct_g6 pay_file_g7”
# Define UV Environment Variables export UVHOME=`cat /.uvhome` export UVBIN=$UVHOME/bin
PATH=$PATH:$UVBIN
# Show exception time echo dstring=`date` reportfilename=’/disk1/uv/RepExcept.errlog’ echo “UniVerse Replication Exception called at:”$dstring > $reportfilename echo “UVBIN=$UVBIN” >> $reportfilename echo “UVHOME=$UVHOME” >> $reportfilename
# Show environment variables passed from replication system echo “UNIREP_REMOTESYS=”$UNIREP_REMOTESYS >> $reportfilename echo “UNIREP_REPTYPE=”$UNIREP_REPTYPE >> $reportfilename echo “UNIREP_GRPNAME=”$UNIREP_GRPNAME >> $reportfilename echo “UNIREP_ERRCODE=”$UNIREP_ERRCODE >> $reportfilename echo “UNIREP_ERRSTRING=”$UNIREP_ERRSTRING >> $reportfilename echo “Please See “$reportfilename” for more information” >> $reportfilename
# Now Paging to DBA
# sendmail
# echo “Subject: REPLICATION SUSPENDED” | cat - $reportfilename |
/usr/lib/sendmail -F UniData_Primary -t [email protected]
# Now Check all groups are suspended.
5-41 U2 Data Replication for UniVerse
# Using uv_repadmin REPORT command on each of the groups
# ud_repadmin REPORT -XML can be used by a DBA to get a formatted report for all groups.
all_suspended=0 try=0 while [ $all_suspended = 0 -a $try -lt 10 ] do
sleep 5
all_suspended=1
for grpname in $REP_GROUPS
do
if [ $all_suspended ]
then
# Run uv_repadmin report command
cmd=”$UVBIN/uv_repadmin REPORT GROUP $grpname DISTRIB
$UNIREP_REMOTESYS”
echo “Try Counter is “$try >> $reportfilename
echo “Now running:”$cmd >> $reportfilename
$cmd
returncode=$?
echo “returncode=$returncode” >> $reportfilename
if [ $returncode -gt 30 ]
then
#report command failed
echo “Report command failed, exit.” >> $reportfilename
exit 2
elif [ $returncode = $REP_SUSPENDED -o $returncode = $SUB_STOP -o
$returncode = $SUB_EXIT ]
then
echo “Group $grpname is suspended.” >> $ filename
else
all_suspended=0
fi
fi
done
try=`expr $try + 1` done if [ $all_suspended = 0 ] then
echo “Number of Try’s Exceeded to Confirm All Groups Suspended” >>
$reportfilename fi
# Try automatically sync and resume
# only run on one system in the replication (normally sub) - this avoids reciprocal firing of script
# sleep 60
# cmd=”$UVBIN/uv_repadmin sync -wait -verbose $UNIREP_REMOTESYS”
# echo “Now running:”$cmd >> $reportfilename
# $cmd >> $reportfilename
# echo “Return code=”$? >> $reportfilename exit 0
Replication action trigger 5-42
Listing replication files
Use the LIST.REPLICATION.FILE to list active replication files in your application. This command lists all replication file entries for an account or file you specify.
LIST.REPLICATION.FILE [ALL |DICT |DATA] filename[,subfile]
NO.PAGE
If you specify ALL, UniVerse displays all active replication files in the current account. If the local account is an account-level replication account, this command displays the account as well.
If you specify a file name, UniVerse displays all replication files contained in the Replication File Table related to that file. If you do not specify ALL or
filename, UniVerse obtains the file names from an active select list, or prompts for input.
LIST.REPLICATION.FILE displays the following information about replicated files:
FTYPE – The type of file. Valid file types are:
LF – LF directory
DICT – Dictionary file
DATA – Hashed file
QDICT – Q-pointer dictionary file
QDATA – Q-pointer data file
QLF – Q-pointer LF directory
ACCT – The account-level replication account
FILE NAME – The VOC file name in the Replication File Table. If the replication file is not located in the local account, the
LIST.REPLICATION.FILE command also lists the path to the file.
5-43 U2 Data Replication for UniVerse
REPLICATION – The replication definition for the file.
PUBLISHED – The file is published
SUBSCRIBED – The file is subscribed
EXCLUDED – The file is excluded from replication
INACTIVE – The file is included in replication, but is currently disabled
PRIMARY – Whether the file is considered the primary replication file.
GROUP – The name of the replication group
Note: When using account-level file replication, a UniVerse distributed file (Type 27
file) and all its part files are loaded separately in a Replication Object Table, where U2
Replication treats them all as separate files. The update on a distributed file is replicated through the part files. When an uvsh session updates a distributed file, or updates the distributed part file directly, the update is replicated with the part file’s name. This requires that the subscriber has the same definition of the distributed file as is on publisher system. Otherwise, data inconsistency may occur.
Listing replication files 5-44
Replication files with multiple VOC pointers
If a file has multiple definitions in the VOC file, in the same or different account, UniVerse loads each VOC item name in different replication file entries. When a uvsh process updates a record in the file, the process searches for the primary replication file entry in the Replication File Table by the ino/d-no, beginning from the static replication file entries. If there is no match, UniVerse searches the dynamic replication file entries. UniVerse uses the first match for replication, generating a replication log in the associated replication group, and sending the VOC file name to the subscriber for publication. This VOC name is referred to as the primary replication file.
When you issue a DELETE.FILE command that physically deletes the file,
UniVerse disables all replication file entries with the same i-no/d-no. If you delete a VOC pointer that points to the file, or a symbolic link or physical link,
UniVerse only disables the corresponding replication file entry. UniVerse does not disable other replication file entries pointing to the file. If you disable the primary replication file, UniVerse uses the next matched file as the primary replication file.
When you enable a replication file, UniVerse only enables the corresponding
VOC file name and account ID, it does not automatically search and enable other VOC file names that point to the same file.
When you replicate a file-level command, UniVerse uses the corresponding replication file entry for the target file regardless if it is the primary replication file or a secondary replication file. UniVerse always replicates recordlevel commands through the primary replication file.
If you have multiple VOC file entries for a replication file, we recommend that you define only one VOC name in the included file list so UniVerse knows which file name and which replication group to use with replication.
5-45 U2 Data Replication for UniVerse
Chapter 6: Restrictions
File types . . . . . . . . . . . . . . . . . . .
Changing inode or device numbers . . . . . . . . . .
One replication object can only belong to one group . . . .
System files not supported as replication objects . . . . . .
No cascading replication . . . . . . . . . . . . . .
Writeable subscriber files . . . . . . . . . . . . . .
Other command replication . . . . . . . . . . . . .
Virtual field definitions . . . . . . . . . . . . . .
Sequence of updates . . . . . . . . . . . . . . .
Transaction limitations . . . . . . . . . . . . . . .
System crashes during failover . . . . . . . . . . . .
Dictionary and data portions of a file . . . . . . . . . .
Multiple locks . . . . . . . . . . . . . . . . . .
Other limitations . . . . . . . . . . . . . . . . .
Chapter
6
The chapter describes restrictions when using UniVerse Replication.
File types
A UniVerse replication object can be any UniVerse database file, including a static hashed file, a dynamic hashed file, a multilevel file, a type 1 file, or a type 19 file. U2 Data Replication does not support a sequential file and other operating system-level files. You cannot publish a type 25 or EDA file, but you can subscribe them.
Changing inode or device numbers
U2 Data Replication uses the inode and device number to identify a replication object. The inode and device numbers of the replication objects are loaded when UniVerse starts, and when you execute the RECONFIG command. If you need to change the inode or device number for a file while
UniVerse is running, you must execute the RECONFIG command to update the replication object.
Note:
The UniVerse RESIZE TCL command may change the inode or device number, but this command reloads the inode and device number when it finishes executing. Therefore, you do not have to execute the RECONFIG command after resizing a file.
One replication object can only belong to one group
Replication objects are sets of objects in replication groups. One replication object can belong to only one replication group. If there are multiple VOC pointers referencing a single UniVerse file, they should be defined only once in one replication group.
If you define one replication object more than once in different groups, only one of them will be used.
6-2 U2 Data Replication for UniVerse
System files not supported as replication objects
U2 Data Replication does not support account-level operations on the following files:
&XML&
&EDAMAP&
&EDAXMAP
MENU.FILE
No cascading replication
You cannot use a subscribing object as a publishing object of another replication.
Writeable subscriber files
You can update a file on the subscribing system if you explicitly define it as writeable in the repconfig file. Updates made to a writeable file on the subscribing system are not replicated back to the publishing system.
You can update both record-level and file-level operations on a writeable subscriber file. If a file-level operation updates the VOC or dictionary file, you must specify these files as writable in the repconfig file.
Other command replication
UniVerse replicates the BASIC command, the CATALOG command, the
DECATALOG command, and the DELETE.CATALOG command through the account-level group. If you do not define an account-level group,
UniVerse does not replicate these commands, even if the target file is defined as a replicated file. If you define an account-level group. UniVerse replicates these commands, even if the target file is not defined as a replicated file.
6-3
Virtual field definitions
U2 Data Replication supports replication of indexed virtual field values. If you do not want to reevaluate virtual field values on the subscribing system, the subscribing object must have the same virtual field definition as on the publishing object.
Sequence of updates
UniVerse ensures the sequence of updates for the same record on a publishing object as on the subscribing object. However, on a subscribing system, the sequence of updates for different records may not be the same as on the publishing system.
U2 Data Replication only keeps the operation sequence within the same replication group. If you replicate an account-level and a file-level operation that updates a file in different replication groups, we do not guarantee that updates will be processed in the same sequence. To keep subscribing and publishing files consistent, you should define all related files in the same replication group.
Transaction limitations
One transaction can update data in files that belong to more than one replication group. However, those replication groups involved in one transaction should have the same subscribing distributions so the transaction is fully replicated to all of the distributions. The replication groups involved should also have the same replication type, either all real-time, all immediate, or all deferred.
6-4 U2 Data Replication for UniVerse
System administrators can define or reconfigure U2 Data Replication while UniVerse is running. The new configuration is only applies to transactions after the RECONFIG command is executed. UniVerse writes logs to the Replication Log Reserve File for those transactions that have been committed on the publisher, but not replicated on the subscriber. UniVerse generates this replication logs using the previous configuration. The data synchronization process transfers these logs to the subscriber using the new configuration information.
This may cause a different processing result.
For example, if the new configuration definition removes a replication object from a replication group, the saved logs for the removed object, if any, are still sent to the subscriber as part of data synchronization. If you configure the subscriber to remove the replication object as well, the Replication Writer process will either ignore the log if you set the RW_IGNORE_ERROR, or suspend the replication.
Make sure all data involved in a transaction is transferred before making changes to a replication group definition.
Although transaction consistency will eventually occur on the subscribing system, an application running on the subscribing system may read partial changes of a transaction on the publisher.
System crashes during failover
The data on the subscribing system may not be synchronized with the publishing system. You may have to recopy the data from the publishing objects to ensure synchronization.
Dictionary and data portions of a file
If you replicate both the data and dictionary portions of a file, they must belong to the same replication group.
6-5
Multiple locks
U2 Data Replication may apply multiple locks on the subscribing system. If your application is running on the subscribing system and you need to apply the same lock, you should follow the same locking sequence to avoid a deadlock.
Other limitations
Maximum replication systems defined on a system: 32,767
Maximum replication groups defined on a system: 32,767
Maximum distributions defined in a group: 32,767
Maximum replication objects defined on a system: 2,147,483,647
Maximum replication accounts defined on a system: 32,767
Maximum replication group name length: 127
Maximum replication system name length: 127
6-6 U2 Data Replication for UniVerse
Chapter 7: Disabling U2 Data
Replication
Disabling U2 Data Replication . . . . . . . . . . . . .
Replication DISABLE mode . . . . . . . . . . . . . .
Replication ENABLE mode . . . . . . . . . . . . . .
Runtime error handling . . . . . . . . . . . . . . . .
Enabling or disabling U2 Data Replication . . . . . . . . .
Exception action script . . . . . . . . . . . . . . . .
Error messaging . . . . . . . . . . . . . . . . . .
Chapter
7
Disabling U2 Data Replication
In U2 Data Replication suspension mode, the publisher continues generating replication logs and reserves them for the next synchronization process. This feature can quickly synchronize the standby database without a lot of user intervention. However, if replication is suspended too long, either because of the subscriber system failure and recovery, or for subscriber system maintenance, the publishing system may accumulate too many replication logs that consume a lot of disk space and slow down the system. In an extreme case, the system may run out of the disk space and crash the publishing system.
U2 Data Replication provides subscriber database refreshing as an alternative method to synchronizing the subscriber database instead of replication synchronization. Subscriber database refreshing is a backup from the publishing system and restoring it to the subscribing system, with some limited unavailable time on the publishing system. You may choose this method if the subscribing system cannot be fully recovered on its own, or in the case of a longer suspension period. In either of these situations, subscriber database refreshing will abandon the replication logs on the publishing system.
An issue emerged that if an upcoming Subscriber Database Refreshing is scheduled, there was no need for the publishing system to keep running replication and reserving replication logs that would eventually be abandoned. U2 Replication Disablement is an enhancement to the U2 Data
Replication that allows a database administrator to temporarily disable the replication system and stop generating unnecessary replication logs for better performance, and to avoid running out of disk space which could trigger system crash.
7-1 U2 Data Replication
Replication DISABLE mode
In replication DISABLE mode, all replication functions stop, but the repmanager continues to run. The following actions occur when U2 Data
Replication is disabled:
All replications are suspended.
All publishing processes stop.
The uv process stops generating replication logs.
The repmanager daemon only accepts the ENABLE, RECONFIG, and STOP commands.
The SYNC, SUSPEND, and RESET commands do not proceed until
Replication is enabled.
The DISABLE mode persists after stopping and restarting UniVerse.
Reconfiguring U2 Data Replication does not affect the DISABLE mode.
If one of the following events occurs, U2 Data Replication automatically switches to the DISABLE mode:
The database administrator issues a DISABLE command.
A fatal replication system error occurs. The error handling procedure sends a request to disable replication.
UniVerse is started with uv -admin -start -disable.
When the Replication Manager receives a DISABLE request, it performs the following tasks:
Suspends all active replications.
Sets the Replication Disable flag and saves it in the uvrepsys.log.
Issues the DBsetup -L command.
Exits the publishing processes.
If the ClearLog option was specified, clears the replication log files for all replication groups.
Issues the DBsetup -U command.
If the disable request was issued in error handling, executes the
Exception Action script, if defined, on the local system.
Replication DISABLE mode 7-2
When the Replication Manager starts with the disable option, it loads the replication configuration, sets the Replication Disable flag and saves it in the uvrepsys.log, and continues running in DISABLE mode.
7-3 U2 Data Replication
Replication ENABLE mode
The Replication ENABLE mode is the normal running mode for U2 Data
Replication. If U2 Data Replication is disabled, it is enabled if the system administrator issues the ENABLE command, or UniVerse is started with the
-init option.
When the Replication Manager receives an ENABLE request, it performs the following tasks:
Issues the DBsetup -L command.
Clears the Replication System disable flag and saves it in the udrepsys.log file.
Resets the Log Sequence Number (LSN) for all groups.
Clears the replication log files.
Starts the publishing processes for all publishing groups.
Issues the DBsetup -U command.
Issues the SYNC command to all replications if AUTORESUME is enabled.
Replication ENABLE mode 7-4
Runtime error handling
With Replication disablement, the runtime error handling of U2 Data
Replication changes. If a U2 Data Replication incurs a fatal error, U2 Data
Replication now disables U2 Data Replication and continues running
UniVerse in DISABLE mode rather than crashing the publishing system.
The following system errors will result in the publishing system being disabled:
When a uv process encounters a Log Extension File (LEF) error when handling replication logs.
When the publishing system cannot access the Log Reserve File
(LRF)
When the publishing process is terminated.
7-5 U2 Data Replication
Enabling or disabling U2 Data Replication
You can enable or disable U2 Data Replication using the uv -admin -start command, the ud_repadmin command, or through the U2 Extensible
Administration Tool (XAdmin).
Enabling or disabling U2 Data Replication through XAdmin
To enable or disable U2 Data Replication through XAdmin, from the Admin
Tasks
view, click Replication, then click the Replication Tool tab. A dialog box similar to the following example appears:
To enable U2 Data Replication, click the Target for which you want to enable replication, then click Enable.
To disable U2 Data Replication, click the Target for which you want to disable replication, then click Disable.
You must be logged in as root to enable or disable U2 Data Replication.
Enabling or disabling U2 Data Replication 7-6
Enabling or disabling U2 Data Replication using ud_repadmin
Use the ud_repadmin command to enable or disable U2 Data Replication from the operating system level.
To disable U2 Data Replication, use the disable option: ud_repadmin disable [-clearlog] [-verbose]
The -clearlog option clears the replication log files. The -verbose option displays messages to the screen.
To enable U2 Data Replication, use the enable option: ud_repadmin enable [-verbose]
The -verbose option displays messages to the screen.
You must be logged in as root to enable or disable U2 Data Replication.
7-7 U2 Data Replication
Exception action script
You can write and deploy and Exception Action script that U2 Data
Replication executes when replication is suspended or disabled unexpectedly. You can register the script using the EXCEPTION_ACTION phrase in the local system repsys file. If U2 Data Replication is suspended or disabled unexpectedly, U2 Data Replication executes the script and sets up environment variables to indicate the error.
The following table describes the environment variables returned by the U2
Data Replication Manager:
Environment Variable Description
UNIREP_GRPNAME The replication group that triggered replication disablement.
UNIREP_REMOTESYS The local system name defined in the repsys file.
UNIREP_REPTYPE
UNIREP_ERRCODE
Empty.
The replication system error code that triggered replication disablement.
UNIREP_ERRSTRING The error message pertaining to the error code.
The following environment variables were added at UniData 7.3:
UNIREP_REPSTATUS The replication status. Valid values are REP_SUSPENDED or REP_DISABLED.
UNIREP_PID
UNIREP_OSERRNO
The process ID that triggered replication disablement. This value is empty if the status is REP_SUSPENDED.
The operating-system error code that triggered the disablement. This value is empty if the status is
REP_SUSPENDED.
Environment Variables
Exception action script 7-8
Error messaging
When U2 Data Replication is disabled, detailed error messages are written to the rm.log. The following example illustrates messages written to the log when a publishing process is terminated:
Wed Oct 5 10:53:17 RM: sigchld received: pid=393236, dsig=9
Replication daemon on group 0(393236) is killed(9)!
Wed Oct 5 10:54:06 RM: Force stop group acct_grp(0)
Wed Oct 5 10:54:06 RM: kill publistener 454762
RM trying to kill 454762 by sig 9
RM: kill 454762
Wed Oct 5 10:54:06 RM: kill Publisher 393236
RM trying to kill 393236 by sig 9
RM: kill 393236
Wed Oct 5 10:52:48 2011: Fatal error from process 393236:
Group=0, Rep Error=2560:Publisher killed; OS Error=0:Error 0
Replication start disabling replication!
RM: Force RFS group commit.
Replication is Disabled!
RM: Pause database activity.
CheckPoint time before ForceCP: Wed Oct 5 10:55:53 2011
.CheckPoint time after ForceCP: Wed Oct 5 10:58:55 2011
.CP has been forced successfully.
DBpause successful.
RM: Force RFS group commit.
Stopped Publishing Group acct_grp successfully.
RM: Disable Replication.
RM: Resume database activity.
DBresume successful.
Execute Replication Exception Action program
/disk1/repacct/repeventtrig.sh
Publisher killed, RM disabled replication successfully.
7-9 U2 Data Replication
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
Real-time replication
Immediate replication
Deferred replication
Standby replication
Non-standby replication
Failover and recovery
Data recovery
Database refreshing
System definition file (repsys)
Replication configuration file (repconfig)
Frequently asked questions
U2 Data Replication works by sending copies of data changes from a publishing system to a subscribing system. This can be done in real-time, immediately, or deferred, depending on the needs of the application.
There are three types of replication: Real-time, Immediate, and Deferred. Real-time replication ensures that all data changes are committed to the subscribing system before the publishing system commits the transaction. Immediate replication sends data changes to the subscribing system as soon as they are ready to commit, but does not wait for the subscribing system to confirm receipt before committing the transaction. Deferred replication saves data changes to a file on the publishing system and then sends them to the subscribing system at a later time.
U2 Data Replication provides a number of benefits, including:
- High availability: U2 Data Replication can help to ensure that your UniVerse database is always available, even in the event of a system failure.
- Disaster recovery: U2 Data Replication can be used to create a standby system that can be used to restore your database in the event of a disaster.
- Reporting: U2 Data Replication can be used to create a separate reporting database that does not impact the performance of your primary database.
- Data consistency: U2 Data Replication ensures that all data changes are applied to the subscribing system in the same order as they are applied to the publishing system.
U2 Data Replication is configured through the use of the "repsys" and "repconfig" files. These files are located in the UVHOME directory. The "repsys" file defines the replication systems involved in the replication process, while the "repconfig" file defines the replication groups and their configuration parameters.
You can administer U2 Data Replication through U2 Extensible Admin or the "uv_repadmin" tool. These tools allow you to define replication systems, add replication groups, view the status of replication, and perform other administrative tasks.
