diff --git a/install_template/templates/products/failover-manager/base.njk b/install_template/templates/products/failover-manager/base.njk index 7c8193e0626..070f626ca5e 100644 --- a/install_template/templates/products/failover-manager/base.njk +++ b/install_template/templates/products/failover-manager/base.njk @@ -21,7 +21,7 @@ redirects: {{ super() }} {% endblock product_prerequisites %} {% block postinstall %} -Where `<4x>` is the version of Failover Manager that you're installing. For example, if you're installing version 4.8, the package name is `edb-efm48`. +Where `<4x>` is the version of Failover Manager that you're installing. For example, if you're installing version 4.9, the package name is `edb-efm49`. The installation process creates a user named efm that has privileges to invoke scripts that control the Failover Manager service for clusters owned by enterprisedb or postgres. diff --git a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx index 6f530d684b0..ba72d11682d 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/01_cluster_properties.mdx @@ -15,7 +15,7 @@ Each node in a Failover Manager cluster has a properties file (by default, named After completing the Failover Manager installation, make a working copy of the template before modifying the file contents: ```text -# cp /etc/edb/efm-4.8/efm.properties.in /etc/edb/efm-4.8/efm.properties +# cp /etc/edb/efm-4.9/efm.properties.in /etc/edb/efm-4.9/efm.properties ``` After copying the template file, change the owner of the file to efm: @@ -224,42 +224,15 @@ db.bin= -Use the `db.data.dir` property to specify the location to write a recovery file on the primary node of the cluster during promotion. This property is required on primary and standby nodes. It isn't required on a dedicated witness node. +Use the `db.data.dir` property to specify the location where a `standby.signal` or `recovery.conf` file will be created. This property is required on primary and standby nodes. It isn't required on a dedicated witness node. ```ini -# For database version 12 and up, this is the directory where a -# standby.signal file will exist for a standby node. For previous -# versions, this is the location of the db recovery.conf file on -# the node. -# After a failover, the recovery.conf files on remaining standbys are -# changed to point to the new primary db (a copy of the original is made -# first). On a primary node, a recovery.conf file will be written during -# failover and promotion to ensure that the primary node can not be -# restarted as the primary database. -# This corresponds to database environment variable PGDATA and should -# be same as the output of query 'show data_directory;' on respective -# database. -db.data.dir= -``` - - - - -Use the `db.data.dir` property to specify the location to write a recovery file on the primary node of the cluster during promotion. This property is required on primary and standby nodes. It isn't required on a dedicated witness node. - -```ini -# For database version 12 and up, this is the directory where a -# standby.signal file will exist for a standby node. For previous -# versions, this is the location of the db recovery.conf file on -# the node. -# After a failover, the recovery.conf files on remaining standbys are -# changed to point to the new primary db (a copy of the original is made -# first). On a primary node, a recovery.conf file will be written during -# failover and promotion to ensure that the primary node can not be -# restarted as the primary database. -# This corresponds to database environment variable PGDATA and should -# be same as the output of query 'show data_directory;' on respective -# database. +# This is the directory where a standby.signal file will exist for a standby node. +# If a primary database fails, a recovery.conf file will be written in this +# location to ensure that the failed database can not be restarted as the +# primary database. +# This corresponds to database environment variable PGDATA and should be same +# as the output of query 'show data_directory;' on respective database. db.data.dir= ``` @@ -269,14 +242,13 @@ Use the `db.config.dir` property to specify the location of database configurati ```ini # Specify the location of database configuration files if they are -# not contained in the same location as the recovery.conf or -# standby.signal file. This is most likely the case for Debian -# installations. The location specified will be used as the -D value -# (the location of the data directory for the cluster) when calling -# pg_ctl to start or stop the database. If this property is blank, -# the db.data.dir location specified by the db.data.dir property will -# be used. This corresponds to the output of query 'show config_file;' -# on respective database. +# not contained in the same location as the standby.signal +# file. This is most likely the case for Debian installations. The location +# specified will be used as the -D value (the location of the data directory +# for the cluster) when calling pg_ctl to start or stop the database. +# If this property is blank, the db.data.dir location specified by the +# db.data.dir property will be used. +# This corresponds to the output of query 'show config_file;' on respective database. db.config.dir= ``` @@ -315,10 +287,10 @@ For information about configuring and using SSL, see [Secure TCP/IP Connections Use the `user.email` property to specify an email address (or multiple email addresses) to receive notifications sent by Failover Manager. ```ini -# Email address(es) for notifications. The value of this -# property must be the same across all agents. Multiple email -# addresses must be separated by space. If using a notification -# script instead, this property can be left blank. +# Email address(es) for notifications. The value of this property must +# be the same across all agents. Multiple email addresses must +# be separated by space. This is required if not using a 'script.notification' +# script. Either/both can be used. user.email= ``` @@ -506,10 +478,11 @@ Use the `node.timeout` property to specify the number of seconds for an agent to node.timeout=50 ``` -!!! Summary/comparison of timeout properties - - The `local.*` properties are for failure detection of an agent's local database. - - The `node.timeout` property is for failure detection of other nodes. - - The `remote.timeout` property limits how long agents wait for responses from other agents. +!!!note Summary/comparison of timeout properties + - The `local.*` properties are for failure detection of an agent's local database. + - The `node.timeout` property is for failure detection of other nodes. + - The `remote.timeout` property limits how long agents wait for responses from other agents. +!!! @@ -584,7 +557,7 @@ To perform maintenance on the primary database when `primary.shutdown.as.failure -Use the `update.physical.slots.period` property to define the slot advance frequency for database version 12 and later. When `update.physical.slots.period` is set to a positive integer value, the primary agent reads the current `restart_lsn` of the physical replication slots after every `update.physical.slots.period` seconds and sends this information with its `pg_current_wal_lsn` and `primary_slot_name` (if it is set in the postgresql.conf file) to the standbys. The physical slots must already exist on the primary for the agent to find them. If physical slots do not already exist on the standbys, standby agents create the slots and then update `restart_lsn` parameter for these slots. A non-promotable standby doesn't create new slots but updates them if they exist. +Use the `update.physical.slots.period` property to define the slot advance frequency. When `update.physical.slots.period` is set to a positive integer value, the primary agent reads the current `restart_lsn` of the physical replication slots after every `update.physical.slots.period` seconds and sends this information with its `pg_current_wal_lsn` and `primary_slot_name` (if it is set in the postgresql.conf file) to the standbys. The physical slots must already exist on the primary for the agent to find them. If physical slots do not already exist on the standbys, standby agents create the slots and then update `restart_lsn` parameter for these slots. A non-promotable standby doesn't create new slots but updates them if they exist. Before updating the `restart_lsn` value of a slot, the agent checks to see if an `xmin` value has been set, which may happen if this was previously a primary node. If an `xmin` value has been set for the slot, the agent drops and recreates the slot before updating the `restart_lsn` value. @@ -690,15 +663,14 @@ auto.failover=true -Use the `auto.reconfigure` property to instruct Failover Manager to enable or disable automatic reconfiguration of remaining standby servers after the primary standby is promoted to primary. Set the property to `true` (the default) to enable automatic reconfiguration or `false` to disable automatic reconfiguration. This property isn't required on a dedicated witness node. If you're using EDB Postgres Advanced Server or PostgreSQL version 11, the `recovery.conf` file is backed up during the reconfiguration process. +Use the `auto.reconfigure` property to instruct Failover Manager to enable or disable automatic reconfiguration of remaining standby servers after the primary standby is promoted to primary. Set the property to `true` (the default) to enable automatic reconfiguration or `false` to disable automatic reconfiguration. This property isn't required on a dedicated witness node. ```ini # After a standby is promoted, Failover Manager will attempt to -# update the remaining standbys to use the new primary. For database -# versions before 12, Failover Manager will back up recovery.conf. -# Then it will change the host parameter of the primary_conninfo entry -# in recovery.conf or postgresql.auto.conf, and restart the database. -# The restart command is contained in either the efm_db_functions or +# update the remaining standbys to use the new primary. Failover +# Manager will change the host parameter of the primary_conninfo +# entry in postgresql.auto.conf and restart the database. The +# restart command is contained in either the efm_db_functions or # efm_root_functions file; default when not running db as an os # service is: "pg_ctl restart -m fast -w -t -D " # where the timeout is the local.timeout property value and the diff --git a/product_docs/docs/efm/4/04_configuring_efm/02_encrypting_database_password.mdx b/product_docs/docs/efm/4/04_configuring_efm/02_encrypting_database_password.mdx index 55a32440c2f..5cdae81fe6e 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/02_encrypting_database_password.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/02_encrypting_database_password.mdx @@ -35,7 +35,7 @@ This example shows using the `encrypt` utility to encrypt a password for the `ac # efm encrypt acctg This utility will generate an encrypted password for you to place in your Failover Manager cluster property file: -/etc/edb/efm-4.8/acctg.properties +/etc/edb/efm-4.9/acctg.properties Please enter the password and hit enter: Please enter the password again to confirm: The encrypted password is: 516b36fb8031da17cfbc010f7d09359c @@ -49,17 +49,11 @@ db.password.encrypted=516b36fb8031da17cfbc010f7d09359c After receiving your encrypted password, paste the password into the properties file and start the Failover Manager service. If there's a problem with the encrypted password, the Failover Manager service doesn't start: ```text -[witness@localhost ~]# systemctl start edb-efm-4.8 -Job for edb-efm-4.8.service failed because the control process exited with error code. See "systemctl status edb-efm-4.8.service" and "journalctl -xe" for details. +[witness@localhost ~]# systemctl start edb-efm-4.9 +Job for edb-efm-4.9.service failed because the control process exited with error code. See "systemctl status edb-efm-4.9.service" and "journalctl -xe" for details. ``` -If you receive this message when starting the Failover Manager service, see the startup log `/var/log/efm-4.8/startup-efm.log` for more information. - -If you are using RHEL/CentOS 7.x or RHEL/Rocky Linux/AlmaLinux 8.x, startup information is also available with the following command: - -```shell -systemctl status edb-efm-4.8 -``` +If you receive this message when starting the Failover Manager service, see the startup log `/var/log/efm-4./startup-efm.log` for more information. To prevent a cluster from inadvertently connecting to the database of another cluster, the cluster name is incorporated into the encrypted password. If you modify the cluster name, you must re-encrypt the database password and update the cluster properties file. diff --git a/product_docs/docs/efm/4/04_configuring_efm/03_cluster_members.mdx b/product_docs/docs/efm/4/04_configuring_efm/03_cluster_members.mdx index aae28ced623..93772136379 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/03_cluster_members.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/03_cluster_members.mdx @@ -15,7 +15,7 @@ Each node in a Failover Manager cluster has a cluster members file (by default n After completing the Failover Manager installation, make a working copy of the template: ```shell -cp /etc/edb/efm-4.8/efm.nodes.in /etc/edb/efm-4.8/efm.nodes +cp /etc/edb/efm-4.9/efm.nodes.in /etc/edb/efm-4.9/efm.nodes ``` After copying the template file, change the owner of the file to efm: diff --git a/product_docs/docs/efm/4/04_configuring_efm/04_extending_efm_permissions.mdx b/product_docs/docs/efm/4/04_configuring_efm/04_extending_efm_permissions.mdx index c0906b88a0c..8097034f4a1 100644 --- a/product_docs/docs/efm/4/04_configuring_efm/04_extending_efm_permissions.mdx +++ b/product_docs/docs/efm/4/04_configuring_efm/04_extending_efm_permissions.mdx @@ -21,7 +21,7 @@ The `efm_db_functions` or `efm_root_functions` scripts perform management functi The `sudoers` file contains entries that allow the user efm to control the Failover Manager service for clusters owned by postgres or enterprisedb. You can modify a copy of the `sudoers` file to grant permission to efm to manage Postgres clusters owned by other users. -The `efm-48` file is located in `/etc/sudoers.d` and contains the following entries: +The `efm-49` file is located in `/etc/sudoers.d` and contains the following entries: ```text # Copyright EnterpriseDB Corporation, 2014-2021. All Rights Reserved. @@ -36,24 +36,24 @@ The `efm-48` file is located in `/etc/sudoers.d` and contains the following entr # If you run your db service under a non-default account, you will need to copy # this file to grant the proper permissions and specify the account in your efm # cluster properties file by changing the 'db.service.owner' property. -efm ALL=(postgres) NOPASSWD: /usr/edb/efm-4.8/bin/efm_db_functions -efm ALL=(enterprisedb) NOPASSWD: /usr/edb/efm-4.8/bin/efm_db_functions +efm ALL=(postgres) NOPASSWD: /usr/edb/efm-4.9/bin/efm_db_functions +efm ALL=(enterprisedb) NOPASSWD: /usr/edb/efm-4.9/bin/efm_db_functions # Allow user 'efm' to sudo efm_root_functions as 'root' to write/delete the PID file, # validate the db.service.owner property, etc. -efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.8/bin/efm_root_functions +efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.9/bin/efm_root_functions # Allow user 'efm' to sudo efm_address as root for VIP tasks. -efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.8/bin/efm_address +efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.9/bin/efm_address # Allow user 'efm' to sudo efm_pgpool_functions as root for pgpool tasks. -efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.8/bin/efm_pgpool_functions +efm ALL=(ALL) NOPASSWD: /usr/edb/efm-4.9/bin/efm_pgpool_functions # relax tty requirement for user 'efm' Defaults:efm !requiretty ``` -If you're using Failover Manager to monitor clusters that are owned by users other than postgres or enterprisedb, make a copy of the `efm-48` file. Then modify the content to allow the user to access the `efm_functions` script to manage their clusters. +If you're using Failover Manager to monitor clusters that are owned by users other than postgres or enterprisedb, make a copy of the `efm-49` file. Then modify the content to allow the user to access the `efm_functions` script to manage their clusters. If an agent can't start because of permission problems, make sure the default `/etc/sudoers` file contains the following line at the end of the file: @@ -89,9 +89,9 @@ To run Failover Manager without sudo, you must select a database process owner w ```shell su - enterprisedb - cp /etc/edb/efm-4.8/efm.properties.in .properties + cp /etc/edb/efm-4.9/efm.properties.in .properties - cp /etc/edb/efm-4.8/efm.nodes.in /.nodes + cp /etc/edb/efm-4.9/efm.nodes.in /.nodes ``` Then, modify the cluster properties file, providing the name of the user in the `db.service.owner` property. Also make sure that the `db.service.name` property is blank. Without sudo, you can't run services without root access. @@ -99,7 +99,7 @@ Then, modify the cluster properties file, providing the name of the user in the After modifying the configuration, the new user can control Failover Manager with the following command: ```shell -/usr/edb/efm-4.8/bin/runefm.sh start|stop .properties +/usr/edb/efm-4.9/bin/runefm.sh start|stop .properties ``` Where `` specifies the full path of the cluster properties file. The user provides the full path to the properties file whenever the nondefault user is controlling agents or using the `efm` script. diff --git a/product_docs/docs/efm/4/05_using_efm.mdx b/product_docs/docs/efm/4/05_using_efm.mdx index b7040a1dbec..a2e7ba1d577 100644 --- a/product_docs/docs/efm/4/05_using_efm.mdx +++ b/product_docs/docs/efm/4/05_using_efm.mdx @@ -132,13 +132,13 @@ Where: During switchover: -- For server version 11, the `recovery.conf` file is copied from an existing standby to the primary node. For server version 12 and later, the `primary_conninfo` and `restore_command` parameters are copied and stored in memory. +- The `primary_conninfo` and `restore_command` parameters are copied from an existing standby to the primary node are and stored in memory. - The primary database is stopped. - If you are using a VIP, the address is released from the primary node. - A standby is promoted to replace the primary node and acquires the VIP. -- The address of the new primary node is added to the `recovery.conf` file or the `primary_conninfo` details are stored in memory. -- If the `application.name` property is set for this node, the application_name property is added to the `recovery.conf` file or the `primary_conninfo` information is stored in memory. -- If you're using server version 12 or later, the recovery settings that were stored in memory are written to the `postgresql.auto.conf` file. A `standby.signal` file is created. +- The address of the new primary node is added to the `primary_conninfo` details stored in memory. +- If the `application.name` property is set for this node, the application_name property is added to the `primary_conninfo` information stored in memory. +- The recovery settings that were stored in memory are written to the `postgresql.auto.conf` file. A `standby.signal` file is created. - The old primary is started; the agent resumes monitoring it as a standby. During a promotion, the primary agent releases the virtual IP address. If it isn't a switchover, a `recovery.conf` file is created in the directory specified by the `db.data.dir` property. The `recovery.conf` file is used to prevent the old primary database from starting until the file is removed, preventing the node from starting as a second primary in the cluster. If the promotion is part of a switchover, recovery settings are handled as described above. @@ -271,11 +271,11 @@ After creating the `acctg.properties` and `sales.properties` files, create a ser If you're using RHEL/CentOS 7.x or RHEL/Rocky Linux/AlmaLinux 8.x, copy the service file `/usr/lib/systemd/system/edb-efm-4..service` to `/etc/systemd/system` with a new name that's unique for each cluster. -For example, if you have two clusters named `acctg` and `sales` managed by Failover Manager 4.8, the unit file names might be `efm-acctg.service` and `efm-sales.service`. You can create them with: +For example, if you have two clusters named `acctg` and `sales` managed by Failover Manager 4.9, the unit file names might be `efm-acctg.service` and `efm-sales.service`. You can create them with: ```shell -cp /usr/lib/systemd/system/edb-efm-4.8.service /etc/systemd/system/efm-acctg.service -cp /usr/lib/systemd/system/edb-efm-4.8.service /etc/systemd/system/efm-sales.service +cp /usr/lib/systemd/system/edb-efm-4.9.service /etc/systemd/system/efm-acctg.service +cp /usr/lib/systemd/system/edb-efm-4.9.service /etc/systemd/system/efm-sales.service ``` Then use `systemctl edit` to edit the `CLUSTER` variable in each unit file, changing the specified cluster name from `efm` to the new cluster name. @@ -286,7 +286,7 @@ In this example, edit the `acctg` cluster by running `systemctl edit efm-acctg.s ```ini [Service] Environment=CLUSTER=acctg -PIDFile=/run/efm-4.8/acctg.pid +PIDFile=/run/efm-4.9/acctg.pid ``` Edit the `sales` cluster by running `systemctl edit efm-sales.service` and write: @@ -294,7 +294,7 @@ Edit the `sales` cluster by running `systemctl edit efm-sales.service` and write ```ini [Service] Environment=CLUSTER=sales -PIDFile=/run/efm-4.8/sales.pid +PIDFile=/run/efm-4.9/sales.pid ``` !!!Note diff --git a/product_docs/docs/efm/4/08_controlling_efm_service.mdx b/product_docs/docs/efm/4/08_controlling_efm_service.mdx index 3a9ddfc1005..479f26fb5f1 100644 --- a/product_docs/docs/efm/4/08_controlling_efm_service.mdx +++ b/product_docs/docs/efm/4/08_controlling_efm_service.mdx @@ -40,12 +40,12 @@ Stop the Failover Manager on the current node. This command must be invoked by r The `status` command returns the status of the Failover Manager agent on which it is invoked. You can invoke the status command on any node to instruct Failover Manager to return status and server startup information. ```text -[root@ONE ~]}> systemctl status edb-efm-4.8 - edb-efm-4.8.service - EnterpriseDB Failover Manager 4.8 - Loaded: loaded (/usr/lib/systemd/system/edb-efm-4.8.service; disabled; vendor preset: disabled) - Active: active (running) since Mon 2023-09-18 09:57:13 EDT; 1min 32s ago - Process: 58125 ExecStart=/bin/bash -c /usr/edb/edb-efm-4.8/bin/runefm.sh start ${CLUSTER} (code=exited, status=0/SUCCESS) +[root@ONE ~]}> systemctl status edb-efm-4.9 + edb-efm-4.9.service - EnterpriseDB Failover Manager 4.9 + Loaded: loaded (/usr/lib/systemd/system/edb-efm-4.9.service; disabled; vendor preset: disabled) + Active: active (running) since Thu 2024-04-11 11:02:31 EDT; 4h 11min ago + Process: 58125 ExecStart=/bin/bash -c /usr/edb/edb-efm-4.9/bin/runefm.sh start ${CLUSTER} (code=exited, status=0/SUCCESS) Main PID: 58180 (java) - CGroup: /system.slice/edb-efm-4.8.service - └─58180 /usr/lib/jvm/java-11-openjdk-11.0.20.0.8-1.el7_9.x86_64/bin/java -cp /usr/edb/efm-4.8/lib/EFM-4.8.jar -Xmx128m... + CGroup: /system.slice/edb-efm-4.9.service + └─58180 /usr/lib/jvm/java-11-openjdk-11.0.20.0.8-1.el7_9.x86_64/bin/java -cp /usr/edb/efm-4.9/lib/EFM-4.9.jar -Xmx128m... ``` diff --git a/product_docs/docs/efm/4/10_notifications.mdx b/product_docs/docs/efm/4/10_notifications.mdx index 8443f5efb5a..a4c0c430211 100644 --- a/product_docs/docs/efm/4/10_notifications.mdx +++ b/product_docs/docs/efm/4/10_notifications.mdx @@ -154,6 +154,7 @@ The conditions listed in this table trigger a SEVERE notification: | primary_or_standby database failure for cluster *cluster_name* | The database has failed on the specified node. | | Agent is timing out for cluster *cluster_name* | This agent has timed out trying to reach the local database. After the timeout, the agent successfully pinged the database and resumed monitoring. However, check the node to make sure it is performing normally to prevent a possible database or agent failure. | | Resume timed out for cluster *cluster_name* | This agent couldn't resume monitoring after reconfiguring and restarting the local database. See agent log for details. | +| A duplicate replication slot name is in use for cluster *cluster_name* | A standby in the cluster is using the same physical replication slot name as the primary database: *slot_name*. This is unsupported and will result in the slot not being created on the standby that uses the same name. The original primary will not be able to follow this standby if it is promoted. | | Internal state mismatch for cluster *cluster_name* | The Failover Manager cluster's internal state didn't match the actual state of the cluster members. This is rare and can be caused by a timing issue of nodes joining the cluster or changing their state. The problem should be resolved, but you check the cluster status as well to verify. Details of the mismatch can be found in the agent log file. | | Failover has not occurred | An agent has detected that the primary database is no longer available in cluster *cluster_name*, but there are no standby nodes available for failover. | | Failover has not occurred | An agent has detected that the primary database is no longer available in cluster *cluster_name*, but there are not enough standby nodes available for failover. | diff --git a/product_docs/docs/efm/4/efm_quick_start/index.mdx b/product_docs/docs/efm/4/efm_quick_start/index.mdx index c24397aa822..7efe031df38 100644 --- a/product_docs/docs/efm/4/efm_quick_start/index.mdx +++ b/product_docs/docs/efm/4/efm_quick_start/index.mdx @@ -21,7 +21,7 @@ Using EDB Postgres Advanced Server as an example (Failover Manager also works wi - Install Failover Manager on each primary and standby node. During EDB Postgres Advanced Server installation, you configured an EDB repository on each database host. You can use the EDB repository and the `yum install` command to install Failover Manager on each node of the cluster: ```shell - yum install edb-efm48 + yum install edb-efm49 ``` During the installation process, the installer creates a user named efm that has privileges to invoke scripts that control the Failover Manager service for clusters owned by enterprisedb or postgres. The example that follows creates a cluster named `efm`. @@ -31,7 +31,7 @@ Start the configuration process on a primary or standby node. Then, copy the con 1. Create working configuration files. Copy the provided sample files to create Failover Manager configuration files, and correct the ownership and version number if you are installing a different version: ```shell - cd /etc/edb/efm-4.8 + cd /etc/edb/efm-4.9 cp efm.properties.in efm.properties @@ -45,7 +45,7 @@ Start the configuration process on a primary or standby node. Then, copy the con 1. Create an [encrypted password](/efm/latest/04_configuring_efm/02_encrypting_database_password/) needed for the properties file: ```shell - /usr/edb/efm-4.8/bin/efm encrypt efm + /usr/edb/efm-4.9/bin/efm encrypt efm ``` Follow the onscreen instructions to produce the encrypted version of your database password. @@ -83,22 +83,22 @@ Start the configuration process on a primary or standby node. Then, copy the con The Failover Manager agent doesn't validate the addresses in the `efm.nodes` file. The agent expects that some of the addresses in the file can't be reached (for example, that another agent hasn’t been started yet). -1. Configure the other nodes. Copy the `efm.properties` and `efm.nodes` files to `/etc/edb/efm-4.8` on the other nodes in your sample cluster. After copying the files, change the file ownership so the files are owned by efm:efm. The `efm.properties` file can be the same on every node, except for the following properties: +1. Configure the other nodes. Copy the `efm.properties` and `efm.nodes` files to `/etc/edb/efm-4.9` on the other nodes in your sample cluster. After copying the files, change the file ownership so the files are owned by efm:efm. The `efm.properties` file can be the same on every node, except for the following properties: - Modify the `bind.address` property to use the node’s local address. - Set `is.witness` to `true` if the node is a witness node. If the node is a witness node, the properties relating to a local database installation are ignored. -1. Start the Failover Manager cluster. On any node, start the Failover Manager agent. The agent is named `edb-efm-4.8`; you can use your platform-specific service command to control the service. For example, on a RHEL 7.x or Rocky Linux/AlmaLinux/RHEL 8.x host, use the command: +1. Start the Failover Manager cluster. On any node, start the Failover Manager agent. The agent is named `edb-efm-4.9`; you can use your platform-specific service command to control the service. For example, on a RHEL 7.x or Rocky Linux/AlmaLinux/RHEL 8.x host, use the command: ```shell - systemctl start edb-efm-4.8 + systemctl start edb-efm-4.9 ``` 1. After the agent starts, run the following command to see the status of the single-node cluster. The addresses of the other nodes appear in the `Allowed node host` list. ```shell - /usr/edb/efm-4.8/bin/efm cluster-status efm + /usr/edb/efm-4.9/bin/efm cluster-status efm ``` 1. Start the agent on the other nodes. Run the `efm cluster-status efm` command on any node to see the cluster status. @@ -106,7 +106,7 @@ Start the configuration process on a primary or standby node. Then, copy the con If any agent fails to start, see the startup log for information about what went wrong: ```shell - cat /var/log/efm-4.8/startup-efm.log + cat /var/log/efm-4.9/startup-efm.log ``` ## Perform a switchover @@ -114,7 +114,7 @@ Start the configuration process on a primary or standby node. Then, copy the con If the cluster status output shows that the primary and standby nodes are in sync, you can perform a switchover: ```shell - /usr/edb/efm-4.8/bin/efm promote efm -switchover + /usr/edb/efm-4.9/bin/efm promote efm -switchover ``` The command promotes a standby and reconfigures the primary database as a new standby in the cluster. To switch back, run the command again. @@ -124,5 +124,5 @@ The command promotes a standby and reconfigures the primary database as a new st For quick access to online help, use: ```shell -/usr/edb/efm-4.8/bin/efm --help +/usr/edb/efm-4.9/bin/efm --help ``` diff --git a/product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx b/product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx new file mode 100644 index 00000000000..27b9acf9452 --- /dev/null +++ b/product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx @@ -0,0 +1,11 @@ +--- +title: "Version 4.9" +--- + +Enhancements, bug fixes, and other changes in EFM 4.9 include: + +| Type | Description | +| ---- |------------ | +| Enhancement | Failover Manager has been upgraded to use PostgreSQL JDBC Driver version 42.7.2. | +| Bug Fix | Handle a rare case of a thread being interrupted while stopping the primary database during a switchover. [Support ticket: #102362] | +| Bug Fix | Fixed an issue with improper property settings that could prevent the startup process from exiting. | diff --git a/product_docs/docs/efm/4/efm_rel_notes/index.mdx b/product_docs/docs/efm/4/efm_rel_notes/index.mdx index 47785741f2c..860b99c63b5 100644 --- a/product_docs/docs/efm/4/efm_rel_notes/index.mdx +++ b/product_docs/docs/efm/4/efm_rel_notes/index.mdx @@ -9,6 +9,7 @@ about the release that introduced the feature. | Version | Release Date | | ------- | ------------ | +| [4.9](01_efm_49_rel_notes) | 14 May 2024| | [4.8](02_efm_48_rel_notes) | 15 Nov 2023| | [4.7](03_efm_47_rel_notes) | 20 Jun 2023| | [4.6](04_efm_46_rel_notes) | 14 Feb 2023| diff --git a/product_docs/docs/efm/4/installing/prerequisites.mdx b/product_docs/docs/efm/4/installing/prerequisites.mdx index 1a66e3d626c..cafbcadd217 100644 --- a/product_docs/docs/efm/4/installing/prerequisites.mdx +++ b/product_docs/docs/efm/4/installing/prerequisites.mdx @@ -37,9 +37,7 @@ If an event occurs, Failover Manager invokes the script (if provided) and can al Failover Manager requires that PostgreSQL streaming replication be configured between the primary node and the standby nodes. Failover Manager doesn't support other types of replication. -On database versions 11 or earlier, unless specified with the `-sourcenode` option, a `recovery.conf` file is copied from a random standby node to the stopped primary during switchover. Ensure that the paths in the `recovery.conf` file on your standby nodes are consistent before performing a switchover. For more information about the `-sourcenode` option, see [Promoting a Failover Manager node](../05_using_efm/#promote_node). - -On database version 12 or later, the `primary_conninfo` and `restore_command` properties are copied from a random standby node to the stopped primary during switchover unless otherwise specified with the `-sourcenode` option. +The `primary_conninfo` and `restore_command` properties are copied from a random standby node to the stopped primary during switchover unless otherwise specified with the `-sourcenode` option. ## Modify pg_hba.conf @@ -96,9 +94,7 @@ The database user specified by the `db.user` property in the `efm.properties` fi `pg_wal_replay_pause()` -If the `reconfigure.num.sync` or `reconfigure.sync.primary` property is set to `true`, then: - -- For database versions 11 and later, the db.user requires `pg_read_all_stats` privilege and permissions to run `pg_reload_conf()`. +If the `reconfigure.num.sync` or `reconfigure.sync.primary` property is set to `true`, then the db.user requires `pg_read_all_stats` privilege and permissions to run `pg_reload_conf()`. For detailed information about each of these functions, see the [PostgreSQL core documentation](https://www.postgresql.org/docs/current/index.html). diff --git a/product_docs/docs/efm/4/upgrading.mdx b/product_docs/docs/efm/4/upgrading.mdx index 0448aad80a9..f890e574564 100644 --- a/product_docs/docs/efm/4/upgrading.mdx +++ b/product_docs/docs/efm/4/upgrading.mdx @@ -14,37 +14,37 @@ legacyRedirectsGenerated: Failover Manager provides a utility to assist you when upgrading a cluster managed by Failover Manager. To upgrade an existing cluster, you must: -1. Install Failover Manager 4.8 on each node of the cluster. For detailed information about installing Failover Manager, see [Installing Failover Manager](installing). +1. Install Failover Manager 4.9 on each node of the cluster. For detailed information about installing Failover Manager, see [Installing Failover Manager](installing). -2. After installing Failover Manager, invoke the efm upgrade-conf utility to create the `.properties` and `.nodes` files for Failover Manager 4.8. The Failover Manager installer installs the upgrade utility ([efm upgrade-conf](07_using_efm_utility/#efm_upgrade_conf)) to the `/usr/edb/efm-4.8/bin` directory. To invoke the utility, assume root privileges, and invoke the command: +2. After installing Failover Manager, invoke the efm upgrade-conf utility to create the `.properties` and `.nodes` files for Failover Manager 4.9. The Failover Manager installer installs the upgrade utility ([efm upgrade-conf](07_using_efm_utility/#efm_upgrade_conf)) to the `/usr/edb/efm-4.9/bin` directory. To invoke the utility, assume root privileges, and invoke the command: ```shell efm upgrade-conf ``` - The `efm upgrade-conf` utility locates the `.properties` and `.nodes` files of preexisting clusters and copies the parameter values to a new configuration file for use by Failover Manager. The utility saves the updated copy of the configuration files in the `/etc/edb/efm-4.8` directory. + The `efm upgrade-conf` utility locates the `.properties` and `.nodes` files of preexisting clusters and copies the parameter values to a new configuration file for use by Failover Manager. The utility saves the updated copy of the configuration files in the `/etc/edb/efm-4.9` directory. -3. Modify the `.properties` and `.nodes` files for Failover Manager 4.8, specifying any new preferences. Use your choice of editor to modify any additional properties in the properties file (located in the `/etc/edb/efm-4.8` directory) before starting the service for that node. For detailed information about property settings, see [The cluster properties file](04_configuring_efm/01_cluster_properties/#cluster_properties). +3. Modify the `.properties` and `.nodes` files for Failover Manager 4.9, specifying any new preferences. Use your choice of editor to modify any additional properties in the properties file (located in the `/etc/edb/efm-4.9` directory) before starting the service for that node. For detailed information about property settings, see [The cluster properties file](04_configuring_efm/01_cluster_properties/#cluster_properties). 4. If you're using Eager Failover, you must disable it before stopping the Failover Manager cluster. For more information, see [Disabling Eager Failover](04_configuring_efm/06_configuring_for_eager_failover/#disabling-eager-failover). -5. Use a version-specific command to stop the old Failover Manager cluster. For example, you can use the following command to stop a version 4.7 cluster: +5. Use a version-specific command to stop the old Failover Manager cluster. For example, you can use the following command to stop a version 4.8 cluster: ```shell - /usr/efm-4.7/bin/efm stop-cluster efm + /usr/efm-4.8/bin/efm stop-cluster efm ``` !!! Note The primary agent doesn't drop the virtual IP address (if used) when it's stopped. The database remains up and accessible on the VIP during the EFM upgrade. See also [Using Failover Manager with virtual IP addresses](04_configuring_efm/05_using_vip_addresses.mdx). -6. Start the new [Failover Manager service](08_controlling_efm_service/#controlling_efm_service) (`edb-efm-4.8`) on each node of the cluster. +6. Start the new [Failover Manager service](08_controlling_efm_service/#controlling_efm_service) (`edb-efm-4.9`) on each node of the cluster. The following example shows invoking the upgrade utility to create the `.properties` and `.nodes` files for a Failover Manager installation: ```text -[root@hostname ~]# /usr/edb/efm-4.8/bin/efm upgrade-conf efm -Checking directory /etc/edb/efm-4.7 +[root@hostname ~]# /usr/edb/efm-4.9/bin/efm upgrade-conf efm +Checking directory /etc/edb/efm-4.8 Processing efm.properties file -Checking directory /etc/edb/efm-4.7 +Checking directory /etc/edb/efm-4.8 Processing efm.nodes file Upgrade of files is finished. The owner and group for properties and nodes files have been set as 'efm'. @@ -73,35 +73,35 @@ Summary: !!! Note If you are using custom scripts, check to see if they are calling any Failover Manager scripts. For example, a script that runs after promotion to perform various tasks and then calls Failover Manager's `efm_address` script to acquire a virtual IP address. If you have any custom scripts calling Failover Manager scripts, update the custom scripts to use the newly installed version of the Failover Manager script before uninstalling the older version of the Failover Manager script. -After upgrading to Failover Manager 4.8, you can use your native package manager to remove previous installations of Failover Manager. For example, use the following command to remove Failover Manager 4.7 and any unneeded dependencies: +After upgrading to Failover Manager 4.9, you can use your native package manager to remove previous installations of Failover Manager. For example, use the following command to remove Failover Manager 4.8 and any unneeded dependencies: - On RHEL or CentOS 7.x: ```shell -yum remove edb-efm47 +yum remove edb-efm48 ``` - On RHEL or Rocky Linux or AlmaLinux 8.x: ```shell -dnf remove edb-efm47 +dnf remove edb-efm48 ``` - On Debian or Ubuntu: ```shell -apt-get remove edb-efm47 +apt-get remove edb-efm48 ``` - On SLES: ```shell -zypper remove edb-efm47 +zypper remove edb-efm48 ``` ## Performing a maintenance task -You can perform maintenance activities such as an OS patch or a minor database version upgrade. You can upgrade from one minor version to another (for example, from 10.1.5 to version 10.2.7) or apply a patch release for a version. +You can perform maintenance activities such as an OS patch or a minor database version upgrade. You can upgrade from one minor version to another (for example, from 15.5.0 to version 15.6.0) or apply a patch release for a version. First, update the database server on each standby node of the Failover Manager cluster. Then, perform a switchover, promoting a standby node to the role of primary in the Failover Manager cluster. Then, perform a database update on the old primary node.