Configuration basics
Reloads
This section applies to:
- HAProxy 3.1 and newer
- HAProxy Enterprise 3.1 and newer
- HAProxy ALOHA 17.0 and newer
Earlier product versions support the reload operation, but they don’t use the same master-worker no-impact model described in this section. As a result, earlier versions may drop connections during reloads.
Use the reload operation to apply configuration file changes to the load balancer.
When you change, add, or remove files such as the load balancer configuration file, map files, cert files, WAF rules, and so on, you need to reload the load balancer to apply the changes. The changes don’t take effect until you perform the reload.
When the load balancer performs a reload, it applies configuration changes immediately without interrupting existing connections. The load balancer can support graceful, no-impact reloads because of its master-worker architecture.
Master-worker architecture Jump to heading
When the load balancer starts, it starts a master process and a worker process.
- The master manages the worker process, and it also manages reloads. It doesn’t consume load balancer configuration files, and it doesn’t process load balancer application traffic.
- The worker handles validation of the configuration and execution of the load balancer application as it processes traffic.
Reload process Jump to heading
When you issue a reload command for the load balancer, the master designates the current worker as the leaving worker, and it starts a new worker to replace it. So for a brief period of time, there are two workers processing traffic.
- The leaving worker no longer receives new connections because the listening sockets for the load balancer are transferred from the leaving worker to the new worker during the reload. The leaving worker’s existing connections are allowed to continue uninterrupted. When the last connection closes, the master process terminates the leaving worker.
- The new worker initializes itself using files from persistent storage: load balancer configuration file, map files, certs, WAF rules files, and so on. Any changes you have made to these files are now in effect. The new worker binds to the listening sockets and receives all new incoming connections.
With the two workers overlapping in this way, configuration changes are brought online without interrupting existing connections or impacting performance.
Dynamic changes Jump to heading
Dynamic changes are configuration changes made to the load balancer process running in memory. These changes, applied using the HAProxy Runtime API, aren’t written to disk and don’t persist through a load balancer reload or restart. When the process terminates, the dynamic changes are lost.
If you made dynamic changes to the leaving worker process and need to recreate them in the new worker process, you must repeat the changes either as dynamic changes or as persistent disk changes. To make dynamic changes, use the HAProxy Runtime API. To make changes to the configuration file on disk, edit the files directly or use HAProxy Data Plane API; then reload the load balancer.
If you use HAProxy Fusion Control Plane:
When you change the configuration using the HAProxy Fusion Control Plane UI or API, the changes are written to the configuration on disk and persist through load balancer reloads and restarts. Changes made using the HAProxy Fusion Control Plane UI or API aren’t considered dynamic changes.
Persistent statistics Jump to heading
If you use the HAProxy statistics module, you can configure it to persist statistics across a reload or restart. See Statistics tutorial.
Initiate a reload Jump to heading
There are several ways to initiate a reload.
On a load balancer node, you can use the systemctl command:
nixsudo systemctl reload hapee-3.3-lb
nixsudo systemctl reload hapee-3.3-lb
Another way to perform a reload on a load balancer node is to use the HAProxy Runtime API master CLI reload command:
nixecho "reload" | \sudo socat stdio /run/hapee-lb-master.sock
nixecho "reload" | \sudo socat stdio /run/hapee-lb-master.sock
On HAProxy Fusion Control Plane, you don’t need to perform a reload after changing the configuration because HAProxy Fusion performs the reload for you, pushing the changed configuration to all nodes in the cluster. Still, you can trigger a reload manually on the Nodes page:
- Go to Infrastructure > Nodes.
- Select the desired load balancer nodes.
- Set Set action to
Reload. - Set On service to
Haproxy. - Click Apply action.
On HAProxy ALOHA, to reload the HAProxy (LB Layer7) service, go to the Services tab:
- Go to the Services tab.
- Reload the haproxy service.
See also Jump to heading
- To change a load balancer configuration in memory, use the HAProxy Runtime API.
- To send debugging commands to a running HAProxy master or worker process, use the HAProxy Runtime API master CLI.
- To change a load balancer configuration programmatically and persist changes to the configuration file, see HAProxy Data Plane API.
- To persist statistics across a load balancer reload or restart, see Statistics tutorial.