Configuring HARP for cluster management

The HARP configuration file follows a standard YAML-style formatting that was simplified for readability. This file is located in the /etc/harp directory by default and is named config.yml

You can explicitly provide the configuration file location to all HARP executables by using the -f /--config argument.

Standard configuration

HARP essentially operates as three components:

  • HARP Manager

  • HARP Proxy

  • harpctl

Each of these use the same standard config.yml configuration format, which always include the following sections:

  • cluster.name — The name of the cluster to target for all operations.

  • dcs — DCS driver and connection configuration for all endpoints.

This means a standard preamble is always included for HARP operations, such as the following:

cluster:
  name: mycluster

dcs:
  ...

Other sections are optional or specific to the named HARP component.

Cluster name

The name entry under the cluster heading is required for all interaction with HARP. Each HARP cluster has a name for both disambiguation and for labeling data in the DCS for the specific cluster.

HARP Manager writes information about the cluster here for consumption by HARP Proxy and harpctl. HARP Proxy services direct traffic to nodes in this cluster. The harpctl management tool interacts with this cluster.

DCS settings

Configuring the consensus layer is key to HARP functionality. Without the DCS, HARP has nowhere to store cluster metadata, can’t hold leadership elections, and so on. Therefore this portion of the configuration is required, and certain elements are optional.

Specify all elements under a section named dcs with these multiple supplementary entries:

  • ``driver`` : Required type of consensus layer to use. Currently can be etcd or bdr . Support for bdr as a consensus layer is experimental. Using bdr as the consensus layer reduces the additional software for consensus storage but expects a minimum of three full BDR member nodes to maintain quorum during database maintenance.

  • ``endpoints`` : Required list of connection strings to contact the DCS. List every node of the DCS here if possible. This ensures HARP continues to function as long as a majority of the DCS can still operate and be reached by the network.

Format when using etcd as the consensus layer is as follows: edb_notranlate_1 Format when using the experimental bdr consensus layer is as follows: edb_notranlate_2 Currently, bdr consensus layer requires the first endpoint to point to the local postgres instance.

  • ``request_timeout`` : Time in milliseconds to consider a request as failed. If HARP makes a request to the DCS and receives no response in this time, it considers the operation as failed. This can cause the issue to be logged as an error or retried, depending on the nature of the request. Default: 250.

The following DCS SSL settings apply only when edb_notranlate_3 yaml dcs: driver: etcd endpoints: - host1:2379 - host2:2379 - host3:2379 edb_notranlate_4 yaml cluster: name: mycluster

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

manager: name: node1 log_level: INFO edb_notranlate_5 yaml cluster: name: mycluster

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

proxy: name: proxy1 location: dc1 pgbouncer_bin_dir: /usr/sbin edb_notranlate_6 bash harpctl set node node1 lease_refresh_interval=100 edb_notranlate_7 bash harpctl set proxy global max_client_conn=1000 ```