Master replicates and how to use them

Previous versions of Enterprise Replication did not have the capability to discover a data type mismatch at the source and target nodes at the time of replicate creation, and instead discovered any mismatches when data was corrupted. For example, using classic (non-master) replicates, it is possible to define a replicate with having an int8 column on the source node and an integer column on other nodes. This mismatch would not be detected until it had already caused data corruption. In Version 10.0, you can guarantee consistency between the nodes in your Enterprise Replication environment by defining master replicates. Master replicates store dictionary information about replicated column attributes for the participant tables so that Enterprise Replication can check for consistency between the master definition and local participant definitions when the replicates are defined. Using master replicates avoids runtime data corruption occurring due to data type mismatch on source and target nodes. Verification of replicate attributes also occurs each time the master replicate is started.

To specify a master replicate, use the --master option with the cdr define replicate command. The --master option (-M) requires you to specify the master node where the master table dictionary is located. The master table dictionary is used to compare schemas on all replicate participants to ensure consistency. You also have the option to create tables on target nodes using master replicates if those tables are not already present.

For more information about master replicates, see the Informix Dynamic Server Information Center.

Suppose you create a logged database and table:

>dbaccess - -
create database test with log;
create table tab1 (c1 integer primary key, c2 integer) with crcols;

Then you can define the master replicate using -M option to specify the master node as g_pkcdr.1:

>cdr define repl rep1 -M g_pkcdr1 -C "ignore" "test@g_pkcdr1:pravin.tab1" 
"select * from tab1" "test@g_pkcdr2:pravin.tab1" "select * from tab1"
Verification of test@g_pkcdr1:pravin.tab1 started 
Verification of test@g_pkcdr1:pravin.tab1 is successful
Verification of test@g_pkcdr2:pravin.tab1 started 
Verification of test@g_pkcdr2:pravin.tab1 is successful

cdr start repl rep1

These commands create a master replicate that first verifies the schema at two nodes. The cdr list repl command indicates that the replicate is a master replicate in the REPLTYPE field:

cdr list repl rep1

CURRENTLY DEFINED REPLICATES
---------------------------------------------------
REPLICATE:        rep1
STATE:            Active ON:pkcdr1
CONFLICT:         Ignore
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      test pravin.tab1
OPTIONS:          transaction,fullrow
REPLTYPE:         Master

Back to top

Enterprise Replication features dependent on master replicates

The following new features for Version 10.0 require using master replicates:

• Performing alter operations on replicated tables

  To support online schema changes (SQL alter operations) to a table that is undergoing replication, use master replicates. If necessary, change a classic replicate to a master replicate using the re-mastering process, described below. For more information about alter support in Version 10.0, see Performing Alter Operations on Replicated Tables in the Informix Dynamic Server Information Center.

• Templates

  Templates provide a means of simplified large scale Enterprise Replication administration. Templates use master replicates internally. Master replicates provide the template the capability to do complete database replication including automatic creation of tables on target nodes. For more information, see Using Templates to Set up Replication in the Informix Dynamic Server Information Center.

• Resynchronizing data using shadow replicates

  Repairing out-of-sync replicates can be performed even with classic replicates. This feature internally defines four different shadow replicates that are used to perform the repair process. These shadow replicates, however, are master replicates. For more information about resynchronization, see Resynchronizing Data Among Replication Servers in the Informix Dynamic Server Information Center.

Back to top

Benefits of using master replicates

The primary benefits of using master replicates are that they:

• Ensure data integrity by verifying that all participants in the replicate have table and replicated column attributes that match the master replicate definition.
• Provide automatic table generation on participants that do not already contain the table specified in the master replicate. However, Enterprise Replication cannot create tables with user-defined data types unless the UDTs already exist on all source and target nodes.
• Allow alter operations on the replicated tables
• Provide the basis for templates
• Provide the basis for future development of Enterprise Replication functionality that requires schema consistency

Back to top

Caveats to using master replicates

Master replicates have the following restrictions that are not applicable to classic replicates:

• Direct connections are required between all the nodes where master replicates are being defined. Enterprise Replication must connect to each of the servers directly to process the master schema verification and optional table creation. Therefore, in the sqlhosts file, entries for all the nodes need to be present.
• Master replicates require all server participants to be running, because during definition the master and local dictionaries for the replicate tables are checked for consistency.
• You cannot configure a leaf node as the master node because it does not have direct access to all the nodes other than its non-root server.

Back to top

Shadow replicates

A shadow replicate is a copy of an existing, or primary, replicate. Enterprise Replication uses shadow replicates to manage alter and repair operations on replicated tables. Shadow replicates are present in the system for fairly short intervals and are deleted when no longer needed. You must create a shadow replicate to perform a transform a classic replicate to a master replicate. For information on how you can remaster a replicate, see Remastering a Replicate in the Informix Dynamic Server Information Center. After creating the shadow replicate, the next step in manual re-mastering is to switch the primary replicate and the shadow replicate using the cdr swap shadow command.

Create a shadow replicate using the cdr define replicate command with the --mirrors option, as described in cdr define replicate. When you define a shadow replicate, its state is always set to the same state as the primary replicate. If you change the state of the primary replicate, all its shadow replicates' states are also changed to the same state.

For more detailed information, see Defining Shadow Replicates in the Informix Dynamic Server Information Center.

Back to top

Transforming classic replicates to master replicates

You can use the new cdr remaster command to transform an existing classic replicate to a master replicate. This is a recommended procedure, so that you can benefit from new Version 10.0 features.

For example, suppose you create a logged database and table:

>dbaccess - -
create database test with log;
create table tab1 (c1 integer primary key, c2 integer) with crcols;

Then you define the classic replicate:

>cdr define repl rep1 -C "ignore" "test@g_pkcdr1:pravin.tab1" "select * from tab1" 
"test@g_pkcdr2:pravin.tab1" "select * from tab1"
>cdr start rep rep1

Now you can change this classic replicate to a master replicate using the following command (you could have specified the list of columns in the SELECT statement to be replicated):

>cdr remaster -M g_pkcdr1 rep1 "select * from tab1"

The re-mastering internally creates a shadow replicate, Shadow_4_rep1_GMT1113917066_GID100_PID26153, that keeps track of the older classic replicate definition and then renames the new master replicate to the original replicate name. While the shadow replicate exists, you can see it with the cdr list repl command:

>cdr list repl

CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE:        Shadow_4_rep1_GMT1113917066_GID100_PID26153
STATE:            Active ON:pkcdr2
CONFLICT:         Ignore
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      test:pravin.tab1
OPTIONS:          transaction,fullrow
REPLTYPE:         Shadow
PARENT REPLICATE: rep1

REPLICATE:        rep1
STATE:            Active ON:pkcdr2
CONFLICT:         Ignore
FREQUENCY:        immediate
QUEUE SIZE:       0
PARTICIPANT:      test:pravin.tab1
OPTIONS:          transaction,fullrow
REPLTYPE:         Master

After the log records pertaining to older schema no longer exist in the system, the shadow replicate is automatically deleted and system only has new master replicates.

Resources

• Participate in the discussion forum.
  
  
• Want to try this product? Download a free trial version of Informix Dynamic Server, V10.0
  
  
• The Informix Dynamic Server Information Center for IBM Informix Dynamic Server, Version 10.0, contains product documentation in HTML and PDF format.
  
  
• Read "Improved information retrieval in IBM Informix Dynamic Server, Version 10.0 documentation", developerWorks DB2, March 2005
  
  
• Read IBM Informix Dynamic Server Enterprise Replication templates, How to use templates to deploy replication", developerWorks DB2, May 2005
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Master replicates and how to use them
• Enterprise Replication features dependent on master replicates
• Benefits of using master replicates
• Caveats to using master replicates
• Shadow replicates
• Transforming classic replicates to master replicates
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Informix Dynamic Server Enterprise Edition
• Demo: Use DB2 First Steps and the DB2 Control Center
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: Information on Demand
• Buy: Informix Dynamic Server Enterprise Edition

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers