Motivation: Hot Reloading
When updating Vitess services, it is necessary to shift traffic from the old process to the new process. In some cases, it may be convenient and advantageous to do so without requiring a traffic shift to a different host:port for the new version, but instead to migrate the version in place on the same host or container.
Proposal
Add an option for ports to be bound with SO_REUSEPORT on unix builds of Vitess. SO_REUSEPORT is a unix socket option which allows multiple processes running under the same UID to bind the same port at the same time. The kernel then load balances traffic between all processes listening on the port. This option can be utilized by users who want to update Vitess binaries in place without service interruption, or to hot-reload configuration.
WIP implementation
Alternative
Alternatively, create a new top level attribute, servenv.Listen with the type func Listen(network, address string) (net.Listener, error), and then replace calls to net.Listen with servenv.Listen. Users could override this attribute with a custom implementation. This would allow users to inject their own OS/config-specific socket binding functions, while keeping the Vitess repo minimal.
Alternative implementation
Use Case(s)
At Slack, we run a VTGate-like sidecar daemon along side a web application via systemd. We would like to be able to configure our web applications with a static host/port (eg. localhost:3306) and then perform sidecar updates in-place without service disruption.
Motivation: Hot Reloading
When updating Vitess services, it is necessary to shift traffic from the old process to the new process. In some cases, it may be convenient and advantageous to do so without requiring a traffic shift to a different host:port for the new version, but instead to migrate the version in place on the same host or container.
Proposal
Add an option for ports to be bound with
SO_REUSEPORTon unix builds of Vitess.SO_REUSEPORTis a unix socket option which allows multiple processes running under the same UID to bind the same port at the same time. The kernel then load balances traffic between all processes listening on the port. This option can be utilized by users who want to update Vitess binaries in place without service interruption, or to hot-reload configuration.WIP implementation
Alternative
Alternatively, create a new top level attribute,
servenv.Listenwith the typefunc Listen(network, address string) (net.Listener, error), and then replace calls tonet.Listenwithservenv.Listen. Users could override this attribute with a custom implementation. This would allow users to inject their own OS/config-specific socket binding functions, while keeping the Vitess repo minimal.Alternative implementation
Use Case(s)
At Slack, we run a VTGate-like sidecar daemon along side a web application via systemd. We would like to be able to configure our web applications with a static host/port (eg.
localhost:3306) and then perform sidecar updates in-place without service disruption.