Primary-Target Example

This is a simple example of primary-target replication.

In primary-target replication, only changes to the primary table are replicated to the other tables in the replicate. Changes to the secondary tables are not replicated.

In this example, define the g_usa and g_italy database server groups as Enterprise Replication servers and create a replicate, repl1.

To define the database server groups and create the replicate

Create and populate the database that defines the usa database server as a replication server:
```
cdr define server --init g_usa
```
Before replicating data, you must define the database servers as replication servers. A replication server is a database server that has an extra database that holds replication information.
The --init option specifies that this server is a new replication server. When you define a replication server, you must use the name of the database server group (g_usa) rather than the database server name.

Display the replication server that you defined to verify that the definition succeeded:

cdr list server

The command returns the following information:

SERVER    ID STATE    STATUS    QUEUE   CONNECTION CHANGED
----------------------------------------------------------
g_usa      1 Active   Local     0

Define the second database server, italy, as a replication server:
```
cdr define server --connect=italy --init \
--sync=g_usa g_italy
```
The --connect option allows you to define italy (on the s2 computer) while working at the s1 (usa) computer. The --sync option instructs the command to use the already-defined replication server (g_usa) as a pattern for the new definition. The --sync option also links the two replication servers into a replication environment.
Tip: In all options except the --connect option, Enterprise Replication uses the name of the database server group to which a database server belongs, instead of the name of the database server itself.

Verify that the second definition succeeded:

cdr list server

The command returns the following information:

SERVER    ID STATE    STATUS    QUEUE   CONNECTION CHANGED
----------------------------------------------------------
g_italy    8 Active   Connected 0       JUN 14 14:38:44 2000
g_usa      1 Active   Local     0

Define the replicate repl1:
```
cdr define replicate --conflict=ignore repl1 \ 
"P stores@g_usa:informix.manufact" \
"select * from manufact" \
"R stores@g_italy:informix.manufact" \
"select * from manufact"
```
These lines are all one command. The backslashes (\) at the end of the lines indicate that the command continues on the next line.

This step specifies that conflicts should be ignored and describes two participants, usa and italy, in the replicate:
- The P indicates that in this replicate usa is a primary server. That is, if any data in the selected columns changes, that changed data should be sent to the secondary servers.
- The R indicates that in this replicate italy is a secondary server (receive-only). The specified table and columns receive information that is sent from the primary server. Changes to those columns on italy are not replicated.

Display the replicate that you defined, so that you can verify that the definition succeeded:

cdr list replicate

The command returns the following information:

CURRENTLY DEFINED REPLICATES
------------------------------------------------
REPLICATE:     repl1
STATE:         Inactive
CONFLICT:      Ignore
FREQUENCY:     immediate
QUEUE SIZE:    0
PARTICIPANT:   g_usa:informix.manufact
               g_italy:informix.manufact

Step 5 defines a replicate but does not make the replicate active. The output of step 6 shows that the STATE of the replicate is INACTIVE.

Make the replicate active:
```
 cdr start repl1
```

Display the replicate so that you can verify that the STATE has changed to ACTIVE:

cdr list replicate

The command returns the following information:

CURRENTLY DEFINED REPLICATES
------------------------------------------------
REPLICATE:     repl1
STATE:         Active
CONFLICT:      Ignore
FREQUENCY:     immediate
QUEUE SIZE:    0
PARTICIPANT:   g_usa:informix.manufact
               g_italy:informix.manufact

If any changes are made to the manufact table, the changes will be replicated to the other participants in the replicate.

Now you can modify the manufact table on the usa database server and see the change reflected in the manufact table on the italy database server.

To cause a replication

Use DB-Access to insert a value into the manufact table on usa:

INSERT INTO stores@usa:manufact \
VALUES ('AWN','Allwyn','8');

Observe the changes on usa and on italy:

SELECT * from stores@usa:manufact
SELECT * from stores@italy:manufact

In repl1, usa is the primary database server and italy is the target. Changes made to the manufact table on italy do not replicate to usa.

To not cause a replication

Use DB-Access to insert a value into the manufact table on italy:

INSERT INTO stores@italy:manufact \
VALUES ('ZZZ','Zip','9');

Verify that the change occurred on italy but did not replicate to the manufact table on usa:
```
SELECT * from stores@usa:manufact
SELECT * from stores@italy:manufact
```