Installation

A standard installation of HARP includes two system services:

• HARP Manager (harp_manager) on the node being managed

• HARP Proxy (harp_router) elsewhere

There are generally two ways to install and configure these services to managePostgres for proper Quorum-based connection routing.

Software Versions

HARP does have dependencies on external software. These must fit a minimumversion as listed here.

Software	Min Ver
etcd	3.4
PgBouncer	1.14

TPAExec

The easiest way to install and configure HARP is to use EDB’s TPAexec utilityfor cluster deployment and management. For details on this software, see theTPAexec product page.

!!! Note * TPAExec is currently only available through an EULA specifically dedicated to BDR cluster deployments. If you are unable to access the above URL, please contact your sales or account representative for more information.

TPAexec itself must be configured to recognize that cluster routing should bemanaged through HARP by ensuring the TPA config.yml file contains theseattributes:

cluster_vars:
   * failover_manager: harp

!!! Note * Versions of TPAexec prior to 21.1 require a slightly different approach:

*   cluster_vars:
*     enable_harp: true

After this, HARP will be installed by invoking the regular tpaexec commandsfor making cluster modifications:

tpaexec provision ${CLUSTER_DIR}
tpaexec deploy ${CLUSTER_DIR}

No other modifications should be necessary, barring cluster-specificconsiderations.

Package Installation

Currently CentOS/RHEL packages are provided via the EDB packaginginfrastructure. For details, see the HARP productpage.

etcd Packages

Currently etcd packages for many popular Linux distributions are not available via their standard public repositories. EDB has therefore packaged etcd for RHEL and CentOS versions 7 and 8, Debian, and variants such as Ubuntu LTS. Again, access to our HARP package repository is necessary to usethese libraries.

Consensus layer

HARP requires a distributed consensus layer to operate. Currently this must beeither bdr or etcd. If using fewer than 3 BDR nodes, it may becomenecessary to rely on etcd. Otherwise any BDR service outage will reduce theconsensus layer to a single node and thus prevent node consensus and disablePostgres routing.

etcd

If using etcd as the consensus layer, etcd must be installed eitherdirectly on the Postgres nodes, or in some separate location they can access.

To set etcd as the consensus layer, include this in the HARP config.ymlconfiguration file:

dcs:
   * driver: etcd
   * endpoints:
   *   - host1:2379
   *   - host2:2379
   *   - host3:2379

When using TPAExec, all configured etcd endpoints will be entered here automatically.

BDR

The bdr native consensus layer is available from BDR 3.6.21 and 3.7.3. This Consensus Layer model requires no supplementary software when managing routing for a BDR cluster.

As previously mentioned, to ensure Quorum is possible in the cluster, alwaysuse more than two nodes so BDR’s consensus layer remains responsive during nodemaintenance or outages.

To set BDR as the consensus layer, include this in the config.yml configuration file:

dcs:
   * driver: bdr
   * endpoints:
   *   - host=host1 dbname=bdrdb user=harp_user
   *   - host=host2 dbname=bdrdb user=harp_user
   *   - host=host3 dbname=bdrdb user=harp_user

As can be seen here, the endpoints for a BDR consensus layer follow thestandard Postgres DSN connection format.