cdr remaster replicateset

The cdr remaster replicateset command updates the definitions of the set of replicates whose participants were changed by ALTER operations.

Syntax


1  cdr remaster replicateset?  %Connect Option  (1)  --master=server  derived_set?   --wait =
2.1 seconds
2.1 -1
Notes:
Element Purpose Restrictions Syntax
derived_set Name of the derived replicate set to be mastered. The derived replicate set must exist. Long Identifiers
seconds Number of seconds to wait for remastering to complete. The number must be -1 or a positive integer.
server Name of the database server group from which to base the replicate definitions. The name must be the database server group name. Long Identifiers

The following table describes the options to the cdr remaster replicateset command.

Long Form Short Form Meaning
--master= -M Specifies the server from which to base the definitions of the replicates.
--wait= -w Specifies how long to wait for remastering to complete. Default is -1: wait indefinitely until all replicates are finished being remastered.

If you specify a waiting time, but the remaster operation is not complete at the end of the waiting time, the operation is rolled back and the replicate definitions are not updated.

Usage

All participant servers in the derived replicate set must be online and the cdr utility must be able to connect to each participant.

If you run this command as a DBSA instead of as user informix, you must have INSERT, UPDATE, and DELETE permission on the replicated tables on all the replication servers in the domain.

When you change replicate participants by running ALTER operations, you must remaster the replicate. Remastering updates the replicate definition in the global catalogs of the replication servers. Before you can run the cdr remaster replicateset command, you must run the cdr define replicateset command with the --needRemaster option to create a derived replicate set.

You can run this command from within an SQL statement by using the SQL administration API.

The remastering operation creates temporary shadow replicates that are deleted when the remastering operation is complete. If shadow replicates exist, the remastering operation is in progress. You can run the cdr list replicate command to determine if the shadow replicate exists. An example of a shadow replicate name is: 
Shadow_4_Repl1_GMT1090373046_GID10_PID28836

Shadow replicate names have the following format: 

Shadow_4_basereplicatename_GMTtime_GIDgroupID_PIDpid
basereplicatename
The name of the replicate that is being remastered. If the replicate name is longer than 64 characters, only the first 64 characters are included.
time
The time stamp of when the shadow replicate was created, in GMT.
groupID
The group ID of the server. The group ID is the number that is specified by the -i option in the group definition in the sqlhosts file.
pid
The process ID of the client computer.

Example

The following command remasters a derived replicate set named derived_accounts and sets the replication server named server1 as the master server:

cdr remaster replicateset --master=server1 derived_accounts