Cisco Cisco Access Registrar 3.5 - Manual (Page 43)

4-5
Cisco Access Registrar 3.5 Concepts and Reference Guide
OL-2683-02
Chapter 4 Understanding Replication
Replication Configuration Settings
Full Resynchronization
Full Resynchronization means that the slave has missed more transactions than are stored in the master's
replication archive and cannot be resynchronized automatically. There is no automatic
full-resynchronization mechanism in Access Registrar's configuration replication feature. To perform a
full resynchronization, refer to the Cisco Access Registrar User’s Guide.
Understanding Hot-Configuration
Hot-Configuration is the process of reflecting configuration changes made to Access Registrar's internal
configuration database in the in-memory configuration of the executing Access Registrar server.
Hot-Configuration is accomplished without interruption of RADIUS request processing. For example,
if an administrator uses aregcmd to configure a new client and issues a save command, when the prompt
returns, the newly configured client may send requests to Access Registrar.
Hot-Configuration minimizes the down-time associated with having to restart an Access Registrar server
to put configuration changes into effect. With the Hot-Configuration feature, a restart is only necessary
when a Session Manager, Resource Manager or Remote Server configuration is modified. These
configuration elements may not be hot-configured because they maintain state (an active session, for
example) and cannot be modified without losing the state information they maintain. Changes to these
configuration elements require a restart of Access Registrar to put them into effect.
Hot-Configuration is not associated with the replication feature. Hot-Configuration’s only connection to
the replication feature is that when a change is replicated to the slave, the slave is hot-configured to
reflect the replicated change as if an administrator had used aregcmd to make the changes directly on
the slave server.
Replication’s Impact on Request Processing
The replication feature was designed to perform replication of transactions with minimal impact on
RADIUS request processing. When a transaction is received by a slave, RADIUS requests are queued
while the transaction is applied to the slave. Once the transaction is complete, RADIUS request
processing resumes.
The impact on RADIUS request processing is a direct result of the size of a transaction. The smaller the
transaction the lesser the impact, and the larger the transaction, the greater the impact. In other words,
when making changes to the master, frequent saves are better than making lots of changes and then
saving. Each change is one transaction element and all changes involved in a save comprise a single
transaction with one element per change. Since the replication feature only impacts RADIUS request
processing when changes are made, the impact under normal operation (when changes are not being
made) is virtually unmeasurable.
Replication Configuration Settings
This section describes each replication configuration setting. In aregcmd, replication settings are found
in //localhost/Radius/Replication.