summaryrefslogtreecommitdiff
path: root/sql/wsrep_var.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-20008: Galera strict modebb-10.6-MDEV-20008mkaruza2021-01-261-0/+16
| | | | | | | | | | | | | Added new enum variable `wsrep_mode` which can be used to turn on WSREP features which are not part of default behaviour. Added enum `BINLOG_ROW_FORMAT_ONLY`, `REQUIRED_PRIMARY_KEY` and `STRICT_REPLICATION`. `wsrep-mode=STRICT_REPLICATION` behaves like variable `wsrep_strict_ddl`. Variable wsrep_strict_ddl is deprecated and if set we use new wsrep_mode setting instead. Reviewed and improved by: Jan Lindström <jan.lindstrom@mariadb.com>
* Merge 10.5 into 10.6Marko Mäkelä2021-01-251-20/+87
|\
| * Merge 10.4 into 10.5Marko Mäkelä2021-01-251-20/+87
| |\
| | * MDEV-24463 : galera.galera_sst_mysqldump_with_key MTR failed: 'INSERT ↵bb-10.4-MDEV-24463Jan Lindström2021-01-221-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | failed: 1213: Deadlock found when trying to get lock We need to complete SST if both new and old start positions are not same as initial positions. If they are initial positions just set local uuid and seqno.
| | * MDEV-24596 : Assertion `state_ == s_exec || state_ == s_quitting' failed in ↵Jan Lindström2021-01-211-14/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wsrep::client_state::disable_streaming There were multiple problems here * wsrep_trx_fragment_size should not be set when wsrep is disabled or provider is not loaded * wsrep_trx_fragment_unit should not be set when wsrep is disabled or provider is not loaded * wsrep_debug has no effect if wsrep is disabled or provider is not loaded * wsrep_start_position should not be set when wsrep is disabled or provider is not loaded any other value than default * wsrep_start_position should be changed only when we are joiner or initialized * wsrep_start_position should be allowed to set only a value that exits, thus we need to add error handling to wsrep_sst_complete
| | * MDEV-22285 : Assertion `xid_seqno > wsrep_seqno' failed in ↵Jan Lindström2021-01-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | trx_rseg_update_wsrep_checkpoint on SET @@global.wsrep_start_position Actual assertion mentioned on MDEV seems to be already fixed but setting seqno to -2 will trigger a different assertion mysqld: /home/jan/mysql/10.4-bugs/wsrep-lib/src/server_state.cpp:702: void wsrep::server_state::sst_received(wsrep::client_service&, int): Assertion `state_ == s_joiner || state_ == s_initialized' failed. Fixed this by not allowing user to set seqno < -1 (-1 is special seqno meaning undefined and seqno is initialized to it). MariaDB releases 10.2 and 10.3 already do not allow to set seqno < -1.
* | | Merge 10.5 into 10.6Marko Mäkelä2021-01-111-0/+8
|\ \ \ | |/ /
| * | MDEV-24546 : AddressSanitizer: initialization-order-fiasco on address ... in ↵Jan Lindström2021-01-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Sys_var_integer from __static_initialization_and_destruction_0, possibly inside global var wsrep_gtid_server Galera parameter wsrep_gtid_domain_id was defined using a class where actual parameter was not a first member. Fixed this by using normal variable and assigning this value to class member value.
* | | Merge 10.5 into 10.6Marko Mäkelä2020-11-021-1/+2
|\ \ \ | |/ /
| * | Merge 10.4 to 10.5Marko Mäkelä2020-10-221-1/+2
| |\ \ | | |/
| | * Merge 10.3 into 10.4Marko Mäkelä2020-10-221-1/+2
| | |\
| | | * Merge 10.2 into 10.3Marko Mäkelä2020-10-221-2/+2
| | | |\
| | | | * MDEV-23894 UBSAN: several call to function show_binlog_vars(THD*, ↵Eugene Kosov2020-10-061-2/+2
| | | | | | | | | | | | | | | | | | | | st_mysql_show_var*, char*) through pointer to incorrect function type 'int (*)(THD *, st_mysql_show_var *, void *, system_status_var *, enum_var_type) errors
| | | * | Merge 10.2 into 10.3Marko Mäkelä2020-01-181-2/+8
| | | |\ \ | | | | |/
| | | | * MDEV-17062 : Test failure on galera.MW-336Jan Lindström2020-01-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Add mutex protection while we calculate required slave thread change and create them. Add error handling.
* | | | | MDEV-16664: Remove innodb_lock_schedule_algorithmbb-10.6-MDEV-16664Marko Mäkelä2020-10-051-18/+1
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setting innodb_lock_schedule_algorithm=VATS that was introduced in MDEV-11039 (commit 021212b525e39d332cddd0b9f1656e2fa8044905) causes conflicting exclusive locks to be incorrectly granted to two transactions. Specifically, in lock_rec_insert_by_trx_age() the predicate !lock_rec_has_to_wait_in_queue(in_lock) would hold even though an active transaction is already holding an exclusive lock. This was observed between two DELETE of the same clustered index record. The HASH_DELETE invocation in lock_rec_enqueue_waiting() may be related. Due to lack of progress in diagnosing the problem, we will remove the option. The unsafe option was enabled by default between commit 0c15d1a6ff0d18da946f050cfeac176387a76112 (MariaDB 10.2.3) and the parent of commit 1cc1d0429da14a041a6240c6fce17e0d31cad8e2 (MariaDB 10.2.17, 10.3.9), and it was deprecated in commit 295e2d500b31819422c97ad77beb6226b961c207 (MariaDB 10.2.34).
* | | | Fixed wrong value of "wsrep" in SHOW STATUSMonty2020-08-201-0/+5
| | | | | | | | | | | | | | | | | | | | If WSREP was not initalized SHOW GLOBAL STATUS could have a random value of "wsrep"
* | | | Merge 10.4 into 10.5Marko Mäkelä2020-08-201-0/+6
|\ \ \ \ | |/ / /
| * | | MDEV-23092 SIGABRT when setting invalid wsrep_providerDaniele Sciascia2020-08-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some invalid wsrep_provider paths may be interpreted as a valid directory. For example '/invalid/libgalera_smm.so' with UTF character set is interpreted as '/', which is a valid directory. A early check that wsrep_provider should not be a directory fixes it.
* | | | Merge 10.4 into 10.5Marko Mäkelä2020-04-251-0/+12
|\ \ \ \ | |/ / / | | | | | | | | | | | | The functional changes of commit 5836191c8f0658d5d75484766fdcc3d838b0a5c1 (MDEV-21168) are omitted due to MDEV-742 having addressed the issue.
| * | | MDEV-22203: WSREP_ON is unnecessarily expensive WITH_WSREP=OFFMarko Mäkelä2020-04-241-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the server is compiled WITH_WSREP=OFF, we should avoid evaluating conditions on a global variable that is constant. WSREP_ON_: Renamed from WSREP_ON. Defined only WITH_WSREP=ON. WSREP_ON: Defined as unlikely(WSREP_ON_). wsrep_on(): Defined as WSREP_ON && wsrep_service->wsrep_on_func(). The reason why we have wsrep_on() at all is that the macro WSREP(thd) depends on the definition of THD, and that is intentionally an opaque data type for InnoDB. So, we cannot avoid invoking wsrep_on(), but we can evaluate the less expensive condition WSREP_ON before calling the function.
| * | | MDEV-22203: WSREP_ON is unnecessarily expensive to evaluateJan Lindström2020-04-241-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | Replaced WSREP_ON macro by single global variable WSREP_ON that is then updated at server statup and on wsrep_on and wsrep_provider update functions.
* | | | perfschema memory related instrumentation changesSergei Golubchik2020-03-101-15/+15
| | | |
* | | | Merge 10.4 into 10.5Marko Mäkelä2020-02-071-50/+71
|\ \ \ \ | |/ / /
| * | | MDEV-20625 : MariaDB asserting when enabling wsrep_onbb-10.4-MDEV-20625Jan Lindström2020-02-041-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to release global system variables mutex before doing wsrep_init to avoid race with next show status and we need to save wsrep_on value as it is changed on wsrep_init. Added test case.
| * | | MDEV-20625 : MariaDB asserting when enabling wsrep_onJan Lindström2020-02-031-48/+68
| | | | | | | | | | | | | | | | | | | | When wsrep_on is changed to ON we might need to run wsrep_init if wsrep-provider is set and wsrep is not inited.
* | | | Galera GTID supportmkaruza2020-01-291-3/+52
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support for galera GTID consistency thru cluster. All nodes in cluster should have same GTID for replicated events which are originating from cluster. Cluster originating commands need to contain sequential WSREP GTID seqno Ignore manual setting of gtid_seq_no=X. In master-slave scenario where master is non galera node replicated GTID is replicated and is preserved in all nodes. To have this - domain_id, server_id and seqnos should be same on all nodes. Node which bootstraps the cluster, to achieve this, sends domain_id and server_id to other nodes and this combination is used to write GTID for events that are replicated inside cluster. Cluster nodes that are executing non replicated events are going to have different GTID than replicated ones, difference will be visible in domain part of gtid. With wsrep_gtid_domain_id you can set domain_id for WSREP cluster. Functions WSREP_LAST_WRITTEN_GTID, WSREP_LAST_SEEN_GTID and WSREP_SYNC_WAIT_UPTO_GTID now works with "native" GTID format. Fixed galera tests to reflect this chances. Add variable to manually update WSREP GTID seqno in cluster Add variable to manipulate and change WSREP GTID seqno. Next command originating from cluster and on same thread will have set seqno and cluster should change their internal counter to it's value. Behavior is same as using @@gtid_seq_no for non WSREP transaction.
* | | MDEV-17062 : Test failure on galera.MW-336Jan Lindström2020-01-201-2/+9
| | | | | | | | | | | | | | | Add mutex protection while we calculate required slave thread change and create them. Add error handling.
* | | Merge 10.3 into 10.4Marko Mäkelä2019-07-251-6/+12
|\ \ \ | |/ /
| * | Merge 10.2 into 10.3Eugene Kosov2019-07-161-7/+11
| |\ \ | | |/
| | * MDEV-19746: Galera test failures because of wsrep_slave_threads identificationJan Lindström2019-07-151-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that tests select INFORMATION_SCHEMA.PROCESSLIST processes from user system user and empty state. Thus, there is not clear state for slave threads. Changes: - Added new status variables that store current amount of applier threads (wsrep_applier_thread_count) and rollbacker threads (wsrep_rollbacker_thread_count). This will make clear how many slave threads of certain type there is. - Added THD state "wsrep applier idle" when applier slave thread is waiting for work. This makes finding slave/applier threads easier. - Added force-restart option for mtr to always restart servers between tests to avoid race on start of the test - Added wait_condition_with_debug to wait until the passed statement returns true, or the operation times out. If operation times out, the additional error statement will be executed Changes to be committed: new file: mysql-test/include/force_restart.inc new file: mysql-test/include/wait_condition_with_debug.inc modified: mysql-test/mysql-test-run.pl modified: mysql-test/suite/galera/disabled.def modified: mysql-test/suite/galera/r/MW-336.result modified: mysql-test/suite/galera/r/galera_kill_applier.result modified: mysql-test/suite/galera/r/galera_var_slave_threads.result new file: mysql-test/suite/galera/t/MW-336.cnf modified: mysql-test/suite/galera/t/MW-336.test modified: mysql-test/suite/galera/t/galera_kill_applier.test modified: mysql-test/suite/galera/t/galera_parallel_autoinc_largetrx.test modified: mysql-test/suite/galera/t/galera_parallel_autoinc_manytrx.test modified: mysql-test/suite/galera/t/galera_var_slave_threads.test modified: mysql-test/suite/wsrep/disabled.def modified: mysql-test/suite/wsrep/r/variables.result modified: mysql-test/suite/wsrep/t/variables.test modified: sql/mysqld.cc modified: sql/wsrep_mysqld.cc modified: sql/wsrep_mysqld.h modified: sql/wsrep_thd.cc modified: sql/wsrep_var.cc
* | | Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-191-1/+1
|\ \ \ | |/ /
| * | Merge 10.2 into 10.3Marko Mäkelä2019-05-141-1/+1
| |\ \ | | |/
| | * Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
| | |\
| | | * Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| | | |
| | | * MDEV-17801: Galera test failure on galera_var_reject_queriesJan Lindström2018-11-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that controlling connection i.e. connection that executed the query SET GLOBAL wsrep_reject_queries = ALL_KILL; was also killed but server would try to send result from that query to controlling connection resulting a assertion mysqld: /home/jan/mysql/10.2-sst/include/mysql/psi/mysql_socket.h:738: inline_mysql_socket_send: Assertion `mysql_socket.fd != -1' failed. as socket was closed when controlling connection was closed. wsrep_close_client_connections() Do not close controlling connection and instead of wsrep_close_thread() we do now soft kill by THD::awake wsrep_reject_queries_update() Call wsrep_close_client_connections using current thd.
* | | | MDEV-18552 MDEV-18699 allowing SR only in galera 4 cluster (#1293)bb-10.4-collapseseppo2019-05-031-0/+8
| | | | | | | | | | | | | | | | Streaming replication must be allowed only in a cluster, where all nodes have Galera 4 capability
* | | | LOCK_thread_count and COND_thread_count removed from wsrep modules (#1197)seppo2019-02-261-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactored wsrep patch to not use LOCK_thread_count and COND_thread_count anymore. This has partially been replaced by using old LOCK_wsrep_slave_threads mutex. For slave thread count change waiting, new COND_wsrep_slave_threads signal has been added Added LOCK_wsrep_cluster_config mutex to control that cluster address change cannot happen in parallel Protected wsrep_slave_threads variable changes with LOCK_cluster_config mutex This is for avoiding concurrent slave thread count and cluster joining operations to happen Fixes according to Teemu's review
* | | | Disable unused functionMarko Mäkelä2019-02-181-1/+2
| | | |
* | | | WSREP debug log levels supportmkaruza2019-02-131-0/+6
| | | | | | | | | | | | | | | | | | | | Global variable wsrep_debug now can be used to filter wsrep-lib messages based on debug level provided. Type of wsrep_debug is now set to be unsigned int, so tests and configuration files changed accordingly.
* | | | Galera4Brave Galera Crew2019-01-231-121/+200
|/ / /
* | | Merge 10.2 into 10.3Marko Mäkelä2018-11-261-1/+2
|\ \ \ | |/ / | | | | | | | | | The test galera_sst_mariabackup_table_options was disabled, because the server refuses to start up due to wrong parameters.
| * | MDEV-17801: Galera test failure on galera_var_reject_queriesJan Lindström2018-11-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that controlling connection i.e. connection that executed the query SET GLOBAL wsrep_reject_queries = ALL_KILL; was also killed but server would try to send result from that query to controlling connection resulting a assertion mysqld: /home/jan/mysql/10.2-sst/include/mysql/psi/mysql_socket.h:738: inline_mysql_socket_send: Assertion `mysql_socket.fd != -1' failed. as socket was closed when controlling connection was closed. wsrep_close_client_connections() Do not close controlling connection and instead of wsrep_close_thread() we do now soft kill by THD::awake wsrep_reject_queries_update() Call wsrep_close_client_connections using current thd.
* | | Merge branch '10.2' into 10.3Sergei Golubchik2018-09-281-2/+1
|\ \ \ | |/ /
| * | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-1/+3
| |\ \ | | |/
| | * Merge branch '10.0-galera' into 10.1Sergei Golubchik2018-09-071-1/+1
| | |\
| | * | MDEV-17062: Test failure on galera.MW-336Jan Lindström2018-09-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-17058: Test failure on wsrep.variables MDEV-17060: Test failure on galera.galera_var_slave_threads Fix incorrect calculation of increased applier (slave) threads. Note that increase change takes effect "immediately" but we should use proper wait condition to wait it. Reducing the number of slave threads is not immediate as thread will only exit after a replication event.
* | | | Merge 10.2 into 10.3Marko Mäkelä2018-08-281-0/+6
|\ \ \ \ | |/ / /
| * | | Merge 10.1 into 10.2Marko Mäkelä2018-08-211-0/+6
| |\ \ \ | | |/ /
| | * | MDEV-15933 Cannot resume Node SYNCED state when wsrep_desync is done after FTWRLmkaruza2018-08-141-0/+6
| | | | | | | | | | | | | | | | Manually setting wsrep_desync after FTWRL should not be allowed.