About peers
It is possible to propagate entries of any data-types in stick-tables between several haproxy instances over TCP connections in a multi-master fashion. Each instance pushes its local updates and insertions to remote peers. The pushed values overwrite the remote ones without aggregation. Interrupted exchanges are automatically detected and recovered from the last known point. In addition, during a soft restart, the old process connects to the new one using a TCP connection to push all its entries before the new process tries to connect to other peers. This ensures very fast replication when reloading, it typically takes a fraction of a second even for large tables. Note that Server IDs are used to identify servers remotely, so it is important that the configurations look similar or at least that the same IDs are forced on each server on all participants.
How to create peers via Roxy-WI
With Roxy-WI you can easily add peers via the graphical interface. To add a peer, select HAProxy => Add proxy in the main menu. Click on the Peers button. The form that you will see is intuitive:
In the dropdown-menu select a server for which you would like to create a peer:
Enter the name of the peers section and set the peer definitions (the name of each peer server as well as the address and the port on which each server will listen):
Click on the Add peer button. The peer will be created. If you need to get the peers section for the configuration file represented according to the syntax requirements for HAProxy config files, click on the Generate config button. The following window will open:
Create stick-table
Peers are commonly used in setups that utilize HAProxy in active-active clusters or share your stick-tables between master-slave servers, where a new connection from a client may end up at one of multiple HAProxy servers (for instance, when using Amazon Elastic Load Balancer). All stick table entries can be stored on one server, but on the other server the set of entries can be quite different. You can add a peers section in order to solve this problem.
Change your stick table definition to include a peers argument:
The exchange of sticky table entries between the two servers will take place. The problem is that the two servers will not sum their individual counters, so http_req_rate on one server will overwrite the value on the other; the sum will not be available for both servers.
