peers section enables the replication of stick table data between two or more HAProxy Enterprise instances.
peers mycluster # peers list
This feature works well for one-way replication of data because when the data replicates to the peer, it overwrites existing data on that peer. This makes it ideal for an active-standby cluster where the active instance pushes data to the standby instance.
In an active-active cluster where both instances receive traffic, use the Stick Table Aggregator module to combine the data captured by all nodes in the cluster.
Add one or more
peer lines to your
peers section. Each one identifies an instance that takes part in the synchronization. One of the
peer lines must be the local host:
peers mycluster # local host, active instance peer
loadbalancer1192.168.1.10:10000 # standby instance peer loadbalancer2192.168.1.11:10000
Then, add a
peers attribute to your
stick-table directive to include that stick table in the synchronization. The attribute references the name of the
peers section you defined:
backend stick-table type ip size 1m expire 10s store http_req_rate(10s) peers mycluster
The names assigned to each
peer (e.g. loadbalancer1) must match that server's hostname so that HAProxy Enterprise can determine which peer is the local host. You must duplicate this configuration on each load balancer so the new active node can synchronize data in the opposite direction using the same list of hosts in the event of a failover.
Persist data at reload
A useful side effect of using a
peers section is that HAProxy Enterprise will persist stick table data after a reload. This is because during a reload the old process connects to the new one and shares all of its stick table entries with it.
To use this feature only, you can define a
peers section with only the local host address:
peers mycluster peer
Without this, stick table data is lost during a reload.