Admin Process (AP)

The role of a NuoDB Admin process (AP) is to provide database life cycle control (start, stop) for Transaction Engines (TEs) and Storage Managers (SMs). An AP provides the following:

  • Allows management client access via NuoDB Command (nuocmd), which communicates directly to an AP.

  • Communicates with all other APs in the domain.

  • Routes SQL connection requests to TEs anywhere in the domain, using different SQL connection load-balancing schemes.

  • Stores the durable domain configuration.

  • Monitors activity and fires alarms for all hosts, databases and processes in the domain.

  • Provides safety in case of failure, such as network partitioning. Safety means that an incorrect result is never returned.

Each AP has a complete picture of the entire domain, including all hosts, and all databases and their processes. For continuous availability, each data center (or cloud deployment availability zone) should run at least one AP.

Admin Process (AP) Peering

A domain must contain at least one AP. Any additional APs join the domain by securely connecting (peering) into the domain by means of another AP. The APs communicate with each other to make sure they are still accessible and available.

In physical / VMware deployments, each AP is configured to run on its own physical host in the domain. Post-installation, the AP is not initially started by default.

The nuoadmin.conf file on each host must be configured appropriate for the intended deployment configuration. The settings of the initial membership and or peer property is the same in each of the nuoadmin.conf files on each host. On each host, the value of the peering property value used is the hostname and port of the host machine running the initial AP.

The first AP started becomes the quorum leader admin server. The leader AP performs the liveliness checks for the domain peers and determines if another AP is no longer responding. When further APs are started, they peer into the domain through an existing AP.

All APs have a last known state for the domain, so they can be restarted in any order and will reconnect properly. The initial peer used to connect to the domain no longer matters.

A NuoDB domain can be expanded dynamically by starting additional APs on new hosts, and peering them into the domain. The new AP can connect to all existing APs in the domain by using the address and port of an existing AP.

An AP can be removed dynamically and gracefully from the domain using the shutdown server command .

The shutdown server command is issued using NuoDB Command (nuocmd). For information on using NuoDB Command and other NuoDB command line utilities, see Command Line Tools.

In summary:

  • One AP in the domain peers to itself.

  • In a domain, all APs peer to the same AP.

  • All APs can start at the same time.

  • The initial AP, the one with peer set to its own address, does not need to be restarted first.

  • If a peer is unreachable, NuoDB falls back to its last known state, if there is one.