Cisco Cisco Access Registrar 3.5 - Manual (Page 40)

4-2
Cisco Access Registrar 3.5 Concepts and Reference Guide
OL-2683-02
Chapter 4 Understanding Replication
How Replication Works
When there is a configuration change, the master server propagates the change set to all member servers
over the network. All member servers have to update their configuration after receiving the change set
notifications from master server. Propagating the change set to a member serve involves multiple packet
transfer from the master server to the member because the master serve has to convey all the
configuration changes to the member. The number of packets to be transferred depends on the size of
the change set.
After receiving a change set notification, the member server will go off-line before applying the change
set received from master server. This state is indicated by the log message
Radius Server is Off-line
in name_radius_1_log file. When the change set is successfully applied, the member server goes up
automatically. This is indicated by the log message
Radius Server is On-Line in name_radius_1_log
file. When the member server goes off-line to apply the change set, no incoming packets are processed.
Due to the number of packets to be transferred in the change set and the amount of time the member
server will be offline updating its databasepoints, Cisco recommends that you use multiple save
commands rather than a large configuration change with one save command. You can also minimize the
number of changes that occur in a replication interval by modifying either the
RepTransactionArchiveLimit or the RepTransactionSyncInterval, or both of these properties. For
example, instead of using the default value of 100 for the RepTransactionArchiveLimit, you might
change it to 20.
How Replication Works
This section describes the flow of a simple replication as it occurs under normal conditions.
Replication Data Flow
The following sections describe data flow on the master server and the slave server.
Master Server
The following describes the data flow for the master server:
Step 1 The administrator makes a change to the master server’s configuration using the aregcmd command line
interface (CLI) and issues a save command.
Step 2 After the changes are successfully validated, the changes are stored in the Access Registrar database.
Step 3 aregcmd then notifies the Access Registrar server executing on the master of the configuration change.
Step 4 The Access Registrar server then updates its version of the configuration stored in memory. (This is
called hot-config because it happens while the server is running and processing requests.)
Step 5 The Access Registrar server first copies the changes pertaining to the aregcmd save, also known as a
transaction to its replication archive, then transmits the transaction to the slave server for processing.
Step 6 In aregcmd, the prompt returns indicating that the save has completed successfully, the transaction has
been archived, and the transaction has been transmitted to the slaves.