Go to main content

Oracle® Solaris Cluster Data Service for PostgreSQL Guide

Exit Print View

Updated: June 2017
 
 

Planning the HA for PostgreSQL Installation and Configuration

This section contains the information you need to plan your HA for PostgreSQL installation and configuration.

PostgreSQL and Oracle Solaris Zones

HA for PostgreSQL is supported in a cluster of Oracle Solaris zones, known as an Oracle Solaris Cluster zone cluster, and in the Oracle Solaris Cluster data service for Oracle Solaris Zones (HA for Solaris Zones). HA for Solaris Zones are managed by the Oracle Solaris Zones agent, and are represented by a resource of a resource group.

PostgreSQL WAL Shipping

The PostgreSQL agent offers three options for a cluster configuration. In these three options, two options leverage the Write Ahead Log (WAL) file shipping features and require the installation of the PostgreSQL pg_standby utility. The various options for cluster configuration are the following:

  • Traditional HA configuration with shared storage. In this configuration, you have a cluster with an active PostgreSQL resource, where the database directories reside on a cluster file system or on a highly available local file system, also called a failover file system.

  • WAL file shipping between two PostgreSQL failover resources. In this configuration, you have two independent PostgreSQL resources in a cluster or in different clusters. One of the resources acts as a primary server and obtains the client requests. The other resource acts as a standby server applying the PostgreSQL WAL files shipped from the primary server.

  • WAL file shipping without shared storage. This configuration does not require shared storage. The PostgreSQL WAL file shipping replaces the shared storage. This configuration consists of three resource groups. In two single-node resource groups, one resource group contains the designated primary database resource. The other resource group contains the designated standby database resource. The third resource group contains a logical host and a Rolechanger resource. This Rolechanger resource is responsible for transforming the designated standby into an acting primary on a node outage of the designated primary.

Configuration Restrictions

The configuration restrictions in the subsections that follow apply only to HA for PostgreSQL.


Caution

Caution  -  Your data service configuration might not be supported if you do not observe these restrictions.


Restriction for the Location of the Database Cluster

The PostgreSQL database cluster is where the database files and the configuration files are stored. The database cluster, represented by the configuration variable PGDATA, needs to be placed on the shared storage.

Restriction for the Listening Policy of the PostgreSQL Database Server

HA for PostgreSQL requires that the PostgreSQL listens at the localhost. Otherwise the monitoring of your data service will not work. For more information, see Preparing Your PostgreSQL Installation for Cluster Control.

Restriction for the PostgreSQL postgresql.conf File

The postgresql.conf file is one of the central configuration files for a specific PostgreSQL database cluster.

The postgresql.conf file must be stored in the PGDATA path. You cannot register HA for PostgreSQL if the file postgresql.conf is not in the directory referenced in the PGDATA variable. The other configuration files can be kept elsewhere. For more information about registration, see Registering and Configuring HA for PostgreSQL.

Restriction for the Password Policy for the HA for PostgreSQL Monitoring Database

HA for PostgreSQL requires a database to which it can connect and where it can manipulate a table for monitoring purposes. The password policy of this database for access from the localhost must be either trust or password. All other password policies can be whatever is applicable. For more information about setting the password policy, see Registering and Configuring HA for PostgreSQL. For more information about the password policy, go to http://www.postgresql.org.

Restriction for the PostgreSQL smf Service Name in an HA for Solaris Zones Configuration

The PostgreSQL configuration in an HA for Solaris Zones configuration uses the smf component of Oracle Solaris Cluster HA for Solaris Zones. The registration of the HA for PostgreSQL data service in an HA for Solaris Zones configuration defines an smf service to control the PostgreSQL database. The name of this smf service is generated in this naming scheme: svc:/application/sczone-agents:resource-name. No other smf service with exactly this name can exist.

The associated smf manifest is automatically created during the registration process in this location and naming scheme: /var/svc/manifest/application/sczone-agents/resource-name.xml. No other manifest can coexist with this name.

Restriction for the PostgreSQL WAL File Shipping Without Shared Storage

The pg_standby utility must be configured with a trigger file after a failover from the primary to the standby triggering a role conversion. An automatic failback cannot occur because the old primary is now out of synchronization. To invoke an actual copy, the PostgreSQL user needs to copy, customize, and execute the two example scripts :resilver-step1 and resilver-step2.

To minimize the data loss on a planned failover, you should switch the PostgreSQL transaction logs before you perform the failover. For information about switching transaction logs, see http://www.postgresql.org/.


Note -  The PostgreSQL WAL file Shipping without shared storage configuration cannot be deployed with non-global zones managed by the HA for Solaris Zones agent.

Configuration Requirements

The configuration requirements in this section apply only to HA for PostgreSQL.


Caution

Caution  -  If your data service configuration does not conform to these requirements, the data service configuration might not be supported.


Dependencies Between HA for PostgreSQL Components

The dependencies between the HA for PostgreSQL components are described in the following table.

Table 2  Dependencies Between HA for PostgreSQL Components
Component
Dependency
PostgreSQL resource in the global zone or in a zone cluster
SUNW.HAStoragePlus – This dependency is required only if the configuration uses a highly available local file system, or failover file system. It is a resource_offline_restart_dependency.
SUNW.LogicalHostname
PostgreSQL resource in an HA for Solaris Zones configuration
Oracle Solaris Cluster HA for Solaris Zones boot resource.
SUNW.HAStoragePlus – This dependency is a resource_offline_restart_dependency.
SUNW.LogicalHostname – This dependency is required only if the zones boot resource does not manage the zone's IP address.

You set these dependencies, when you register and configure HA for PostgreSQL. For more information, see Registering and Configuring HA for PostgreSQL.

If more elaborate dependencies are required, see the r_properties(5) and rg_properties(5) man pages for further dependencies and affinities settings.

Parameter File for HA for PostgreSQL

HA for PostgreSQL requires a parameter file to pass configuration information to the data service. You must create a directory for this file. Because the directory must be available on each node that is to host the PostgreSQL database, place the directory on the shared storage. If HA for PostgreSQL is configured for an HA for Solaris Zones configuration, this file must be available in this zone. The parameter file is created automatically when the resource is registered. Although it is possible to store the password for database monitoring in clear text in the parameter file, you must not do it due to security risks. Instead of storing the password in clear text in the parameter file, encrypt the password using the register script.

Configuration Requirements for the WAL File Shipping Without Shared Storage Configuration

For the WAL file shipping without shared storage configuration, the rsync utility is required. As an additional requirement, you need to link some PostgreSQL configuration files outside the PGDATA directory. Otherwise these files are destroyed during the resilvering of the primary database. Information about how to perform these steps is available in the comments of the resilver1 script. The PostgreSQL users on both nodes require a nonpassword login on each node.