Release Notes

Amigopod |Technical Note High Availability Deployment Guide |7
In this state, the primary node is assigned the cluster IP address and is responsible for
delivering network services to clients. Each node is also continuously performing failure
detection, database replication and configuration replication, as explained below.
Failure detection
Failure detection is accomplished using a keep-alive test. The primary and secondary
nodes verify that each is able to communicate with the other node by sending network
requests and answering with a response. This takes place at the Keep Alive Rate specified
in the cluster configuration, which by default is once every 2 seconds.
If several consecutive keep-alive tests have failed, the cluster determines that a failure has
occurred. A cluster fail-over may then take place, depending on which node has failed.
Refer to section 0 for information about a primary node failure, or section 0 for
information about a secondary node failure.
To avoid any network service interruptions, it is important that the nodes maintain an
uninterrupted network connection.
Database replication
Database replication occurs continuously in a normally operating cluster. All database
modifications, including new guest accounts, changes to existing guest accounts, RADIUS
roles, NAS servers, and RADIUS accounting information, are replicated from the primary
node to the secondary node. The replication delay will depend on the volume of database
updates and system load but is generally only a few seconds.
Replicating the database contents ensures that in the event of a primary node failure, the
secondary node is up to date and can continue to deliver the same network services to
clients.
NOTE While the primary node is online, the secondary node’s database can only be updated with
replication changes from the primary node. No other database changes can take place on
the secondary node. Because of this, any form that requires a database update will be
disabled and shown as “Read Only Access” on the secondary node.
Ensure that you always access the cluster using the virtual IP address when performing
any database updates, such as creating new guest accounts or performing RADIUS
authentication. This is required so that the changes will be performed on the primary node
and then replicated to the secondary node.
Configuration replication
Configuration replication also occurs continuously within the cluster, but takes place at
a slower rate due to the reduced frequency of configuration updates. This rate is the
Config Sync rate specified in the cluster configuration, which by default is once every
minute.