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
We would like to add a new feature to allow for all the MySQL protocol connections to be drained when terminating VTGate. The drain would wait until all the idle connections have disconnected (or the timeout expires, whichever happens first). When the server goes into OnTerm state, new connections will stop being accepted. A load balancer used in front of vtgate should now connect new application sessions to other vtgates. Once all the idle connections have drained, the vtgate will exit.
Note that for this scheme to be practical, the application client to vtgate should refresh it's MySQL connections periodically; a period of something like 45-60 minutes is usually a good value, while not short enough to cause a lot of re-connection churn. If the vtgate drain timeout is set to an hour along with this, the "drain cycle" when shutting down a vtgate would then be something less than an hour, and not actually need to force-close any application MySQL connections, thus avoiding errors served to MySQL protocol clients. The "refresh" setting is often a feature of the MySQL client connector in use, e.g. in HikariCP the setting is called maxLifetime, and is set by default (to 30 minutes).
We would introduce a new flag for this feature to work and it is possibly a breaking change hence the RFC.
Description
We would like to add a new feature to allow for all the MySQL protocol connections to be drained when terminating VTGate. The drain would wait until all the idle connections have disconnected (or the timeout expires, whichever happens first). When the server goes into OnTerm state, new connections will stop being accepted. A load balancer used in front of vtgate should now connect new application sessions to other vtgates. Once all the idle connections have drained, the vtgate will exit.
Note that for this scheme to be practical, the application client to vtgate should refresh it's MySQL connections periodically; a period of something like 45-60 minutes is usually a good value, while not short enough to cause a lot of re-connection churn. If the vtgate drain timeout is set to an hour along with this, the "drain cycle" when shutting down a vtgate would then be something less than an hour, and not actually need to force-close any application MySQL connections, thus avoiding errors served to MySQL protocol clients. The "refresh" setting is often a feature of the MySQL client connector in use, e.g. in HikariCP the setting is called
maxLifetime
, and is set by default (to 30 minutes).We would introduce a new flag for this feature to work and it is possibly a breaking change hence the RFC.
Proposed changes
The text was updated successfully, but these errors were encountered: