What is an auxiliary database?
Description
An auxiliary database provides additional statistics data storage, and is required for advanced storage and retrieval functions such as data analytics. An auxiliary database is deployed on one station, or as a cluster of three or more stations, depending on the scale requirements.
Auxiliary database deployment also supports geographically redundant, or geo-redundant, deployment using functionally identical auxiliary database clusters in separate data centers. See Geo-redundant deployment for more information.
From the NFM-P client GUI, you can do the following.
You can also use CLI commands to display the local or geo-redundant cluster status; see the following for information:
-
How do I view the local auxiliary database cluster status in the client GUI?
-
How do I view the local auxiliary database cluster status from a CLI?
Note: During some internal operations, the status of one or more standby cluster members may be UNREACHABLE temporarily, and is no cause for concern.
Auxiliary database fault tolerance
The following provide auxiliary database fault tolerance:
-
geographically redundant clusters; see Geo-redundant deployment
-
data replication among the stations in a multi-station cluster, and between clusters in a geo-redundant deployment
Hardware redundancy
If enough members of an auxiliary database cluster fail, the cluster is considered to be failed, and an alarm is raised. When a cluster fails in a geo-redundant deployment that includes the NFM-P, the local primary main server initiates a switchover to the standby cluster, which is subsequently the active cluster.
For a cluster to be considered failed, the number of unavailable cluster members varies by the cluster size:
Geo-redundant deployment
Auxiliary database deployment supports geo-redundancy, in which an auxiliary database cluster is deployed in each data center of a DR NSP deployment.
The auxiliary database cluster that has the active role processes transactions and replicates the data to the standby cluster every 30 minutes.
The standby cluster automatically assumes the active role in the event that the active cluster is unreachable. This failover function is independent of NFM-P or NSP system redundancy functions, and is non-revertive.
Note: During some internal operations, the status of one or more standby cluster members may be UNREACHABLE temporarily, and is no cause for concern.
For more information about auxiliary database redundancy, see Auxiliary database geographic redundancy.
You can convert a standalone auxiliary database to geo-redundancy; see the NSP Installation and Upgrade Guide for information.
Backups and restores
An auxiliary database backup operation backs up the database data on each auxiliary database station in the active cluster. Scheduled backups are strongly recommended.
Note: Scheduled auxiliary database backups are disabled by default.
See How do I schedule auxiliary database backups? for information about enabling scheduled backups, and How do I back up an auxiliary database? for information about performing an on-demand auxiliary database backup.
Although an auxiliary database may be distributed among multiple stations, a database restore operation is initiated on one station, and automatically replicates the restored data among the other stations, as required.
See How do I restore an auxiliary database? for information about restoring an auxiliary database.
Fault detection
To detect a database failure or a connectivity loss, the NFM-P monitors each auxiliary database station in the active cluster, and raises one of the following major or critical alarms, which are not self-clearing unless otherwise noted:
Note: The geo-redundancy alarms listed below are NSP alarms and not NFM-P alarms, so are not shown in the NFM-P client GUI.
The geo-redundancy alarm information is also available to Kafka subscribers of the FAULT topic and REST API clients, but not to NFM-P XML API clients.