Cisco Cisco Access Registrar 3.5 - Manual (Page 42)

4-4
Cisco Access Registrar 3.5 Concepts and Reference Guide
OL-2683-02
Chapter 4 Understanding Replication
How Replication Works
Transaction Data Verification
When the master prepares a transaction for replication to a slave, the master calculates a 2's complement
Cyclic Redundancy Check (CRC) for each element (individual configuration change) in the transaction
and for the entire transaction and includes these CRC values in the transmitted transaction. When the
slave receives the transaction, the slave calculates a CRC for each transaction element and for the entire
transaction and compares its own calculated values with those sent with the message. If a discrepancy
occurs from these comparisons, the transaction element or the entire transaction is discarded and a
re-transmission of that particular transaction element or the entire transaction is requested by the slave
from the master. This process is called automatic resynchronization. (described in more detail below)
Transaction Order
When the master prepares a transaction for replication, it assigns the transaction a unique transaction
number. This number is used to ensure the transactions are processed by the slave in exactly the same
order as they were processed on the master. Transactions are order dependent. Since the functionality of
Access Registrar's configuration replication feature is to maintain identical configurations between
master and slave, if transaction order were not retained, master and slave would not contain identical
configurations. Consider where two transactions modify the same thing (a defined client's IP address for
example). If the first transaction was a mistake and the second was the desired result, the client config
on the master would contain the second setting; however, if the transactions were processed in the
reverse order on the slave, the client config on the slave would contain the mistaken IP Address. This
example illustrates the critical need for transaction ordering to ensure data integrity.
Automatic Resynchronization
Automatic Resynchronization is the most significant feature with respect to data integrity. This feature
ensures the configurations on both the master and slave are identical. If they are not, this feature
automatically corrects the problem.
When the master and slave start-up, they determine the transaction number of the last replication
transaction from their respective replication archives. The master immediately begins periodic
transmission of a TransactionSync message to the slave. This message informs the slave of the
transaction number of the transaction that the master last replicated.
If the transaction number in the TransactionSync message does not match the transaction number of the
last received transaction in the slave's archive, then the slave will request resynchronization from the
master. The resynchronization request sent by the slave will include the slave's last received transaction
number.
The master will respond by retransmitting each transaction since the last transaction number indicated
by the slave in the resynchronization request. The master obtains these transactions from its replication
archive.
Should the slave's last received transaction number be less than the lowest transaction number in the
master's replication archive, then automatic resynchronization cannot occur as the master's replication
archive does not contain enough history to synchronize the slave. In this case, the slave must be
resynchronized with a full-resynchronization.