This chapter includes the following sections:

PSQL is compatible with numerous solutions that maximize uptime in physical and virtual environments. Such solutions continually evolve but can be classified generally as high availability, fault tolerance, and disaster recovery.

The definition of high availability can differ depending on the software vendor that provides high availability solutions. In general, it refers to a systems design approach for a predictable baseline level of uptime, despite hardware failure, software failure, or required maintenance.

A common approach to ensure high availability in a physical environment is failover clustering. A common approach in a virtual machine (VM) environment is migration.

PSQL is designed to function as a resource in a failover cluster environment in which only one server node at a time accesses the shared storage subsystem. If the primary node fails, a failover (or switch) to a secondary node occurs. Failover clustering allows a system to remain available while you perform software upgrades or hardware maintenance.

PSQL is compatible with Microsoft Failover Cluster Services and with Linux Heartbeat. Refer to the documentation from those vendors for the specific manner in which they define and implement failover clustering. PSQL Server and PSQL Vx Server are the recommended editions for failover clustering.

See Failover Clustering.

In general terms, migration allows a running VM or application to be moved between different physical machines without disconnecting the client or application. The memory, storage, and network connectivity of the VM are typically migrated to the destination.

PSQL is compatible with the migration capability offered by Microsoft Hyper-V, VMware vSphere, and Citrix XenServer. As long as host names remain the same after the VMs are moved, PSQL continues to operate normally. Refer to the documentation from those vendors for the specific manner in which they define and implement migration.

See Migration.

While high availability aims for a predictable baseline level of uptime, fault tolerance is the uninterrupted operation of a system even after the failure of a component. Fault tolerance requires synchronized shared storage. In virtualized environments, the VM that fails must be on a different physical host from the VM that replaces it.

Fault tolerance can be achieved using just physical machines. However, virtual environments lend themselves so readily to maintaining virtual servers in lockstep with each other that exclusively physical environments are increasingly less common. PSQL Server is compatible with fault tolerance capabilities in an exclusively physical environment.

For virtual environments, PSQL is compatible with the fault tolerance capability offered by VMware vSphere and Citrix XenServer. Refer to the documentation from those vendors for the specific manner in which they define and implement fault tolerance.

See Fault Tolerance.

Disaster recovery involves duplicating computer operations after a catastrophe occurs and typically includes routine off-site data backup as well as a procedure for activating vital information systems in a new location.

PSQL is compatible with major hypervisors that support disaster recovery technology that initializes backup physical or virtual machines. As long as all host names remain the same after the VMs are moved, PSQL continues to operate normally. This allows rapid server replacement and recovery time.

Refer to the documentation from the hypervisor vendors for the specific manner in which they define and implement disaster recovery.

See Disaster Recovery.

For all of the technologies mentioned in this section, we recommend that you select servers, disk subsystems, and network components from the hardware compatibility list provided by the vendor. We follow this same practice when testing for compatibility with vendor products.

Failover clustering provides for multiple physical servers (nodes) to access a common, shared storage subsystem that contains one or more file shares or volumes. The failover services ensure that only one server controls the file shares or volumes at a time. Control of the shared storage subsystem is passed automatically from a failed server to the next active server in the cluster.

The PSQL engine must be licensed separately on each cluster node where you install it, whether the node is a physical or a virtual machine. See also License Models in PSQL User's Guide. The failover clustering being discussed refers to Microsoft Failover Clustering or Cluster Service and to Linux Heartbeat. This is distinct from other high availability solutions that may incorporate VM-based clusters.

This section contain the following topics:

This topic discusses adding the PSQL services to Failover Clustering and assumes the following:

You must assure that failover clustering functions correctly before you add PSQL services. For example, verify that the failover completes and that all resources are available. Complete the action again and fail over back to the original node. See the Microsoft documentation for how to set up Failover Clustering, verify that it is working correctly, and perform tasks through its interface.

The following table explains the recommended process to add PSQL to Cluster Services on Windows Server.

Your PSQL failover cluster is now configured.

The Heartbeat program is one of the core components of the Linux-HA (High-Availability Linux) project. Heartbeat runs on all Linux platforms and performs death-of-node detection, communications and cluster management in one process.

This topic discusses adding the PSQL services to Linux Heartbeat and assumes the following:

It is essential that Linux Heartbeat be functioning correctly before you add PSQL to the cluster. See the documentation from the High Availability Linux Project (www.linux-ha.org) for how to install Heartbeat, verify that it is working correctly, and perform tasks with it.

Just as you would for any application, set up the essential clustering components before you add PSQL.

The following table explains the recommended process to add PSQL to Linux Heartbeat.

After you install PSQL in a failover cluster environment, you can manage it as a resource. The following items discuss common management topics:

The normal PSQL licensing and machine maintenance procedures also apply to the nodes in a failover cluster environment. Deauthorize the PSQL key before you modify the configuration of the physical or virtual machine where the database engine is installed. Reauthorize the key after changes are complete.

See To Deauthorize a Key and To Authorize a Key in PSQL User's Guide.

If a cluster node fails, a PSQL client does not automatically reconnect to the PSQL engine on the surviving node. Your application must reconnect the client to the PSQL database or you must restart the application. This applies even if Enable Auto Reconnect is turned on for the database engine.

If transaction durability is turned off and a failure occurs before a transaction completes, the transaction is automatically rolled back to its state before the transaction began. That is, to the last completed check point. The rollback occurs when the active server requests access to the data file.

If transaction durability was turned on, completed changes can be recovered that occurred between the time of the cluster node failure and the last check point. Transaction durability must be configured the same way on all nodes and the transaction log located on the shared storage. Transactions that had not completed at the time of the cluster failure, however, are lost even if transaction durability was in effect.

A cluster failover occurs from the active node if you manually stop the PSQL transactional service through the operating system. If you are performing service node maintenance and want to avoid such a failover, stop the PSQL transactional service through the cluster utilities.

Some configuration changes require that you restart the database engine. See Configuration Reference.

Use the following steps in the Windows Cluster Administrator. You must do them in the order listed.

At some point, you may need to patch PSQL or the failover cluster software. To help you do so, Actian Technical Support provides a knowledge base article on this topic.

Migration moves a VM running PSQL from one physical host to another. The memory, storage, and network connectivity of the VM are typically migrated to the destination. Depending on the hypervisor, migration is sometimes referred to as “live” migration or “hot” migration.

With a “live” or “hot” migration, client connections to PSQL remain intact. This allows changes to hardware or resource balancing. With a “cold” migration, network connectivity is interrupted because the VM must boot. Client connections to PSQL must be reestablished.

A migration environment has only one instance of PSQL running, which makes the environment somewhat vulnerable if the host machines crashes or must be quickly taken offline. Also, if the shared storage fails, the database engine cannot process reads from or writes to physical storage. Some hypervisors offer a migration solution that does not use shared storage.

As long as host names remain the same after the VM migrates, PSQL continues to operate normally. The product key remains in the active state.

No special steps are required to install or configure PSQL in a migration environment. Refer to the hypervisor documentation.

A fault tolerant environment is similar to a migration environment but includes additional features to ensure uninterrupted operation even after the failure of a component. A fault tolerant environment ensures network connections, continuous service, and data access through synchronized shared storage. If a component switch occurs, client machines and applications continue to function normally with no database engine interruption.

No special steps are required to install or configure PSQL in a fault tolerant environment. Refer to the hypervisor documentation.

Disaster recovery includes data recovery and site recovery. Data recovery is how you protect and restore your data. Site recovery is how you protect and restore your entire site, including your data.

Data recovery is facilitated with the hypervisor shared storage and PSQL transaction logging and transaction durability. See Transaction Logging and Durability. You can use transaction logging and transaction durability with PSQL Server and Vx Server.

Site recovery can be accomplished with both physical machines and virtual machines. PSQL operates normally provided that host names remain the same in the recovered site. This is typically the case for virtual machines. If you are recovering physical machines and the host name at the recovery site is different, the PSQL product keys will change to the failed validation state when PSQL starts. PSQL will continue to operate normally in the failed validation state for several days, during which you can either repair the key or move back to the original site.

No special steps are required to install or configure PSQL in a disaster recovery environment. Refer to the hypervisor documentation.