From 6a8ba999bddcbe6d5a4d7e9c357be573e480e85f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Thu, 8 Nov 2018 08:31:48 +0200 Subject: [PATCH 1/4] MXS-2095: Fix crash on GRANT CREATE TEMPORARY TABLE The avrorouter classified the GRANT statement as a CREATE TABLE statement. --- maxscale-system-test/avro.cpp | 5 +++++ server/modules/routing/avrorouter/avro.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/maxscale-system-test/avro.cpp b/maxscale-system-test/avro.cpp index 384ebe3d4..be8f85ecf 100644 --- a/maxscale-system-test/avro.cpp +++ b/maxscale-system-test/avro.cpp @@ -37,6 +37,11 @@ int main(int argc, char *argv[]) test.set_timeout(120); test.repl->connect(); + // MXS-2095: Crash on GRANT CREATE TABLE + execute_query(test.repl->nodes[0], "CREATE USER test IDENTIFIED BY 'test'"); + execute_query(test.repl->nodes[0], "GRANT CREATE TEMPORARY TABLES ON *.* TO test"); + execute_query(test.repl->nodes[0], "DROP USER test"); + create_t1(test.repl->nodes[0]); insert_into_t1(test.repl->nodes[0], 3); execute_query(test.repl->nodes[0], "FLUSH LOGS"); diff --git a/server/modules/routing/avrorouter/avro.c b/server/modules/routing/avrorouter/avro.c index bf9c44ddf..32034c6af 100644 --- a/server/modules/routing/avrorouter/avro.c +++ b/server/modules/routing/avrorouter/avro.c @@ -59,9 +59,9 @@ static const char* avro_index_name = "avro.index"; /** For detection of CREATE/ALTER TABLE statements */ static const char* create_table_regex = - "(?i)create[a-z0-9[:space:]_]+table"; + "(?i)^[[:space:]]*create[a-z0-9[:space:]_]+table"; static const char* alter_table_regex = - "(?i)alter[[:space:]]+table"; + "(?i)^[[:space:]]*alter[[:space:]]+table"; /* The router entry points */ static MXS_ROUTER *createInstance(SERVICE *service, char **options); From bfc8cb4803b77a67effb1d84be3c19623f21ded9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Fri, 9 Nov 2018 00:39:32 +0200 Subject: [PATCH 2/4] MXS-2151: Always log fatal master connection errors When the connection to the master is broken, the session is not configured to use the read-only modes and the monitor can still connect to the server, the connection will be closed and and error is sent to the client. To leave some trace of this problem in the MaxScale logs, a message should always be logged when a network error occurs. --- .../routing/readwritesplit/readwritesplit.cc | 24 +++++++++++++------ 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/server/modules/routing/readwritesplit/readwritesplit.cc b/server/modules/routing/readwritesplit/readwritesplit.cc index c3aeddbc3..7dde02f89 100644 --- a/server/modules/routing/readwritesplit/readwritesplit.cc +++ b/server/modules/routing/readwritesplit/readwritesplit.cc @@ -441,13 +441,19 @@ static bool handle_error_new_connection(RWSplit *inst, if (inst->config().disable_sescmd_history) { for (auto it = myrses->backends.begin(); it != myrses->backends.end(); it++) - { - if ((*it)->in_use()) - { - succp = true; - break; - } - } + { + if ((*it)->in_use()) + { + succp = true; + break; + } + } + + if (!succp) + { + MXS_ERROR("Unable to continue session as all connections have failed, " + "last server to fail was '%s'.", backend->name()); + } } else { @@ -1388,6 +1394,10 @@ static void handleError(MXS_ROUTER *instance, "will be closed.", srv->name, srv->port); srv->master_err_is_logged = true; } + else + { + MXS_ERROR("Lost connection to the master server, closing session."); + } *succp = can_continue; From 293d45aaf19567462f41318c0514c708b7d8b4f3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Fri, 9 Nov 2018 07:45:02 +0200 Subject: [PATCH 3/4] Limit line length in galeramon documentation Split long lines that exceeded 80 characters. --- Documentation/Monitors/Galera-Monitor.md | 45 +++++++++++++++++------- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/Documentation/Monitors/Galera-Monitor.md b/Documentation/Monitors/Galera-Monitor.md index c333d6db1..c232a35c9 100644 --- a/Documentation/Monitors/Galera-Monitor.md +++ b/Documentation/Monitors/Galera-Monitor.md @@ -2,15 +2,21 @@ ## Overview -The Galera Monitor is a monitoring module for MaxScale that monitors a Galera cluster. It detects whether nodes are a part of the cluster and if they are in sync with the rest of the cluster. It can also assign master and slave roles inside MaxScale, allowing Galera clusters to be used with modules designed for traditional master-slave clusters. +The Galera Monitor is a monitoring module for MaxScale that monitors a Galera +cluster. It detects whether nodes are a part of the cluster and if they are in +sync with the rest of the cluster. It can also assign master and slave roles +inside MaxScale, allowing Galera clusters to be used with modules designed for +traditional master-slave clusters. -By default, the Galera Monitor will choose the node with the lowest `wsrep_local_index` -value as the master. This will mean that two MaxScales running on different -servers will choose the same server as the master. +By default, the Galera Monitor will choose the node with the lowest +`wsrep_local_index` value as the master. This will mean that two MaxScales +running on different servers will choose the same server as the master. ## Configuration -A minimal configuration for a monitor requires a set of servers for monitoring and a username and a password to connect to these servers. The user requires the REPLICATION CLIENT privilege to successfully monitor the state of the servers. +A minimal configuration for a monitor requires a set of servers for monitoring +and a username and a password to connect to these servers. The user requires the +REPLICATION CLIENT privilege to successfully monitor the state of the servers. ``` [Galera Monitor] @@ -24,7 +30,8 @@ passwd=mypwd ## Common Monitor Parameters -For a list of optional parameters that all monitors support, read the [Monitor Common](Monitor-Common.md) document. +For a list of optional parameters that all monitors support, read the +[Monitor Common](Monitor-Common.md) document. ## Galera Monitor optional parameters @@ -32,7 +39,11 @@ These are optional parameters specific to the Galera Monitor. ### `disable_master_failback` -If a node marked as master inside MaxScale happens to fail and the master status is assigned to another node MaxScale will normally return the master status to the original node after it comes back up. With this option enabled, if the master status is assigned to a new node it will not be reassigned to the original node for as long as the new master node is running. +If a node marked as master inside MaxScale happens to fail and the master status +is assigned to another node MaxScale will normally return the master status to +the original node after it comes back up. With this option enabled, if the +master status is assigned to a new node it will not be reassigned to the +original node for as long as the new master node is running. ``` disable_master_failback=true @@ -40,7 +51,11 @@ disable_master_failback=true ### `available_when_donor` -This option only has an effect if there is a single Galera node being backed up an XtraBackup instance. This causes the initial node to go into Donor state which would normally prevent if from being marked as a valid server inside MaxScale. If this option is enabled, a single node in Donor state where the method is XtraBackup will be kept in Synced state. +This option only has an effect if there is a single Galera node being backed up +an XtraBackup instance. This causes the initial node to go into Donor state +which would normally prevent if from being marked as a valid server inside +MaxScale. If this option is enabled, a single node in Donor state where the +method is XtraBackup will be kept in Synced state. ``` available_when_donor=true @@ -48,7 +63,9 @@ available_when_donor=true ### `disable_master_role_setting` -This disables the assignment of master and slave roles to the Galera cluster nodes. If this option is enabled, Synced is the only status assigned by this monitor. +This disables the assignment of master and slave roles to the Galera cluster +nodes. If this option is enabled, Synced is the only status assigned by this +monitor. ``` disable_master_role_setting=true @@ -56,7 +73,9 @@ disable_master_role_setting=true ### `use_priority` -Enable interaction with server priorities. This will allow the monitor to deterministically pick the write node for the monitored Galera cluster and will allow for controlled node replacement. +Enable interaction with server priorities. This will allow the monitor to +deterministically pick the write node for the monitored Galera cluster and will +allow for controlled node replacement. ``` use_priority=true @@ -114,9 +133,9 @@ a master server inside MaxScale. If all candidate servers have the same priority, the order of the servers in the `servers` parameter dictates which is chosen as the master. -Nodes with a non-positive value (_priority_ <= 0) will never be chosen as the master. This allows -you to mark some servers as permanent slaves by assigning a non-positive value -into _priority_. +Nodes with a non-positive value (_priority_ <= 0) will never be chosen as the +master. This allows you to mark some servers as permanent slaves by assigning a +non-positive value into _priority_. Here is an example. From aadd6f38dcee3362417193ceeda0f540409dfa37 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20M=C3=A4kel=C3=A4?= Date: Fri, 9 Nov 2018 07:58:53 +0200 Subject: [PATCH 4/4] MXS-2153: Update available_when_donor documentation Added a more precise description of what the parameter does, what the accepted values are and where to get more information. --- Documentation/Monitors/Galera-Monitor.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/Documentation/Monitors/Galera-Monitor.md b/Documentation/Monitors/Galera-Monitor.md index c232a35c9..8bfb1632b 100644 --- a/Documentation/Monitors/Galera-Monitor.md +++ b/Documentation/Monitors/Galera-Monitor.md @@ -51,11 +51,20 @@ disable_master_failback=true ### `available_when_donor` -This option only has an effect if there is a single Galera node being backed up -an XtraBackup instance. This causes the initial node to go into Donor state -which would normally prevent if from being marked as a valid server inside -MaxScale. If this option is enabled, a single node in Donor state where the -method is XtraBackup will be kept in Synced state. +This option allows Galera nodes to be used normally when they are donors in an +SST operation when the SST method is non-blocking +(e.g. `wsrep_sst_method=mariabackup`). + +Normally when an SST is performed, both participating nodes lose their Synced, +Master or Slave statuses. When this option is enabled, the donor is treated as +if it was a normal member of the cluster (i.e. `wsrep_local_state = 4`). This is +especially useful if the cluster drops down to one node and an SST is required +to increase the cluster size. + +The current list of non-blocking SST +methods are `xtrabackup`, `xtrabackup-v2` and `mariabackup`. Read the +[wsrep_sst_method](https://mariadb.com/kb/en/library/galera-cluster-system-variables/#wsrep_sst_method) +documentation for more details. ``` available_when_donor=true