Topology configuration
Topology configuration enables grouping servers and mirroring configuration changes automatically. It uses a primary/secondary architecture for mirroring shared data across the topology.
All writes and updates are forwarded to the primary, which forwards them to all other servers. Reads can be served by any server in the group.
|
To remove a server from the topology, it must be uninstalled with the |
Topology primary requirements and selection
A topology primary server receives any configuration change from other servers in the topology, verifies the change, then makes the change available to all connected servers when they poll the primary. The primary always sends a digest of its subtree contents on each update. If the node has a different digest than the primary, it knows it’s not synchronized. The servers will pull the entire subtree from the primary if they detect that they are not synchronized. A server can detect it is not synchronized with the primary under the following conditions:
-
At the end of its periodic polling interval, if a server’s subtree digest differs from that of its primary, then it knows it’s not synchronized.
-
If one or more servers have been added to or removed from the topology, the servers will not be synchronized.
The primary of the topology is selected by prioritizing servers by minimum supported product version, most available, newest server version, earliest start time, and startup UUID (a smaller UUID is preferred).
After determining a primary, the topology data is reviewed from all available servers (every five seconds by default) to determine if any new information makes a server better suited to being the primary. If a new server can be the primary, it will communicate that to the other servers, if no other server has advertised that it should be the primary. This ensures that all servers accept the same primary at approximately the same time (within a few milliseconds of each other). If there is no better primary, the initial primary maintains the role.
After the best primary has been selected for the given interval, the following conditions are confirmed:
-
A majority of servers is reachable from that primary. (The primary server itself is considered while determining this majority.)
-
There is only a single primary in the entire topology.
If either of these conditions is not met, the topology is without a primary and the peer polling frequency is reduced to 100 milliseconds to find a new primary as quickly as possible. If there is no primary in the topology for more than one minute, a mirrored-subtree-manager-no-master-found alarm is raised. If one of the servers in the topology is forced as primary with the force-as-master-for-mirrored-data option in the Global Configuration configuration object, a mirrored-subtree-manager-forced-as-master-warning alarm is raised. If multiple servers have been forced as primaries, then a mirrored-subtree-manager-forced-as-master-error critical alarm will be raised.
Topology components
When a server is installed, it can be added to an existing topology, which will clone the server’s configuration. Topology settings are designed to operate without additional configuration. If required, some settings can be adjusted to fit the needs of the environment.
Server configuration settings
Configuration settings for the topology are configured in the Global Configuration and in the Config File Handler Backend. Though they are topology settings, they are unique to each server and are not mirrored. Settings must be kept the same on all servers.
The Global Configuration object contains a single topology setting, force-as-master-for-mirrored-data. This should be set to true on only one of the servers in the topology, and is used only if a situation occurs where the topology cannot determine a primary because a majority of servers is not available. A server with this setting enabled will be assigned the role of primary if no suitable primary can be determined. See Topology primary requirements and selection for details about how a primary is selected for a topology.
The Config File Handler Backend defines three topology (mirrored-subtree) settings:
-
mirrored-subtree-peer-polling-interval– Specifies the frequency at which the server polls its topology peers to determine if there are any changes that might warrant a new primary selection. A lower value will ensure a faster failover, but it will also cause more traffic among the peers. The default value is five seconds. If no suitable primary is found, the polling frequency is adjusted to 100 milliseconds until a new primary is selected. -
mirrored-subtree-entry-update-timeout– Specifies the maximum length of time to wait for an update operation (add, delete, modify or modify-dn) on an entry to be applied by the primary on all of the servers in the topology. The default is 10 seconds. In reality, updates can take up to twice as much time as this timeout value if primary selection is in progress at the time the update operation was received. -
mirrored-subtree-search-timeout– Specifies the maximum length of time in milliseconds to wait for search operations to complete. The default is 10 seconds.
Monitor data for the topology
Each server has a monitor that exposes that server’s view of the topology in its monitor backend, so that peer servers can periodically read this information to determine if there are changes in the topology. Topology data includes the following:
-
The server ID of the current primary, if the primary is not known.
-
The instance name of the current primary, or if a primary is not set, a description stating why a primary is not set.
-
A flag indicating if this server thinks that it should be the primary.
-
A flag indicating if this server is the current primary.
-
A flag indicating if this server was forced as primary.
-
The total number of configured peers in the topology group.
-
The peers connected to this server.
-
The current availability of this server.
-
A flag indicating whether or not this server is not synchronized with its primary, or another node in the topology if the primary is unknown.
-
The amount of time in milliseconds where multiple primaries were detected by this server.
-
The amount of time in milliseconds where no suitable server is found to act as primary.
-
A SHA-256 digest encoded as a base-64 string for the current subtree contents.
The following metrics are included if this server has processed any operations as primary:
-
The number of operations processed by this server as primary.
-
The number of operations processed by this server as primary that were successful.
-
The number of operations processed by this server as primary that failed to validate.
-
The number of operations processed by this server as primary that failed to apply.
-
The average amount of time taken (in milliseconds) by this server to process operations as the primary.
-
The maximum amount of time taken (in milliseconds) by this server to process an operation as the primary.