cdr check sec2er

The cdr check sec2er command determines whether a high availability cluster can be converted to replication servers.

Syntax

Notes:

¹ See Connect Option.


Element	Purpose	Restrictions	Syntax
`secondary`	Name of the secondary server in the cluster.		Long Identifiers

The following table describes the cdr check sec2er option.


Long Form	Short Form	Meaning
--print	-p	Shows the commands that would be run by the cdr start sec2er command during a conversion.

Usage

You must run the cdr check sec2er command from a primary server in a cluster with a high-availability data replication secondary or a remote stand-alone secondary server. The output of the cdr check sec2er command can show warning messages and error messages:

Warning messages indicate possible problems for replication after the conversion. You can solve these problems after converting the cluster to replication servers.
Error messages indicate problems preventing the conversion to replication server. You must solve all error conditions before you run the cdr start sec2er command to convert a cluster to replication servers.

Use the --print option to display the commands that are run during a conversion.

Depending on the state of the data in your database when you run the cdr check command, the system might also run an UPDATE STATISTICS command.

Return codes

A return code of 0 indicates that the command was successful.

If the command is not successful, the following error code is returned: 225.

For information about these error codes, see Return Codes for the cdr Utility.

Examples

The following example checks if a cluster consisting of a primary server named priserv and a secondary server named secserv can be converted to replication servers:

cdr check sec2er -c priserv secserv

The following output of the cdr check sec2er command indicates that conversion would be successful, but that several issues should be addressed either before or after conversion:

WARNING:CDR_SERIAL value on priserv can cause collisions. 
WARNING:Dbspace is becoming full.
WARNING:Using the same values for CDR_SERIAL can cause collisions. 

Secondary conversion to ER is possible.
Errors:0000   Warnings:0003

The following output of the cdr check sec2er command indicates that conversion will not be successful until the CDR_QDATA_SBSPACE configuration parameter is set in the onconfig file on both the primary and the secondary servers:

WARNING:CDR_SERIAL value on priserv can cause collisions. 
WARNING:Dbspace is becoming full.
WARNING:Using the same values for CDR_SERIAL can cause collisions. 
ERROR:ER sbspace not correctly set up (CDR_QDATA_SBSPACE).

Secondary conversion to ER is not possible.
Errors:0001   Warnings:0003

The following output of the cdr check sec2er command indicates that conversion will not be successful until the sqlhosts files on both the primary and the secondary servers are correctly configured for Enterprise Replication:

WARNING:CDR_SERIAL value on serv1 can cause collisions. 
ERROR:Server priserv and server secserv belong to the same group. 
WARNING:Dbspace  is becoming full.
ERROR:Server priserv and server secserv belong to the same group. 
WARNING:Using the same values for CDR_SERIAL can cause collisions. 
FATAL:SQLHOSTS is not set up correctly for ER.
ERROR:SQLHOSTS is not set up correctly for ER.
ERROR:ER sbspace not correctly set up (CDR_QDATA_SBSPACE).

Secondary conversion to ER is not possible.
Errors:0004   Warnings:0003

The following example shows the output of the --print option, which describes the commands that will be run when the cdr start sec2er command is run on the priserv server. The servers are defined as replication servers. Any tables that do not have a primary key are altered to add ERKEY shadow columns. A replicate is created and started for each user table on the priserv server.

$cdr check sec2er --print serv2
Secondary conversion to ER is possible.

Errors:0000   Warnings:0000
--
--  Define ER for the first time
--
cdr define serv -c cdr1 -I cdr1

--
--  Creating Replication Key
--
dbaccess - - <<EOF
database stores_demo;
alter table 'mpruet'.classes add ERKEY;
EOF

--
--  Define the replicates
--
--
--  Defining Replicates for Database stores_demo
--
cdr define repl --connect=cdr1 sec2er_1_1282611664_call_type --master=cdr1 \
   --conflict=always --scope=row \
   "stores_demo@cdr1:'mpruet'.call_type" \
         "select * from 'mpruet'.call_type"
cdr start repl --connect=cdr1 sec2er_1_1282611664_call_type

cdr define repl --connect=cdr1 sec2er_4_1282611664_cust_calls --master=cdr1 \
   --conflict=always --scope=row \
   "stores_demo@cdr1:'mpruet'.cust_calls" \
         "select * from 'mpruet'.cust_calls"
cdr start repl --connect=cdr1 sec2er_4_1282611664_cust_calls

cdr define repl --connect=cdr1 sec2er_5_1282611664_customer --master=cdr1 \
   --conflict=always --scope=row \
   "stores_demo@cdr1:'mpruet'.customer" \
         "select * from 'mpruet'.customer"
cdr start repl --connect=cdr1 sec2er_5_1282611664_customer

cdr define repl --connect=cdr1 sec2er_3_1282611664_classes --master=cdr1 \
   --conflict=always --scope=row \
   "stores_demo@cdr1:'mpruet'.classes" \
         "select * from 'mpruet'.classes"
cdr start repl --connect=cdr1 sec2er_3_1282611664_classes
--
--  Starting RSS to ER conversion
--
--
--  WARNING:
--
--  DDL statements will not be automatically propagated to the ER server
--  after converting the secondary server into an ER server.  If you
--  create or alter any objects, such as databases, tables, indexes, and 
--  so on, you must manually propagate those changes to the ER node and
--  change any replication rules affecting those objects.
--