From a3bbba0a3decb35d7a81ac524ff9bd6ce9bae887 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Wed, 3 Jul 2019 10:23:38 +0300 Subject: [PATCH 1/6] Update REST API ETag documentation The ETag docuemntation did not mention what sort of changes triggered ETag updates. --- Documentation/REST-API/API.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/REST-API/API.md b/Documentation/REST-API/API.md index ddb0e2aac..fc4ac0dd1 100644 --- a/Documentation/REST-API/API.md +++ b/Documentation/REST-API/API.md @@ -229,7 +229,9 @@ English and it uses the server's local timezone. #### ETag An identifier for a specific version of a resource. The value of this header -changes whenever a resource is modified. +changes whenever a resource is modified via the REST API. It will not change if +an internal MaxScale event (e.g. server changing state or statistics being +updated) causes a change. When the client sends the `If-Match` or `If-None-Match` header, the provided value should be the value of the `ETag` header of an earlier GET. From 2d77a361f2ee6fac20417081a0596ed8a36deb37 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Wed, 3 Jul 2019 11:15:21 +0300 Subject: [PATCH 2/6] MXS-2586: Fix users_refresh_time The default value was not assigned on startup. --- server/core/config.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/server/core/config.cc b/server/core/config.cc index 85bfdb663..3ca07e3f6 100644 --- a/server/core/config.cc +++ b/server/core/config.cc @@ -2844,6 +2844,7 @@ void config_set_global_defaults() gateway.passive = false; gateway.promoted_at = 0; gateway.load_persisted_configs = true; + gateway.users_refresh_time = USERS_REFRESH_TIME_DEFAULT; gateway.peer_hosts[0] = '\0'; gateway.peer_user[0] = '\0'; From f36b6492ab027d55a09006eae23915fcd487bfe7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Wed, 3 Jul 2019 12:57:27 +0300 Subject: [PATCH 3/6] Update current DCB for hangup events When fake hangup events are delivered via DCBs, the current DCB would not be updated. This would cause error messages without a session ID which makes failure analysis harder. --- server/core/dcb.cc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/server/core/dcb.cc b/server/core/dcb.cc index 6af8790bd..a75184fe6 100644 --- a/server/core/dcb.cc +++ b/server/core/dcb.cc @@ -2046,15 +2046,19 @@ static void dcb_hangup_foreach_worker(MXB_WORKER* worker, struct server* server) { RoutingWorker* rworker = static_cast(worker); int id = rworker->id(); + DCB* old_current = this_thread.current_dcb; for (DCB* dcb = this_unit.all_dcbs[id]; dcb; dcb = dcb->thread.next) { if (dcb->state == DCB_STATE_POLLING && dcb->server && dcb->server == server && dcb->n_close == 0) { + this_thread.current_dcb = dcb; dcb->flags |= DCBF_HUNG; dcb->func.hangup(dcb); } } + + this_thread.current_dcb = old_current; } /** From 953dd4098bafce6ddfaf80d4566fa5fecd11b74a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Wed, 3 Jul 2019 13:42:14 +0300 Subject: [PATCH 4/6] MXS-2587: Prevent queries after failed trx replay If a transaction replay fails, no queries must be routed before the connection is closed. This could happen if the client received the error from the replay failure and closes the connection before the fake hangup generated by the replay failure is processed. --- .../modules/routing/readwritesplit/rwsplitsession.cc | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/server/modules/routing/readwritesplit/rwsplitsession.cc b/server/modules/routing/readwritesplit/rwsplitsession.cc index bbdb45297..2c49c068e 100644 --- a/server/modules/routing/readwritesplit/rwsplitsession.cc +++ b/server/modules/routing/readwritesplit/rwsplitsession.cc @@ -472,14 +472,15 @@ void RWSplitSession::trx_replay_next_stmt() else { MXS_INFO("Checksum mismatch, transaction replay failed. Closing connection."); - modutil_send_mysql_err_packet(m_client, - 0, - 0, - 1927, - "08S01", + modutil_send_mysql_err_packet(m_client, 1, 0, 1927, "08S01", "Transaction checksum mismatch encountered " "when replaying transaction."); poll_fake_hangup_event(m_client); + + // Turn the replay flag back on to prevent queries from getting routed before the hangup we + // just added is processed. For example, this can happen if the error is sent and the client + // manages to send a COM_QUIT that gets processed before the fake hangup event. + m_is_replay_active = true; } } else From c09a54640d29c97e64cd98ad42477eced9da321e Mon Sep 17 00:00:00 2001 From: Johan Wikman Date: Thu, 4 Jul 2019 08:52:12 +0300 Subject: [PATCH 5/6] Update 2.3.9 release date And update Jira list as well. --- Documentation/Release-Notes/MaxScale-2.3.9-Release-Notes.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/Release-Notes/MaxScale-2.3.9-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.3.9-Release-Notes.md index 1a3d5ac90..934112ee6 100644 --- a/Documentation/Release-Notes/MaxScale-2.3.9-Release-Notes.md +++ b/Documentation/Release-Notes/MaxScale-2.3.9-Release-Notes.md @@ -1,4 +1,4 @@ -# MariaDB MaxScale 2.3.9 Release Notes +# MariaDB MaxScale 2.3.9 Release Notes -- 2019-07-04 Release 2.3.9 is a GA release. @@ -15,7 +15,9 @@ report on [our Jira](https://jira.mariadb.org/projects/MXS). ## Bug fixes * [MXS-2582](https://jira.mariadb.org/browse/MXS-2582) Intermittent unknown statement handler errors from backends +* [MXS-2578](https://jira.mariadb.org/browse/MXS-2578) Maxscale RPM issue PCI Compliancy * [MXS-2575](https://jira.mariadb.org/browse/MXS-2575) PATCH with invalid credentials returns no result +* [MXS-2574](https://jira.mariadb.org/browse/MXS-2574) maxctrl alter user doesn't work on current user * [MXS-2569](https://jira.mariadb.org/browse/MXS-2569) No newline sent with large schemas * [MXS-2563](https://jira.mariadb.org/browse/MXS-2563) Failing debug assertion at rwsplitsession.cc:1129 : m_expected_responses == 0 * [MXS-2562](https://jira.mariadb.org/browse/MXS-2562) Oracle's MySQL Connector/ODBC gets packets out-of-order errors with .NET From be8f4fe055d4d82b222ad71cfe55623720a906b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Tue, 2 Jul 2019 09:23:19 +0300 Subject: [PATCH 6/6] MXS-1901: Route related PS commands to same server All COM_STMT_SEND_LONG_DATA commands and the COM_STMT_EXECUTE that follows it must be sent to the same server. This implicitly works for masters but with multiple slave servers the data could be sent to the wrong server. By using the code added for MXS-2521, this problem can now be easily solved by checking what the previous command was. --- server/core/queryclassifier.cc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/server/core/queryclassifier.cc b/server/core/queryclassifier.cc index 87b78704d..918db76fa 100644 --- a/server/core/queryclassifier.cc +++ b/server/core/queryclassifier.cc @@ -956,8 +956,15 @@ QueryClassifier::current_target_t QueryClassifier::handle_multi_temp_and_load( bool QueryClassifier::query_continues_ps(uint8_t cmd, uint32_t stmt_id, GWBUF* buffer) { bool rval = false; + uint8_t prev_cmd = m_route_info.command(); - if (cmd == COM_STMT_FETCH) + if (prev_cmd == MXS_COM_STMT_SEND_LONG_DATA + && (cmd == MXS_COM_STMT_EXECUTE || cmd == MXS_COM_STMT_SEND_LONG_DATA)) + { + // PS execution must be sent to the same server where the data was sent + rval = true; + } + else if (cmd == COM_STMT_FETCH) { // COM_STMT_FETCH should always go to the same target as the COM_STMT_EXECUTE rval = true;