cdr start sec2er

The cdr start sec2er command converts a high availability cluster to replication servers.

Syntax

Notes:

¹ See Connect Option.


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

Usage

You must run the cdr start sec2er command from a primary server in a cluster with a high-availability data replication secondary or a remote stand-alone secondary server. The cdr start sec2er command converts the two cluster servers into replication servers.

The following conditions must be met on both the primary and secondary cluster servers before running the cdr start sec2er command:

The sqlhosts files must be configured for Enterprise Replication:
- Each server must belong to a different group.
- The group identifier for each server must be different.
- The sqlhosts files on each server must contain a server and a group entry for the other server.
All databases and tables must be logged.
No tables can be defined with label-based access control.
Typed tables must have primary keys.
User-defined types must support Enterprise Replication.
The CDR_QDATA_SBSPACE configuration parameter must be set.
Both server must be running HCL OneDB™ version 11.10 or later.
If the servers are running HCL OneDB database software prior to 11.70, Enterprise Replication cannot be defined.
Enterprise Replication must be active if it is already defined on either of the servers.

The cdr start sec2er command performs the following tasks:

The servers are defined as replication servers.
Any tables on the primary server 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 primary server.

If the cdr start sec2er command fails or is interrupted, you might see the following error message:

ERROR:  Command cannot be run on pre-11.70 instance if ER is already running.

If you receive this error, remove replication by running the cdr delete server command for both servers and then run the cdr start sec2er command again.

Return codes

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

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

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

Example

The following example converts a cluster consisting of a primary server named priserv and a secondary server named secserv into replication servers. The output of the cdr start sec2er command shows the commands that are run.

$cdr start sec2er secserv
--
--  Define ER for the first time
--
cdr define serv -c priserv -I priserv

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

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

cdr define repl --connect=priserv sec2er_2_1282611664_cust_calls --master=priserv \
   --conflict=always --scope=row \
   "stores_demo@priserv:'bill'.cust_calls" \
         "select * from 'bill'.cust_calls"
cdr start repl --connect=priserv sec2er_2_1282611664_cust_calls

. . .

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

cdr define repl --connect=priserv sec2er_6_1282611664_classes --master=priserv \
   --conflict=always --scope=row \
   "stores_demo@priserv:'bill'.classes" \
         "select * from 'bill'.classes"
cdr start repl --connect=priserv sec2er_6_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.
--