Set Up a Cluster

This topic explains the following types of clusters:
To protect your deployment from failure, set up a cluster. A cluster consists of multiple instances (virtual or physical appliances) that replicate data to operate as a single system. A cluster can provide redundancy, disaster recovery, or load-balancing to your infrastructure.
This topic explains the following types of clusters:
Privileged Access Manager
offers clustering across multiple geographically dispersed sites, which is known as “multi-site” clustering. Multi-site clustering uses the concept of one “primary” site and one or more “secondary” sites. Each site can have multiple instances or appliances. A secondary site can provide a warm backup for disaster recovery.
A single-site cluster behaves the same as a primary site in a multi-site cluster. Primary site or single-site clustering uses group replication to keep itself in sync.
Load balancing can be configured across the members of a site using an internal
Privileged Access Manager
virtual IP address (VIP).
The following diagram illustrates an example with three data centers. Each site is accessible using a separate
Privileged Access Manager
VIP. In this example, one optional external load balancer groups all the sites together for user access. The other optional load balancer sits in front of the primary site.
Multi-Site Cluster Example
Multi-Site Cluster Example
Single-Site Cluster or Primary Site
Group replication clustering improves throughput and expands capacity by replicating data to its members. Incoming user logins are spread out by directing them through an internal
Privileged Access Manager
  • A
    Primary Site
    should locate its members in the same data center. Group replication is best supported in geographical proximity. Remote data centers are best served as Secondary Sites.
  • Primary Leader:
    The first cluster member that is listed in a Primary site is the data synchronization source for all cluster members.
  • Cluster size:
    A Primary Site is limited to nine members. We recommend three and a maximum of five members. (See
    , below.) The more members that you add, the more communication work the cluster has to do. The total number of members in all sites is limited to 1,000.
  • Quorum:
    In MySQL group replication, a "quorum" is the number of members required to make decisions for the cluster, such as whether a member has failed. The quorum is the majority of the members in a cluster, or in this case the Primary Site. For this reason, we recommend an odd number of members, such as 3 (whose quorum is 2), or 5 (whose quorum is 3). However, we do support fewer members. 
  • Data Replication:
    Changes to administrative and Credential Management data can be made through any member and can propagate to the other members. When starting the cluster, the database from the first member is replicated to the other members, overwriting their data. Member-specific information, such as logs and some configuration data are not replicated.
  • Load Balancing:
    Provide a VIP address and optional FQDN for load balancing. End-users use this address to connect to
    Privileged Access Manager
    . The primary member of the cluster redirects a request to the least-loaded member. You can bypass the load balancing to contact the members directly, which is useful when debugging a specific member.
  • Single-site
    Primary Site
    replication uses MySQL 8 Group Replication.
Multi-Site Cluster and Secondary Sites
Once you add a new site in Clustering, you have a multi-site cluster. Site Name fields and Primary Site buttons appear for your original cluster and your new site. Under the Multi-Site heading, a choice appears between Operationally Safe and Security Safe. Important differences exist between the Primary and Secondary sites, and their members:
  • There can only be one Primary Site, which is the source of data for the Secondary sites. If the Primary site fails, a Secondary site can be manually promoted to be the Primary site.
  • Secondary site members are intended to support end-user access rather than global administrative functions. Some local administrative functions are available on Secondary members, including: managing sessions, logs, and recordings; managing password approvals, viewing credentials, and disaster recovery; some diagnostics; network, and security.
  • Secondary sites, with few exceptions, do not support REST API or CLI operations. (The specific CLI command documentation mentions this, as in .) Use the VIP of the primary site for REST API and CLI commands. 
  • The best practice is to have each member of a particular Secondary site in the same data center. Load balancing within a Secondary site is accomplished by configuring the internal VIP.
  • Each Secondary site has a leader which receives updates from the Primary site. The Secondary leader then replicates the data to the other site members and relays updates from Secondary members to the Primary site. This topology minimizes WAN traffic between the sites.
  • If the Secondary leader goes offline, the other site members communicate directly with the Primary site.
  • Secondary members can “self-heal” after being disconnected. See Cluster Synchronization, Promotion, and Recovery for details.
  • Members can be added or removed from Secondary sites without stopping the cluster. This process requires a VIP for the site you are subscribing to. The last Secondary site cannot be removed unless the cluster is restarted.
  • Multi-site clustering uses MySQL 8 traditional master-slave replication to communicate between primary and secondary sites.
Next Steps