The synchronization process provides the means to manage distributed database (the Multi-Chassis Synchronization (MCS) database), which contains the dynamic state information created on any of the nodes by any application using its services. The individual entries in the MCS database are always paired by peering-relation, sync-tag and application-id. At any time the specified entry is related to the single redundant-pair objects (two SAPs on two different nodes) and therefore stored in a local MCS database of the respective nodes.
Internally, peering-relation and sync-tag are translated into a port and encapsulation value identifying the object (SAP) that the specified entry is associated with. The application-id then identifies the application which created the entry on one of the nodes. There are three basic operations that the application can perform on MCS database. The MCS database always synchronizes these operations with its respective peer for the specified entry.
The following principles apply:
add-operation
Any dynamic-state created in the application is pushed to the MCS database. MCS then creates and synchronizes with the corresponding peer provided (if configured). The application in the peer node is then notified as soon as the entry has been created. Similarly, the application in the local node (the node where the state has been created) is notified that entry has been synchronized (MCS is ‟in-sync” state). This operation is also used to modify existing MCS database entry.
local-delete
The MCS database entry is marked as no longer in use locally and this information is sent to the peer node. If the information is no longer used by applications on both nodes (the application in remote-node has already issued local-delete before), it is removed from database.
global-delete
The MCS database entry is removed from both nodes and from the application in the remote node.
The choice of the operation in corresponding situation is driven by the application. The following general guidelines are observed:
An event which leads to a dynamic-state deletion on a standby chassis is handled as ‟local-delete”.
An event which leads to a dynamic-state deletion on an active chassis is handled as ‟global-delete”.
An exception to above the rules is an explicit clear command which is handled as global-delete regardless of where the command was executed.
As previously stated, the MCS process automatically synchronizes any database operation with the corresponding peer. During this time, the MCS process maintains state per peer indicating to the applications (and network operator) the current status, such as in-sync, synchronizing or sync_down. These states are indicated by corresponding traps.