From 8859a7672d1142e26b23939d212b3afc4361798b Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Thu, 11 Apr 2024 11:39:10 -0400 Subject: [PATCH 01/14] Updates for efm 4.9 release. Update base template for installation and regenerated files. --- install_template/templates/products/failover-manager/base.njk | 2 +- product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx | 2 +- product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx | 2 +- .../docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx | 2 +- .../docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx | 2 +- product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx | 2 +- product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx | 2 +- product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx | 2 +- product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx | 2 +- product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx | 2 +- 17 files changed, 17 insertions(+), 17 deletions(-) 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/installing/linux_ppc64le/efm_rhel_8.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx index 73698c9f337..dc1a4f244d4 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx @@ -53,7 +53,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_ppc64le/efm_rhel_9.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx index 2f75f8ccb87..194e9e26a8a 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx @@ -53,7 +53,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_ppc64le/efm_sles_12.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx index 67fa8557d3d..1ea1fe83fcf 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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/installing/linux_ppc64le/efm_sles_15.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx index 43e6394b9db..9e827bf42af 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx @@ -56,7 +56,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_centos_7.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx index 9472f94eaa7..691b286ce38 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo yum -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_debian_10.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx index d86249bbdb4..5d7e60ccf39 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_debian_11.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx index eb1906737de..bc2899d6491 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_other_linux_8.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx index 9534c0117f5..14ea1de2643 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_other_linux_9.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx index 97da1da2d48..c5ea91fc632 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_rhel_7.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx index 55d7002f8ed..6a20e227811 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo yum -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_rhel_8.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx index f548e1a3fbd..95ecadcb72c 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_rhel_9.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx index a6c425d18ac..a3f78e4a77c 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_sles_12.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx index 61d497d0277..f1b2c92dd5c 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_sles_15.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx index 15fe8add40a..e7c6e4fcaaa 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx @@ -56,7 +56,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_ubuntu_20.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx index 466474e2e48..333d5df84a3 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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/installing/linux_x86_64/efm_ubuntu_22.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx index ddc8b7e67c7..26e2a6176f1 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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. From 1a231a94b2e74f97c991f8a6733744b35241dffc Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Thu, 11 Apr 2024 11:39:25 -0400 Subject: [PATCH 02/14] Update upgrade instructions. --- product_docs/docs/efm/4/upgrading.mdx | 30 +++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/product_docs/docs/efm/4/upgrading.mdx b/product_docs/docs/efm/4/upgrading.mdx index 0448aad80a9..179ca7782ac 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,30 +73,30 @@ 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 From f4083be44062812f5e19fed20d9187af0e005c07 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Thu, 11 Apr 2024 14:12:31 -0400 Subject: [PATCH 03/14] Adding draft of release notes. Hopefully the only thing missing from this is the release date. --- .../docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx | 12 ++++++++++++ product_docs/docs/efm/4/efm_rel_notes/index.mdx | 1 + 2 files changed, 13 insertions(+) create mode 100644 product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx 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..e6a2e557972 --- /dev/null +++ b/product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx @@ -0,0 +1,12 @@ +--- +title: "Version 4.9" +--- + +Enhancements, bug fixes, and other changes in EFM 4.9 include: + +| Type | Description | +| ---- |------------ | +| Enhancement | The minimum database server version now supported is 12. | +| 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..dad64ff0f53 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) | TODO 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| From 3c03491964a44f25818b4864c74288f59586879f Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Mon, 15 Apr 2024 11:51:18 -0400 Subject: [PATCH 04/14] Removed extra whitespace. --- product_docs/docs/efm/4/efm_rel_notes/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 dad64ff0f53..7b2d912f498 100644 --- a/product_docs/docs/efm/4/efm_rel_notes/index.mdx +++ b/product_docs/docs/efm/4/efm_rel_notes/index.mdx @@ -9,7 +9,7 @@ about the release that introduced the feature. | Version | Release Date | | ------- | ------------ | -| [4.9](01_efm_49_rel_notes) | TODO May 2024| +| [4.9](01_efm_49_rel_notes) | TODO 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| From 7fef297309ed891fb3f91ee8498a1c6cc6a24e47 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Mon, 15 Apr 2024 11:51:54 -0400 Subject: [PATCH 05/14] The rest of the 4.8->4.9 changes. Also removed some text about startup information in systemctl status call. This info is in the startup log instead. --- .../01_cluster_properties.mdx | 2 +- .../02_encrypting_database_password.mdx | 14 ++++--------- .../04_configuring_efm/03_cluster_members.mdx | 2 +- .../04_extending_efm_permissions.mdx | 20 +++++++++---------- product_docs/docs/efm/4/05_using_efm.mdx | 10 +++++----- .../docs/efm/4/08_controlling_efm_service.mdx | 14 ++++++------- .../docs/efm/4/efm_quick_start/index.mdx | 20 +++++++++---------- 7 files changed, 38 insertions(+), 44 deletions(-) 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..5230e3692f2 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: 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..d05a2b40615 100644 --- a/product_docs/docs/efm/4/05_using_efm.mdx +++ b/product_docs/docs/efm/4/05_using_efm.mdx @@ -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/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 ``` From bd3db7f1b8958ed28361f26af4cf1cec64d09d4e Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Wed, 17 Apr 2024 10:44:50 -0400 Subject: [PATCH 06/14] Updates to efm properties file to remove recovery.conf information since we only support v12 and up with this release. --- .../01_cluster_properties.mdx | 42 ++++++++----------- 1 file changed, 17 insertions(+), 25 deletions(-) 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 5230e3692f2..ab81dca2179 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 @@ -227,18 +227,12 @@ 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. ```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. +# 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= ``` @@ -269,14 +263,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= ``` @@ -694,11 +687,10 @@ Use the `auto.reconfigure` property to instruct Failover Manager to enable or di ```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 From d1318902dc92a73d29725304694d2c4d955eba04 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Fri, 19 Apr 2024 10:43:23 -0400 Subject: [PATCH 07/14] Add new notification for EFM-1645. --- product_docs/docs/efm/4/10_notifications.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/product_docs/docs/efm/4/10_notifications.mdx b/product_docs/docs/efm/4/10_notifications.mdx index 8443f5efb5a..3901e5ef6c0 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: *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. | From ce240cf34ecbaa509bc4961576714f5a29228008 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Fri, 19 Apr 2024 10:46:09 -0400 Subject: [PATCH 08/14] "name" -> "slot_name" in new notification --- product_docs/docs/efm/4/10_notifications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/efm/4/10_notifications.mdx b/product_docs/docs/efm/4/10_notifications.mdx index 3901e5ef6c0..a4c0c430211 100644 --- a/product_docs/docs/efm/4/10_notifications.mdx +++ b/product_docs/docs/efm/4/10_notifications.mdx @@ -154,7 +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: *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. | +| 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. | From dae4ea4ba073cf88d1a75e01ec7ede773387a101 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Tue, 23 Apr 2024 12:01:15 -0400 Subject: [PATCH 09/14] Updated old database example versions. --- product_docs/docs/efm/4/upgrading.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/efm/4/upgrading.mdx b/product_docs/docs/efm/4/upgrading.mdx index 179ca7782ac..f890e574564 100644 --- a/product_docs/docs/efm/4/upgrading.mdx +++ b/product_docs/docs/efm/4/upgrading.mdx @@ -101,7 +101,7 @@ 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. From ddb6b863463013fd488d5b66c9af9761b185e133 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Tue, 23 Apr 2024 12:02:08 -0400 Subject: [PATCH 10/14] More changes to remove v11 references and make properties up to date with 4.9 release. Also removed duplicate db.data.dir entry from cluster properties page. --- .../01_cluster_properties.mdx | 37 ++++--------------- product_docs/docs/efm/4/05_using_efm.mdx | 8 ++-- .../docs/efm/4/installing/prerequisites.mdx | 8 +--- 3 files changed, 14 insertions(+), 39 deletions(-) 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 ab81dca2179..208d8865e27 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 @@ -228,35 +228,14 @@ Use the `db.data.dir` property to specify the location to write a recovery file ```ini # This is the directory where a standby.signal file will exist for a standby node. -# 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 +# 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= ``` - - - -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. -db.data.dir= -``` - Use the `db.config.dir` property to specify the location of database configuration files if they aren't stored in the same directory as the `recovery.conf` or `standby.signal` file. This is the value specified by the `config_file` parameter directory of your EDB Postgres Advanced Server or PostgreSQL installation. This value is used as the location of the EDB Postgres Advanced Server `data` directory when stopping, starting, or restarting the database. @@ -308,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= ``` @@ -577,7 +556,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. @@ -683,7 +662,7 @@ 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 diff --git a/product_docs/docs/efm/4/05_using_efm.mdx b/product_docs/docs/efm/4/05_using_efm.mdx index d05a2b40615..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. 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). From 18f5d66a88ff88b5cb59ef1fc6ad72128b9ad3e8 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Tue, 23 Apr 2024 14:06:35 -0400 Subject: [PATCH 11/14] Added May 14th for release date. --- product_docs/docs/efm/4/efm_rel_notes/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 7b2d912f498..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,7 +9,7 @@ about the release that introduced the feature. | Version | Release Date | | ------- | ------------ | -| [4.9](01_efm_49_rel_notes) | TODO May 2024| +| [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| From 735ec31aa59edf46c23beda988b29f9959201c10 Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Mon, 29 Apr 2024 17:04:15 -0400 Subject: [PATCH 12/14] Clear up text about recovery.conf files written on primary node. The property comments are really enough for this one. --- .../docs/efm/4/04_configuring_efm/01_cluster_properties.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 208d8865e27..ae1d05a3e70 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 @@ -224,7 +224,7 @@ 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 # This is the directory where a standby.signal file will exist for a standby node. From b87617c085145eb53238585b89c5f04686201b2b Mon Sep 17 00:00:00 2001 From: Bobby Bissett Date: Tue, 30 Apr 2024 14:45:53 -0400 Subject: [PATCH 13/14] Remove the db version support line This information changes over time as db versions go out of support. Users should check the platform compatibility page for the current supported db versions. --- product_docs/docs/efm/4/efm_rel_notes/01_efm_49_rel_notes.mdx | 1 - 1 file changed, 1 deletion(-) 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 index e6a2e557972..27b9acf9452 100644 --- 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 @@ -6,7 +6,6 @@ Enhancements, bug fixes, and other changes in EFM 4.9 include: | Type | Description | | ---- |------------ | -| Enhancement | The minimum database server version now supported is 12. | | 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. | From 339a5847fa5ff430be1ce1d0de2fa75fa2816bef Mon Sep 17 00:00:00 2001 From: gvasquezvargas Date: Wed, 15 May 2024 09:56:06 +0200 Subject: [PATCH 14/14] rolled back edits to templates and fixed a note --- .../4/04_configuring_efm/01_cluster_properties.mdx | 11 ++++++----- .../efm/4/installing/linux_ppc64le/efm_rhel_8.mdx | 2 +- .../efm/4/installing/linux_ppc64le/efm_rhel_9.mdx | 2 +- .../efm/4/installing/linux_ppc64le/efm_sles_12.mdx | 2 +- .../efm/4/installing/linux_ppc64le/efm_sles_15.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_centos_7.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_debian_10.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_debian_11.mdx | 2 +- .../4/installing/linux_x86_64/efm_other_linux_8.mdx | 2 +- .../4/installing/linux_x86_64/efm_other_linux_9.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx | 2 +- .../docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_sles_12.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_sles_15.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx | 2 +- .../efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx | 2 +- 17 files changed, 22 insertions(+), 21 deletions(-) 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 ae1d05a3e70..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 @@ -224,7 +224,7 @@ db.bin= -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. +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 # This is the directory where a standby.signal file will exist for a standby node. @@ -478,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. +!!! diff --git a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx index dc1a4f244d4..73698c9f337 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_8.mdx @@ -53,7 +53,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_ppc64le/efm_rhel_9.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx index 194e9e26a8a..2f75f8ccb87 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_rhel_9.mdx @@ -53,7 +53,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_ppc64le/efm_sles_12.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx index 1ea1fe83fcf..67fa8557d3d 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_12.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_ppc64le/efm_sles_15.mdx b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx index 9e827bf42af..43e6394b9db 100644 --- a/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx +++ b/product_docs/docs/efm/4/installing/linux_ppc64le/efm_sles_15.mdx @@ -56,7 +56,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_centos_7.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx index 691b286ce38..9472f94eaa7 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_centos_7.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo yum -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_debian_10.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx index 5d7e60ccf39..d86249bbdb4 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_10.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_debian_11.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx index bc2899d6491..eb1906737de 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_debian_11.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_other_linux_8.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx index 14ea1de2643..9534c0117f5 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_8.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_other_linux_9.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx index c5ea91fc632..97da1da2d48 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_other_linux_9.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_rhel_7.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx index 6a20e227811..55d7002f8ed 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_7.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo yum -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_rhel_8.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx index 95ecadcb72c..f548e1a3fbd 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_8.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_rhel_9.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx index a3f78e4a77c..a6c425d18ac 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_rhel_9.mdx @@ -49,7 +49,7 @@ Before you begin the installation process: sudo dnf -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_sles_12.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx index f1b2c92dd5c..61d497d0277 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_12.mdx @@ -55,7 +55,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_sles_15.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx index e7c6e4fcaaa..15fe8add40a 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_sles_15.mdx @@ -56,7 +56,7 @@ Before you begin the installation process: sudo zypper -n install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_ubuntu_20.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx index 333d5df84a3..466474e2e48 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_20.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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`. +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`. 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/installing/linux_x86_64/efm_ubuntu_22.mdx b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx index 26e2a6176f1..ddc8b7e67c7 100644 --- a/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx +++ b/product_docs/docs/efm/4/installing/linux_x86_64/efm_ubuntu_22.mdx @@ -44,7 +44,7 @@ Before you begin the installation process: sudo apt-get -y install edb-efm<4x> ``` -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`. +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`. 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.