hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enable connection_keepalive by default

Browse Source 
Enabling the feature by default prevents the master connection from dying
during times when there are very little or no writes. Having a modest ping
interval of 300 seconds serves to minimize the amount of extra work that
both MaxScale and the server have to do while still keeping the
connections in good shape.
This commit is contained in:
Markus Mäkelä 2018-11-23 09:28:59 +02:00
parent b47d4a4105
commit dcf53da209
No known key found for this signature in database
GPG Key ID: 72D48FCE664F7B19
3 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/Release-Notes/MaxScale-2.3.2-Release-Notes.md
View File

@ -16,6 +16,14 @@ The systemd watchdog is now safe to use in all circumstances.
By default it is enabled with a timeout of 60 seconds.
### Readwritesplit
#### `connection_keepalive`
The default value of `connection_keepalive` is now 300 seconds. This prevents
the connections from dying due to wait_timeout with longer sessions. This is
especially helpful with pooled connections that stay alive for a very long time.
## Bug fixes
## Known Issues and Limitations

6
Documentation/Routers/ReadWriteSplit.md
View File

@ -92,7 +92,8 @@ master_failure_mode=fail_on_write
### `connection_keepalive`
Send keepalive pings to backend servers. This feature was introduced in MaxScale
2.2.0 and is disabled by default.
2.2.0. The default value is 300 seconds starting with 2.3.2 and for older
versions the feature was disabled by default.
The parameter value is the interval in seconds between each keepalive ping. A
keepalive ping will be sent to a backend server if the connection is idle and it
@ -103,7 +104,8 @@ client executes a query.
This functionality allows the readwritesplit module to keep all backend
connections alive even if they are not used. This is a common problem if the
backend servers have a low _wait_timeout_ value and the client connections live
for a long time.
for a long time or if your workload is extremely read-heavy with writes done at
lower intervals than the configured _wait_timeout_.
### `master_reconnection`

2
server/modules/routing/readwritesplit/readwritesplit.cc
View File

@ -503,7 +503,7 @@ extern "C" MXS_MODULE* MXS_CREATE_MODULE()
{"strict_multi_stmt", MXS_MODULE_PARAM_BOOL, "false" },
{"strict_sp_calls", MXS_MODULE_PARAM_BOOL, "false" },
{"master_accept_reads", MXS_MODULE_PARAM_BOOL, "false" },
{"connection_keepalive", MXS_MODULE_PARAM_COUNT, "0" },
{"connection_keepalive", MXS_MODULE_PARAM_COUNT, "300" },
{"causal_reads", MXS_MODULE_PARAM_BOOL, "false" },
{"causal_reads_timeout", MXS_MODULE_PARAM_STRING, "10" },
{"master_reconnection", MXS_MODULE_PARAM_BOOL, "false" },