Example: Synchronization and the epoch number matrix

The example in this topic illustrates how the epoch number matrix changes at various sites as replica creation and synchronization occur.

Before replication is enabled for the first time at boston_hub, its epoch number matrix is empty:

multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "original" (@ minuteman):
     original=0

After the administrator uses mkreplica –export to create a new replica (sanfran_hub), boston_hub’s epoch number matrix contains a row for sanfran_hub (also note that the administrator renamed the replica original to boston_hub):
```
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
        sanfran_hub=0
     original=1
Oplog IDs for row "sanfran_hub" (@ goldengate):
     original=0
         sanfran_hub=0
```

After the administrator at the sanfran_hub replica imports the replica-creation packet, the epoch number matrix for sanfran_hub looks like this:

multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
     original=1
        sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
     original=1
         sanfran_hub=1

As development work occurs at the two replicas, each replica’s record of its own state is updated accordingly. However, because no synchronization has taken place, each replica’s estimate of the other replica’s state does not change.

At boston_hub:

multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
        sanfran_hub=0
     original=9
Oplog IDs for row "sanfran_hub" (@ goldengate):
     original=0
         sanfran_hub=0

At sanfran_hub:

multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
     original=1
        sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
     original=1
         sanfran_hub=4

The administrator at boston_hub enters a syncreplica –export command to generate an update packet for sanfran_hub.
The sanfran_hub row is updated to show that all operations that have taken place at boston_hub will be applied at the sanfran_hub replica:
```
multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
        sanfran_hub=0
     boston_hub=10
Oplog IDs for row "sanfran_hub" (@ goldengate):
     boston_hub=10
         sanfran_hub=0
```

At sanfran_hub, the administrator applies the update packet. The epoch number matrix for sanfran_hub now reflects the changes made at the boston_hub replica:

multitool lsepoch 
For VOB replica "/vobs/dev":
Oplog IDs for row "boston_hub" (@ minuteman):
     boston_hub=10
        sanfran_hub=0
Oplog IDs for row "sanfran_hub" (@ goldengate):
     boston_hub=10
        sanfran_hub=4

Example: Synchronization and the epoch number matrix

The following example illustrates how the epoch number matrix changes at various replicas as replica creation and synchronization occur.

After activation, but before replication is enabled for the first time at boston_hub, its epoch number matrix is empty:
multiutil lsepoch -clan telecomm -site boston_hub -family PRODA -user lexadmin -password secret

Multiutil: Estimates of the epochs from each site replayed at each site ‘boston_hub’ (@host1):

boston_hub: 0
After the administrator at the sanfran_hub replica imports the replica-creation packet, the epoch number matrix for sanfran_hub looks like this:
multiutil lsepoch -clan telecomm -site sanfran_hub -family PRODA -user sfadmin -password secret

Multiutil: Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’ (@host2):

boston_hub: 2

SANFRAN_HUB:0

Note: sanfran_hub’s estimate of itself is 0. In this example, sanfran_hub also estimates that two database operations occurred at boston_hub. These operations could range from creation of a new record to the creation of a replica.
As development work occurs at the two replicas, each replica’s record of its own state is updated accordingly. However, because no synchronization has taken place, each replica’s estimate of the other replica’s state does not change.
At boston_hub:

multiutil lsepoch -clan telecomm -site boston_hub -user lexadmin -password secret boston_hub

Multiutil: Estimates of the epochs from each site replayed at each site ‘boston_hub’ (@host1):

boston_hub: 12

SANFRAN_HUB:0

At sanfran_hub:

multiutil lsepoch -clan telecomm -site sanfran_hub -user sfadmin -password secret

Multiutil: Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’ (@host2):

boston_hub: 2

SANFRAN_HUB:7
The administrator at boston_hub enters a syncreplica -export command to generate an update packet for sanfran_hub.
At boston_hub, the sanfran_hub row is updated to show that all operations that have taken place at boston_hub have been sent to the sanfran_hub replica:
multiutil lsepoch -clan telecomm -site boston_hub -user lexadmin -password secret sanfran_hub

Multiutil: Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’ (@host1):

boston_hub: 12

SANFRAN_HUB:0
At sanfran_hub, the administrator imports the update packet. The epoch number matrix for sanfran_hub now reflects the changes made at the boston_hub replica:
multiutil lsepoch -clan telecomm -site sanfran_hub -user sfadmin -password secret sanfran_hub

Multiutil: Estimates of the epochs from each site replayed at each site ‘SANFRAN_HUB’ (@host1):

boston_hub: 12

SANFRAN_HUB:7