You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be possible to perform zero-downtime upgrades for setups with clustering configured to use >1 worker. Essentially, the process would be:
Admin sends e.g. SIGUSR1 to the pump master process
A cluster worker is selected by the master process and told to shut down
The worker stops accepting new connections and finalizes current connections (note this may be tricky because WebSockets)
Worker shuts down
Master process starts a new worker as normal
Repeat from step 2, selecting a different cluster worker until all workers have upgraded
Potential problems here:
This leaves the master process out-of-date, but we don't update it that often. Will this be a problem? Can we possibly exec() a new master process?
How do we deal with semver-major upgrades? This should work if there's only config changes but database migrations will be sticky. Seems like we could just document whether each release was compatible with the zero-downtime feature?
The text was updated successfully, but these errors were encountered:
It may be possible to perform zero-downtime upgrades for setups with clustering configured to use >1 worker. Essentially, the process would be:
SIGUSR1
to the pump master processPotential problems here:
exec()
a new master process?The text was updated successfully, but these errors were encountered: