cdr def ser -c delta -I -S g_alpha g_delta
At the end of this step, all servers in the replication environment include information in the syscdr database about delta, and delta has information about all other servers.
cdr cha rep -a zebra "dbname@g_delta:owner.table1"
This step updates the replication catalog. The servers alpha, beta, and gamma do not queue any qualifying replication data for delta because the replicate on delta, although defined, has not been started.
cdr sus ser g_alpha g_beta g_gamma
As a result of this step, replication data is queued for delta, but no data is delivered.
cdr sta rep zebra g_delta
This step causes servers alpha, beta, and gamma to start queueing data for delta. No data is delivered to delta because delta is suspended. Then, delta queues and delivers qualifying data (if any) to the other servers.
Do not run any transactions on delta that affect table table1 until you finish the synchronization process.
If you used the HPL to unload the data in step 5, then use the HPL Deluxe load without replication to load the data into table1 on delta.
This step starts the flow of data from alpha, beta, and gamma to delta.
At this point, you might see some transactions aborted because of conflict. Transactions can abort because alpha, beta, and gamma started queueing data from delta in step 4. However, those same transactions might have been moved in steps 5 and 7.
You must declare replication on server delta and then immediately suspend replication because, while you are preparing the replicates and unloading and loading files, the other servers in the replicate (alpha, beta, and gamma) might be collecting information that needs to be replicated. After you finish loading the initial data to delta and resume replication, the information that was generated during the loading process can be replicated.