If I understood various sources correctly, there is currently no healthchecks for old processes remaining from a process rollover.
While the workaround of
hard-stop-after n
may be suited to wait a little and hard-stop the remaining connections, would not not be useful to have an optional setting to explicitly enabled healthchecks for old processes and couple that with
on-marked-down shutdown-sessions
where long running connections would remain on the old process,fully health-checked, but when the state of the backend changes, they would get actually cleanly stopped (idle clients would immediately know that the connection is ended).
The use-case I am thinking of is where the backends are using a healthcheck to designate for example the leader of a cluster who can write
frontend write
mode tcp
use_backend write
backend write
option httpchk GET /read-write
http-check expect status 200
server db1 10.0.0.1:5433 maxconn 100 check port 8000
server db2 10.0.0.2:5433 maxconn 100 check port 8000
In the above example, db1 or db2 will be the leader depending on their http services response on port 8000. The other will be DOWN.
But that status might change after some time. If a process rollover happened in the meanwhile, the old process(es) will not see the UP/DOWN change and not act on it, sending write workload to a then-read node.
Feel free to roast me if this is a stupid idea or suggest alternatives.