From 559f740910f1eefc73b9dc82e5ca01a76e040b8f Mon Sep 17 00:00:00 2001 From: Guillaume Lefranc Date: Fri, 9 Sep 2016 14:34:13 +0200 Subject: [PATCH 1/8] Clarify detect_stale_master defaults --- Documentation/Monitors/MySQL-Monitor.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/Monitors/MySQL-Monitor.md b/Documentation/Monitors/MySQL-Monitor.md index 808c1703d..e0941b561 100644 --- a/Documentation/Monitors/MySQL-Monitor.md +++ b/Documentation/Monitors/MySQL-Monitor.md @@ -55,7 +55,8 @@ and the table if they do not exist. Allow previous master to be available even in case of stopped or misconfigured replication. -This feature is enabled by default. +Starting from MaxScale 2.0.0 this feature is enabled by default. It is disabled +by default in MaxScale 1.4.3 and below. This allows services that depend on master and slave roles to continue functioning as long as the master server is available. This is a situation From f161c1e423382a1d270b862ff3e710984c42b133 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Fri, 9 Sep 2016 15:53:21 +0300 Subject: [PATCH 2/8] Add section about changed defaults to release notes A list of changes in the defaults is good to have in the release notes. --- Documentation/Getting-Started/Configuration-Guide.md | 8 ++++---- .../Release-Notes/MaxScale-2.0.1-Release-Notes.md | 12 ++++++++++++ 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/Documentation/Getting-Started/Configuration-Guide.md b/Documentation/Getting-Started/Configuration-Guide.md index 8cd7c211a..5aa7a18d2 100644 --- a/Documentation/Getting-Started/Configuration-Guide.md +++ b/Documentation/Getting-Started/Configuration-Guide.md @@ -12,7 +12,7 @@ The purpose of this document is to describe how to configure MariaDB MaxScale an * [Server](#server) * [Server and SSL](#server-and-ssl) * [Listener](#listener) - * [Listener and SSL](#listener-and-ssl) + * [Listener and SSL](#listener-and-ssl) * [Router Modules](#routing-modules) * [Diagnostic Modules](#diagnostic-modules) * [Monitor Modules](#monitor-modules) @@ -662,7 +662,7 @@ For more information about persistent connections, please read the [Administrati ### Server and SSL -This section describes configuration parameters for servers that control the SSL/TLS encryption method and the various certificate files involved in it when applied to back end servers. To enable SSL between MaxScale and a back end server, you must configure the `ssl` parameter in the relevant server section to the value `required` and provide the three files for `ssl_cert`, `ssl_key` and `ssl_ca_cert`. After this, MaxScale connections to this server will be encrypted with SSL. Attempts to connect to the server without using SSL will cause failures. Hence, the database server in question must have been configured to be able to accept SSL connections. +This section describes configuration parameters for servers that control the SSL/TLS encryption method and the various certificate files involved in it when applied to back end servers. To enable SSL between MaxScale and a back end server, you must configure the `ssl` parameter in the relevant server section to the value `required` and provide the three files for `ssl_cert`, `ssl_key` and `ssl_ca_cert`. After this, MaxScale connections to this server will be encrypted with SSL. Attempts to connect to the server without using SSL will cause failures. Hence, the database server in question must have been configured to be able to accept SSL connections. #### `ssl` @@ -686,7 +686,7 @@ This parameter controls the level of encryption used. Accepted values are: * TLSv10 * TLSv11 * TLSv12 - * MAX + * MAX Not all backend servers will support TLSv11 or TLSv12. If available, TLSv12 should be used. @@ -805,7 +805,7 @@ This parameter controls the level of encryption used. Accepted values are: * TLSv10 * TLSv11 * TLSv12 - * MAX + * MAX If possible, use TLSv12 for best security. Recent Linux systems will include a version of OpenSSL that supports TLS version 1.2. Only if you are using MaxScale on a system that does not have OpenSSL with support for this should earlier versions be used. It is unlikely that TLS 1.1 will be available unless TLS 1.2 is also available. MAX will use the best available version. diff --git a/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md index 8746eeda7..c8336a16e 100644 --- a/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md +++ b/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md @@ -11,6 +11,18 @@ of [2.0.0](./MaxScale-2.0.0-Release-Notes.md). For any problems you encounter, please consider submitting a bug report at [Jira](https://jira.mariadb.org). +## Changed default values + +### `strip_db_esc` + +The service parameter [_strip_db_esc_](../Getting-Started/Configuration-Guide.md#strip_db_esc) +now defaults to true. + +### `detect_stale_master` + +The [stale master detection](../Monitors/MySQL-Monitor.md#detect_stale_master) +feature is now enabled by default. + ## Updated Features ### Starting MariaDB MaxScale From 4a95439a8dfd3f55be45c06e5e5994a6c6c2037f Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Fri, 9 Sep 2016 16:38:27 +0300 Subject: [PATCH 3/8] Don't restart even on abnormal failures If systemd restarts MaxScale when an abnormal exit is detected, it is likely to happen again. This leads into a loop which causes multiple maxscale processes on the same machine. One example of this behavior is when systemd times MaxScale out when it is starting. --- etc/maxscale.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/maxscale.service.in b/etc/maxscale.service.in index 0ebeaeaab..982cbc00b 100644 --- a/etc/maxscale.service.in +++ b/etc/maxscale.service.in @@ -4,7 +4,7 @@ After=network.target [Service] Type=forking -Restart=on-abnormal +Restart=no PIDFile=@MAXSCALE_VARDIR@/run/maxscale/maxscale.pid ExecStartPre=/usr/bin/install -d @MAXSCALE_VARDIR@/run/maxscale -o maxscale -g maxscale ExecStart=@CMAKE_INSTALL_PREFIX@/@MAXSCALE_BINDIR@/maxscale --user=maxscale From 7a144079b9a38e016bc7ca1fd6bc6ddfec935b52 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Thu, 8 Sep 2016 15:56:48 +0300 Subject: [PATCH 4/8] MXS-812: Fix active operation counters When a client executes commands which do not return results (for example inserting BLOB data via the C API), readwritesplit expects a result for each sent packet. This is a somewhat of a false assumption but it clears itself out when the session is closed normally. If the session is closed due to an error, the counter is not decremented. Each sesssion should only increase the number of active operation on a server by one operation. By checking that the session is not already executing an operation before incrementing the active operation count the runtime operation count will be correct. --- .../routing/readwritesplit/readwritesplit.c | 24 ++++++++++--------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/server/modules/routing/readwritesplit/readwritesplit.c b/server/modules/routing/readwritesplit/readwritesplit.c index 0c980a631..f6a60f788 100644 --- a/server/modules/routing/readwritesplit/readwritesplit.c +++ b/server/modules/routing/readwritesplit/readwritesplit.c @@ -942,7 +942,7 @@ static void closeSession(ROUTER *instance, void *router_session) } #endif /** Clean operation counter in bref and in SERVER */ - while (BREF_IS_WAITING_RESULT(bref)) + if (BREF_IS_WAITING_RESULT(bref)) { bref_clear_state(bref, BREF_WAITING_RESULT); } @@ -955,6 +955,10 @@ static void closeSession(ROUTER *instance, void *router_session) /** decrease server current connection counters */ atomic_add(&bref->bref_backend->backend_conn_count, -1); } + else + { + ss_dassert(!BREF_IS_WAITING_RESULT(bref)); + } } /** Unlock */ rses_end_locked_router_action(router_cli_ses); @@ -2796,11 +2800,8 @@ static void bref_clear_state(backend_ref_t *bref, bref_state_t state) MXS_ERROR("[%s] Error: NULL parameter.", __FUNCTION__); return; } - if (state != BREF_WAITING_RESULT) - { - bref->bref_state &= ~state; - } - else + + if ((state & BREF_WAITING_RESULT) && (bref->bref_state & BREF_WAITING_RESULT)) { int prev1; int prev2; @@ -2825,6 +2826,8 @@ static void bref_clear_state(backend_ref_t *bref, bref_state_t state) } } } + + bref->bref_state &= ~state; } static void bref_set_state(backend_ref_t *bref, bref_state_t state) @@ -2834,11 +2837,8 @@ static void bref_set_state(backend_ref_t *bref, bref_state_t state) MXS_ERROR("[%s] Error: NULL parameter.", __FUNCTION__); return; } - if (state != BREF_WAITING_RESULT) - { - bref->bref_state |= state; - } - else + + if ((state & BREF_WAITING_RESULT) && (bref->bref_state & BREF_WAITING_RESULT) == 0) { int prev1; int prev2; @@ -2864,6 +2864,8 @@ static void bref_set_state(backend_ref_t *bref, bref_state_t state) bref->bref_backend->backend_server->port); } } + + bref->bref_state |= state; } /** From 76ea31bc2d742f1d95ac08fb8ae00c1b2effef8b Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Fri, 9 Sep 2016 17:02:41 +0300 Subject: [PATCH 5/8] Add MXS-812 to release notes MXS-812 is now mentioned in the 2.0.1 release notes. --- Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md index c8336a16e..fe6675efc 100644 --- a/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md +++ b/Documentation/Release-Notes/MaxScale-2.0.1-Release-Notes.md @@ -115,6 +115,7 @@ Please consult [Here is a list of bugs fixed since the release of MaxScale 2.0.1.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20in%20(2.0.0%2C%202.0.1)%20AND%20resolved%20%3E%3D%20-21d%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC) +* [MXS-812](https://jira.mariadb.org/browse/MXS-812): Number of conns not matching number of operations * [MXS-847](https://jira.mariadb.org/browse/MXS-847): server_down event is executed 8 times due to putting sever into maintenance mode * [MXS-845](https://jira.mariadb.org/browse/MXS-845): "Server down" event is re-triggered after maintenance mode is repeated * [MXS-842](https://jira.mariadb.org/browse/MXS-842): Unexpected / undocumented behaviour when multiple available masters from mmmon monitor From 717b623587278a31ac0d6a1937c469e009bde5bf Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Fri, 9 Sep 2016 20:39:16 +0300 Subject: [PATCH 6/8] Fix crash in server_free server_free tried to free a char array which wasn't malloc'ed. --- server/core/server.c | 1 - 1 file changed, 1 deletion(-) diff --git a/server/core/server.c b/server/core/server.c index 4de4e4d64..c4ef6426b 100644 --- a/server/core/server.c +++ b/server/core/server.c @@ -135,7 +135,6 @@ server_free(SERVER *tofreeserver) free(tofreeserver->protocol); free(tofreeserver->unique_name); free(tofreeserver->server_string); - free(tofreeserver->slaves); server_parameter_free(tofreeserver->parameters); if (tofreeserver->persistent) From e26f3795e29058b0dd466dce1fad884ee3377074 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Sun, 11 Sep 2016 20:37:50 +0300 Subject: [PATCH 7/8] Remove useless parts from CHK_LOGFILE The CHK_LOGFILE macro first asserts that the values being checked are valid and then proceeds to evaluate it again. The result of this evaluation was not assigned to anything and it caused GCC 6.1.1 to produce a warning. --- utils/skygw_debug.h | 8 -------- 1 file changed, 8 deletions(-) diff --git a/utils/skygw_debug.h b/utils/skygw_debug.h index dd0ce10c4..15aa1b352 100644 --- a/utils/skygw_debug.h +++ b/utils/skygw_debug.h @@ -405,14 +405,6 @@ typedef enum skygw_chk_t lf->lf_name_suffix != NULL && \ lf->lf_full_file_name != NULL, \ "NULL in name variable\n"); \ - ss_debug( \ - (lf->lf_chk_top != CHK_NUM_LOGFILE || \ - lf->lf_chk_tail != CHK_NUM_LOGFILE ? \ - false : \ - (lf->lf_filepath == NULL || \ - lf->lf_name_prefix == NULL || \ - lf->lf_name_suffix == NULL || \ - lf->lf_full_file_name == NULL ? false : true));) \ } #define CHK_FILEWRITER(fwr) { \ From 8be833640f7938dd4542e7ed9da2f74935c3e045 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Mon, 12 Sep 2016 09:35:11 +0300 Subject: [PATCH 8/8] Change restart type to on-abort MaxScale should only restart if an abort is detects, i.e. MaxScale crashes. --- etc/maxscale.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/etc/maxscale.service.in b/etc/maxscale.service.in index 982cbc00b..84b76bcc3 100644 --- a/etc/maxscale.service.in +++ b/etc/maxscale.service.in @@ -4,7 +4,7 @@ After=network.target [Service] Type=forking -Restart=no +Restart=on-abort PIDFile=@MAXSCALE_VARDIR@/run/maxscale/maxscale.pid ExecStartPre=/usr/bin/install -d @MAXSCALE_VARDIR@/run/maxscale -o maxscale -g maxscale ExecStart=@CMAKE_INSTALL_PREFIX@/@MAXSCALE_BINDIR@/maxscale --user=maxscale