Upgrading PostgreSQL

During an upgrade from a previous version of the SPS for Linux PostgreSQL software, the upgrade will make modifications to the existing SPS PostgreSQL resource instance. When the SPS software is updated on the server, the following stored values will be added to the internal SPS information field automatically.

• Client Executable Location (psql) – the location of the psql or equivalent client utility used for connecting to the protected database instance. After an upgrade, this value can be verified from the LifeKeeper GUI properties display. The value can also be verified from the LifeKeeper command line using the set_value utility.
  
  set_value is the name of a LifeKeeper utility provided for the LifeKeeper PostgreSQL Recovery Kit to update the internal resource information field values. The use of this utility should be limited to issues explained in this topic or at the request and instruction of the SIOS Technology Corp. Support team.

Note: The set_value utility does not perform rigorous error checking and therefore is not intended for general use.

• Administration Executable Location (pg_ctl) – the location of the pg_ctl or equivalent administration utility used for starting, stopping and checking the status of the protected database instance. After an upgrade, this value can be verified from the LifeKeeper GUI properties display. The value can also be verified from the LifeKeeper command line using the set_value utility.

• PostgreSQL Database Administrator User – the PostgreSQL Database Administrator User for the LifeKeeper protected instance. This user must have connection and administrator privileges for the protected database instance. The default value used following an upgrade is the PostgreSQL Operating System User that owns the PostgreSQL data directory. After an upgrade, this value can be verified from the LifeKeeper GUI properties display. The value can also be verified from the LifeKeeper command line using the set_value utility.

• PostgreSQL Daemon Name (postmaster) – the name of the running backend daemon. This value is determined during the first status check of the database instance. The default value is postmaster. After an upgrade, this value can be verified from the LifeKeeper GUI properties display. The value can also be verified from the LifeKeeper command line using the set_value utility.

• Default Test Database (template1) – the database used by LifeKeeper during the database instance monitoring to verify basic connectivity. After an upgrade, the default test database will be set to template1.

• PostgreSQL Maximum Monitoring Hangs (LKPGSQL_QCKHANG_MAX) – the setting that provides protection against an unlimited number of connection hangs before a restorative or reparative failover action is initiated. A portion of PosgreSQL Recovery Kit’s monitoring requires a connection to the protected database. The number of connection hangs allowed is determined during resource creation by the setting LKPGSQL_QCKHANG_MAX. The default value previous to version 8.1.2 was 15. After upgrading to version 8.1.2 (or later), the default value is 2. Since this value is stored with the resource at create time, any resources created prior to upgrading to version 8.1.2 will remain at the default value of 15 unless updated by the user while any resources created after upgrading to 8.1.2 (or later) will contain a default value of 2. The value can also be verified from the SPS command line using the set_value utility.

*IMPORTANT NOTE: Following the upgrade of the SPS for Linux PostgreSQL Recovery Kit software, you should test your PostgreSQL resource hierarchy by initiating a manual switchover that will simulate a failover of the resource instance from the primary server to a backup server.

Important Upgrade Considerations

If a resource does not come into service following the upgrade, check the following conditions:

• Client Executable name is not found or incorrect
  

The value can be updated using the set_value utility. The syntax for the Client Executable update is as follows:

/opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value <tag> ‘clientexe’ <full path to the psql utility>.

Example: /opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value pgsql-5443 ‘clientexe’ ‘/pgsql/clientutils/psql’.

• Administration Executable name is not found or incorrect

The value can be updated using the set_value utility. The syntax for the Administration Executable update is as follows:

/opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value <tag> ‘osexe’ <full path to the pg_ctl utility>.

Example: /opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value pgsql-5443 ‘osexe’ ‘/pgsql/adminutils/pg_ctl’.

Lowering the interval for recovering from multiple hang events (LKPGSQL_QCKHANG_MAX)

• Maximum Monitoring Hangs value is too large in versions prior to 8.1.2

The value for Maximum Monitoring Hangs for existing PostgreSQL resource instances can viewed or set using the set_value utility.

The syntax for setting the value for the Maximum Monitoring Hangs (LKPGSQL_QCKHANG_MAX) is as follows:

/opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value <tag> ‘hangmax’ <number>.

Example: /opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value pgsql-5443 ‘hangmax’ 3.

Note: Include the -c argument to update the value on all nodes in the cluster (set_value -c <tag>…).

The syntax for viewing the value is as follows:

/opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value -l <tag> ‘hangmax’

Example:/opt/LifeKeeper/lkadm/subsys/database/pgsql/bin/set_value -l pgsql-5443 ‘hangmax’