From dc485f644d05e1c7f4cae66a124cb225b1f4a025 Mon Sep 17 00:00:00 2001 From: Betsy Gitelman <93718720+ebgitelman@users.noreply.github.com> Date: Thu, 12 Oct 2023 14:41:50 -0400 Subject: [PATCH] edits to non-generated install topics --- .../docs/efm/4/installing/install_details.mdx | 2 +- .../docs/efm/4/installing/prerequisites.mdx | 28 +++++++++---------- 2 files changed, 14 insertions(+), 16 deletions(-) diff --git a/product_docs/docs/efm/4/installing/install_details.mdx b/product_docs/docs/efm/4/installing/install_details.mdx index 26a96b0e319..325c623736d 100644 --- a/product_docs/docs/efm/4/installing/install_details.mdx +++ b/product_docs/docs/efm/4/installing/install_details.mdx @@ -6,7 +6,7 @@ redirects: -Components are installed in the following locations, where `4.x` indicates a minor release: +Components are installed in the following locations, where `4.x` indicates a minor release. | Component | Location | | --------------------------------- | ----------------------------- | diff --git a/product_docs/docs/efm/4/installing/prerequisites.mdx b/product_docs/docs/efm/4/installing/prerequisites.mdx index a4206bac8c0..a3846d706b0 100644 --- a/product_docs/docs/efm/4/installing/prerequisites.mdx +++ b/product_docs/docs/efm/4/installing/prerequisites.mdx @@ -11,11 +11,11 @@ legacyRedirectsGenerated: -Before configuring a Failover Manager cluster, you must satisfy the prerequisites described below. +Before configuring a Failover Manager cluster, you must satisfy these prerequisites. -## Install Java 1.8 (or later) +## Install Java 1.8 or later -Before using Failover Manager, you must first install Java (version 1.8 or later). Failover Manager is tested with OpenJDK, and we strongly recommend installing that version of Java. [Installation instructions for Java](https://openjdk.java.net/install/) are platform specific. +Before using Failover Manager, you must first install Java version 1.8 or later. Failover Manager is tested with OpenJDK, and we strongly recommend installing that version of Java. [Installation instructions for Java](https://openjdk.java.net/install/) are platform specific. !!! Note There's a temporary issue with OpenJDK version 11 on RHEL and its derivatives. When starting Failover Manager, you might see an error like the following: @@ -28,8 +28,8 @@ Before using Failover Manager, you must first install Java (version 1.8 or later You can receive notifications from Failover Manager as specified by a user-defined notification script, by email, or both. -- If you are using email notifications, an SMTP server must be running on each node of the Failover Manager scenario. -- If you provide a value in the `script.notification` property, you can leave the `user.email` field blank; an SMTP server is not required. +- If you're using email notifications, an SMTP server must be running on each node of the Failover Manager scenario. +- If you provide a value in the `script.notification` property, you can leave the `user.email` field blank. An SMTP server isn't required. If an event occurs, Failover Manager invokes the script (if provided) and can also send a notification email to any email addresses specified in the `user.email` parameter of the cluster properties file. For more information about using an SMTP server, see the [Red Hat deployment guide](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-email-mta.html). @@ -37,13 +37,13 @@ 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 prior), 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 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. ## Modify pg_hba.conf -You must modify `pg_hba.conf` on the primary and standby nodes, adding entries that allow communication between all of the nodes in the cluster. The following example shows entries you might make to the `pg_hba.conf` file on the primary node: +You must modify `pg_hba.conf` on the primary and standby nodes, adding entries that allow communication between all of the nodes in the cluster. This example shows entries you might make to the `pg_hba.conf` file on the primary node: ```shell # access for itself @@ -58,19 +58,19 @@ Where: `efm` specifies the name of a valid database user. - `fmdb` specifies the name of a database to which the efm user may connect. + `fmdb` specifies the name of a database to which the efm user can connect. -By default, the `pg_hba.conf` file resides in the `data` directory, under your Postgres installation. After modifying the `pg_hba.conf` file, you must reload the configuration file on each node for the changes to take effect. You can use the following command: +By default, the `pg_hba.conf` file resides in the `data` directory under your Postgres installation. After modifying the `pg_hba.conf` file, for the changes to take effect, you must reload the configuration file on each node. You can use the following command: `# systemctl reload edb-as-` Where `x` specifies the Postgres version. -## Using Autostart for the Database Servers +## Using autostart for the database servers -If a primary node reboots, Failover Manager might detect the database is down on the primary node and promote a standby node to the role of primary. If this happens, the Failover Manager agent on the rebooted primary node doesn't get a chance to write the `recovery.conf` file, and the `recovery.conf` file prevents the database server from starting. If this happens, the rebooted primary node returns to the cluster as a second primary node. +If a primary node restarts, Failover Manager might detect the database is down on the primary node and promote a standby node to the role of primary. If this happens, the Failover Manager agent on the restarted primary node doesn't get a chance to write the `recovery.conf` file, and the `recovery.conf` file prevents the database server from starting. In this case, the rebooted primary node returns to the cluster as a second primary node. -To prevent this condition, ensure that the Failover Manager agent auto starts before the database server. The agent starts in idle mode and checks to see if there is already a primary in the cluster. If there is a primary node, the agent verifies that a `recovery.conf` or `standby.signal` file exists. If neither file exits, the agent creates the `recovery.conf` file. +To prevent this condition, ensure that the Failover Manager agent auto starts before the database server. The agent starts in idle mode and checks to see if there's already a primary in the cluster. If there's a primary node, the agent verifies that a `recovery.conf` or `standby.signal` file exists. If neither file exits, the agent creates the `recovery.conf` file. ## Ensure communication through firewalls @@ -96,9 +96,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 10 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, for database versions 10 and later, 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).