EnterpriseDB Failover Manager What is it? How Can it be established?

High Availability Solutions, Part 1

Authors: Aybars Hallik, Doğan Kemal Cenan

Welcome to our new blog series focusing on High Availability Solutions.

In the first episode of the series “What is EnterpriseDB Failover Manager? How to Install It?” will focus on the topic, EnterpriseDB’s high availability tool EnterpriseDB Failover Manager We will explain the integration of pgpool, a tool developed by the Postgres community that offers many features such as load balancing and connection pooling, with (EFM).

What is replication?

Replication is the process of copying data from a primary database to one or more backup databases. In replication, the primary database is responsible for read-write operations, while the backup database is responsible for read-only operations.
In this article, we will use the terms “primary” or “master” database as “ana veritabanı”, and “secondary” or “standby” database as “yedek veritabanı”.

What is EnterpriseDB Failover Manager?

The EFM high availability module is a tool developed by EnterpriseDB that automatically makes one of the standby databases the primary database—that is, performs the “Promote” operation—in the event of issues that may arise in the primary database due to software and/or hardware reasons.

Information we will provide in this document about the function of the EFM tool and how to install it PostgreSQL or EDB Postgres Advanced Server (EPAS) Applies to version 9.6 and later of databases.

Typical EFM cluster elements consist of the components specified below.

• Master node: It is the primary database server in the replication structure.
• Standby node: A standby node is a database server that uses streaming replication with the primary node.
• Witness node: Following a disaster scenario, it witnesses the new role definitions and statuses assigned to two or more nodes. If the cluster contains three or more nodes (provided that the total number of nodes in the cluster is an odd number), a separate witness node is not needed in the cluster, as one of the nodes can fulfill the witness duty. However, if there is no third cluster member node containing a database, a witness node must be added. Furthermore, the cluster may also contain multiple witness nodes (again, provided that the total number of nodes is an odd number).

Normally, the term cluster describes a single PostgreSQL installation managing multiple databases. However, the term cluster used in this article series will refer to the EFM cluster.

The EFM cluster can reside on servers in the cloud or in a traditional network. It provides communication via the JGroups library, which is written to enable one-to-one and one-to-many communication. This cluster can consist of a primary EFM agent, one or more backup EFM agents, and optionally a witness EFM agent.

The above figure shows an EFM cluster using a Virtual IP address. The Virtual IP address ensures that all requests directed to the EFM cluster arrive at a single IP address and are distributed from there. If these changes can be reported to the load balancer as databases are added to or removed from the cluster online, software acting as a load balancer can also assume the virtual IP address function. We will use pgpool as the load balancing tool. We will demonstrate how to perform the pgpool-EFM integration by leaving the task of managing the Virtual IP to pgpool and editing the configuration file provided by EFM to notify EFM as databases are added to or removed from the cluster.

When any EFM agent other than the witness is started, the agent connects to the database and checks its status.

• If it cannot reach the database, it starts as IDLE.
• During the database recovery process, the database on the agent's node assumes the role of the standby database.
• If the database is not in recovery, the database on the agent node assumes the primary database role.

In the event of a failover, EFM ensures that the standby server designated as the primary database is the most up-to-date standby server in the cluster. However, if the primary node and the standby node are not in sync, EFM does not automatically perform the promote operation.

What are the EnterpriseDB Failover Manager Requirements?

Before configuring the EFM cluster, the system must meet the following requirements.

• Java 1.8 (or later) Installation
  • Before using EFM, we must have Java installed (version 1.8 or later).
  • EFM has been tested with OpenJDK, and it is recommended to install the specified version.
  • Instructions for Java installation are platform-specific.
• SMTP Server Configuration (Optional)
  • When using EFM, it is possible to choose to receive notifications by user-defined script, email, or both.
  • If any of these methods are to be used, the SMTP server must be active.
• Streaming Replication Configuration
  • For EFM, PostgreSQL streaming replication (SR) must be configured between the primary and standby nodes.
  • EFM does not support other replication types.
• Editing the pg_hba.conf file
  • The pg_hba.conf files on the primary and standby nodes must be configured to allow communication between all nodes in the cluster.
  • Below is an example of the lines that must be in the pg_hba.conf file on the primary node.

For access to #

host database_name efm 127.0.0.1/32 md5

For access to the # backup server

host database_name efm 192.168.1.1/32 md5

To access the # witness server

host database_name efm 192.168.1.2/32 md5

• After modifying the pg_hba.conf file, the system needs to be reloaded (using pg_ctl reload or “select pg_reload_conf();”) for the changes to take effect.

• Ensuring communication between firewalls
  • If the Linux firewalls on the EFM nodes are enabled, rules granting the necessary permissions must be added to the firewall configurations.
  • The following command opens port 7800. EFM establishes the connection using the port number specified in the configuration file. If firewalls are not active, this process is not necessary.

iptables -I INPUT -p tcp --dport 7800 -j ACCEPT /sbin/service iptables save

• The database user having the necessary permissions
  • the database user specified in the db.user parameter in the efm.properties file, 
    • pg_current_wal_lsn()
    • pg_last_wal_replay_lsn()
    • pg_wal_replay_resume()
    • pg_wal_replay_pause()

must have sufficient database privileges to be able to call its functions.

• reconfigure.num.sync or reconfigure.sync.primary if the parameters are set to ‘true’:
  • For version 9.6 db.user The user specified in the parameter must be a superuser.
  • For versions after 9.6, the specified database user pg_read_all_stats and to his authority pg_reload_conf()’must have permission to run it.
• Additionally, the specified user must have the privilege to read the configuration values. The authorized user in the database can grant the necessary permissions to the user using the GRANT command.

GRANT pg_read_all_settings TO ;

How to Install EnterpriseDB Failover Manager?

EFM installation, root must be performed by the user. During installation, a user named efm is created, which has the authority to monitor the EFM service for databases (clusters) authorized by the enterprisedb (EPAS superuser) or postgres (PostgreSQL superuser) user and has the authority to use the scripts. The installation steps for CentOS 7 are as follows.

 1. To create repo configuration files, superuser privileges are required. Then, the following command is run.

yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm

 2. Following the installation in the first step, the edb.repo file will be created under the /etc/yum.repos.d directory. The USERNAME and PASSWORD information in this file is replaced with the username and password information obtained from the EnterpriseDB website. This process can be done by opening the file with any editor, or

sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo

This can also be done by replacing the USERNAME and PASSWORD parts with the information obtained from EDB and running the command.

 3. The EPEL repository is installed.

yum -y install epel-release

 4. The EFM package is installed. To avoid errors during this installation, the changes specified in step 2 must be made correctly in the edb.repo file.

yum -y install edb-efm44

 5. After installation, the files will be created in the directories specified below.

• • Executable files
    • /usr/edb/efm-4.4/bin
  • Libraries
    • /usr/edb/efm-4.4/lib
  • Configuration files
    • /etc/edb/efm-4.4
  • Logs
    • /var/log/efm-4.4

 6. For each node after installation

• • The efm.properties file is edited.
  • The efm.nodes file is edited.
  • If the Virtual IP address and code snippet are defined in the efm.properties file, configuration and testing procedures must be performed.
  • EFM agents on each node of the cluster are started.

Wait for our next blog post to learn the details of these processes.

Meanwhile, to get more information about EnterpriseDB Click.