summaryrefslogtreecommitdiff
path: root/sql/wsrep_mysqld.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.1 into 10.2Julius Goryavsky2020-06-051-1/+8
|\
| * MDEV-22763 backporting MDEV-20225 fix into 10.1sjaakola2020-06-031-1/+8
| | | | | | | | | | | | Backported the support for aborting and replaying stored procedure and fix for trigger key assigments from 10.4 version. Backported also two mtr tests: wsrep_sp_bf_abort and MDEV-20225
* | Merge 10.1 into 10.2Marko Mäkelä2020-04-221-0/+11
|\ \ | |/
| * MDEV-22271 Excessive stack memory usage due to WSREP_LOGMarko Mäkelä2020-04-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several tests that involve stored procedures fail on 10.4 kvm-asan (clang 10) due to stack overrun. The main contributor to this stack overrun is mysql_execute_command(), which is invoked recursively during stored procedure execution. Rebuilding with cmake -DWITH_WSREP=OFF shrunk the stack frame size of mysql_execute_command() by more than 10 kilobytes in a WITH_ASAN=ON, CMAKE_BUILD_TYPE=Debug build. The culprit turned out to be the macro WSREP_LOG, which is allocating a separate 1KiB buffer for every occurrence. We replace the macro with a function, so that the stack will be allocated only when the function is actually invoked. In this way, no stack space will be wasted by default (when WSREP and Galera are disabled). This backports commit b6c5657ef27de034439b1505a8b4815c263d6455 from MariaDB 10.3.1. Without ASAN, compilers can be smarter and optimize the stack usage. The original commit message mentions that 1KiB was saved on GCC 5.4, and 4KiB on Mac OS X Lion, which presumably uses a clang-based compiler.
* | MDEV-21473 conflicts with async slave BF aborting (#1475)seppo2020-03-241-0/+11
| | | | | | | | | | | | | | | | | | If async slave thread (slave SQL handler), becomes a BF victim, it may occasionally happen that rollbacker thread is used to carry out the rollback instead of the async slave thread. This can happen, if async slave thread has flagged "idle" state when BF thread tries to figure out how to kill the victim. The issue was possible to test by using a galera cluster as slave for external master, and issuing high load of conflicting writes through async replication and directly against galera cluster nodes. However, a deterministic mtr test for the "conflict window" has not yet been worked on. The fix, in this patch makes sure that async slave thread state is never set to IDLE. This prevents the rollbacker thread to intervene. The wsrep_query_state change was refactored to happen by dedicated function to make controlling the idle state change in one place.
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-01-241-1/+5
|\ \ | |/
| * MDEV-19457: sys_vars.wsrep_provider_basic failed in buildbotJulius Goryavsky2020-01-201-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the initialization of the wsrep provider failed, in some cases the internal variable wrep_inited indicating that the initialization has already been completed is still set to "1", which then leads to confusion in the initialization status. To solve the problem, we should set this variable to "1" only if the wsrep provider initialization really completed successfully. An earlier issue has already been fixed for branch 10.4, and this patch contains a fix for earlier versions (where Galera 3.x is used).
* | MDEV-21189: Dropping partition with 'wsrep_OSU_method=RSU' and 'SESSION ↵Jan Lindström2019-12-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sql_log_bin = 0' cases the galera node to hang Found two bugs (1) have_committing_connections was missing mutex unlock on one exit case. As this function is called on a loop it caused mutex lock when we already owned the mutex. This could cause hang. (2) wsrep_RSU_begin did set up error code when partition to be dropped could not be MDL-locked because of concurrent operations but wrong error code was propagated to upper layer causing error to be ignored. This could have also caused the hang.
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-12-031-1/+33
|\ \ | |/
| * MDEV-18497 CTAS async replication from mariadb master crashes galera nodes ↵seppo2019-11-181-1/+33
| | | | | | | | | | | | | | | | | | | | (#1410) This PR contains a mtr test for reproducing a failure with replicating create table as select statement (CTAS) through asynchronous mariadb replication to mariadb galera cluster. The problem happens when CTAS replication contains both create table statement followed by row events for populating the table. In such situation, the galera node operating as mariadb replication slave, will first replicate only the create table part into the cluster, and then perform another replication containing both the create table and row events. This will lead all other nodes to fail for duplicate table create attempt, and crash due to this failure. PR contains also a fix, which identifies the situation when CTAS has been replicated, and makes further scan in async replication stream to see if there are following row events. The slave node will replicate either single TOI in case the CTAS table is empty, or if CTAS table contains rows, then single bundled write set with create table and row events is replicated to galera cluster. This fix should keep master server's GTID's for CTAS replication in sync with GTID's in galera cluster.
* | MDEV-18562 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait indexJan Lindström2019-10-301-24/+24
| | | | | | | | | | | | Lock wait can happen on secondary index when doing FK checks for wsrep. We should just return error to upper layer and applier will retry operation when needed.
* | MDEV-20324: Galera threads are not registered to performance schemaJan Lindström2019-08-131-1/+15
| | | | | | | | | | | | | | | | | | Galera threads were not registered to performance schema and used pthread_create when mysql_thread_create should have been used. Added test case to verify current galera performance schema instrumentation does work.
* | MDEV-19746: Galera test failures because of wsrep_slave_threads identificationJan Lindström2019-07-151-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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
| |
| * Revert MDEV-18464 and MDEV-12009Marko Mäkelä2019-03-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 21b2fada7ab7f35c898c02d2f918461409cc9c8e and commit 81d71ee6b21870772c336bff15b71904914f146a. The MDEV-18464 change introduces a few data race issues. Contrary to the documentation, the field trx_t::victim is not always being protected by lock_sys_t::mutex and trx_t::mutex. Most importantly, it seems that KILL QUERY could wrongly avoid acquiring both mutexes when invoking lock_trx_handle_wait_low(), in case another thread had already set trx->victim=true. We also revert MDEV-12009, because it should depend on the MDEV-18464 fix being present.
| * MDEV-12009: Allow to force kill user threads/query which are flagged as high ↵Jan Lindström2019-03-281-1/+0
| | | | | | | | | | | | | | | | | | | | priority by Galera As noted on kill_one_thread SUPER should be able to kill even system threads i.e. threads/query flagged as high priority or wsrep applier thread. Normal user, should not able to kill threads/query flagged as high priority (BF) or wsrep applier thread.
* | Merge 10.1 into 10.2Marko Mäkelä2019-02-021-0/+1
|\ \ | |/
| * Merge branch '10.0-galera' into 10.1Oleksandr Byelkin2019-01-311-0/+1
| |\
| | * Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-10-301-0/+1
| | |\
| | | * Add a new config variable wsrep_certification_rulesVasil Dimov2018-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used for controlling whether to use a new/optimized certification rules or the old/classic ones that could cause more certification failures - when foreign keys are used and two INSERTs are done concurrently to the child table from different nodes. (cherry picked from commit 815d73e6af8daace6262ab63ca6c043ffc4204b3)
| * | | MDEV-17801: Galera test failure on galera_var_reject_queriesJan Lindström2018-11-261-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17801: Galera test failure on galera_var_reject_queriesJan Lindström2018-11-221-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 10.1 into 10.2Marko Mäkelä2018-11-061-1/+1
|\ \ \ \ | |/ / /
| * | | wsrep: create a macro for the error: labelSergei Golubchik2018-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | that is used by WSREP_TO_ISOLATION_BEGIN and other galera macros, to avoid the need for wrapping this label in #ifdef WITH_WSREP/#endif
* | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-96/+199
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0-galera' into 10.1Sergei Golubchik2018-09-071-91/+198
| |\ \ \ | | |/ /
| | * | MariaDB adjustments.Jan Lindström2018-08-031-3/+15
| | | |
| | * | Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-08-021-92/+125
| | |\ \ | | | |/
| | | * Fix FK constraint violation in applier, after ALTER TABLE ADD FKDaniele Sciascia2018-08-021-109/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding a FK constraint to an existing table (ALTER TABLE ADD FOREIGN KEY) causes the applier to fail, if a concurrent DML statement that violate the new constraint (i.e. a DELETE or UPDATE of record in the parent table). For exmaple, the following scenario causes a crash in the applier: 1. ALTER successfully adds FK constraint in node_1 2. On node_2 is UPDATE is in pre_commit() and has certified successfully 3. ALTER is delivered in node_2 and BF aborts DML 4. Applying UPDATE event causes FK violation in node_1 To avoid this situation it is necessary for UPDATE to fail during certification. And for the UPDATE to fail certfication it is necessary that ALTER appends certification keys for both the child and the parent table. Before this patch, ALTER TABLE ADD FK only appended keys for child table which is ALTERed.
| | * | MDEV-10564: Galera `wsrep_debug` patch logs MySQL user credentialsJan Lindström2018-07-191-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | Restricted output for CREATE USER, GRANT, REVOKE and SET PASSWORD so that it shows only above keywords but not rest of query i.e. not user or password.
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-021-3/+23
|\ \ \ \ | |/ / /
| * | | MDEV-10564: Galera `wsrep_debug` patch logs MySQL user credentialsJan Lindström2018-07-191-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | Restricted output for CREATE USER, GRANT, REVOKE and SET PASSWORD so that it shows only above keywords but not rest of query i.e. not user or password.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-32/+33
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0-galera' into 10.1Vicențiu Ciorbaru2018-06-121-32/+33
| |\ \ \ | | |/ /
| | * | Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-05-071-32/+33
| | |\ \ | | | |/
| | | * MW-384 protect access to wsrep_ready variable with mutexAlexey Yurchenko2017-10-191-13/+23
| | | |
| | | * MW-322 - CTAS fix merged to 5.5-v25 branchsjaakola2017-07-201-17/+7
| | | | | | | | | | | | | | | | Signed-off-by: Jan Lindström <jan.lindstrom@mariadb.com>
| | | * MW-267: followup to the original pull request, removed unnecessary cast.Alexey Yurchenko2017-04-181-2/+1
| | | |
| | | * MW-267Sachin Setiya2017-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix Galera crash at startup when compiled with gcc 6 Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>
| | | * MDEV-11479 Improved wsrep_dirty_readsSachin Setiya2016-12-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tasks:- Changes in wsrep_dirty_reads variable 1.) Global + Session scope (Current: session-only) 2.) Can be set using command line. 3.) Allow all commands that do not change data (besides SELECT) 4.) Allow prepared Statements that do not change data 5.) Works with wsrep_sync_wait enabled
| | | * refs codership/mysql-wsrep#226 Limit binlog recovery to found wsrep positionTeemu Ollakka2016-02-101-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Limit binlog recovery so that the wsrep position found from storage engines is not exceeded. This is required to have consistent position between wsrep position stored in innodb header and recoverd binlog.
| | | * refs codership/mysql-wsrep#201Daniele Sciascia2016-02-091-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Fixes query cache so that it is aware of wsrep_sync_wait. Query cache would return (possibly stale) results to the client, regardless of the value of wsrep_sync_wait. - Includes the test case that reproduced the issue.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-101-18/+17
|\ \ \ \ | |/ / /
| * | | MDEV-16005 sporadic failures with galera tests MW-328B and MW-328Csjaakola2018-04-241-20/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These test can sporadically show mutex deadlock warnings between LOCK_wsrep_thd and LOCK_thd_data mutexes. This means that these mutexes can be locked in opposite order by different threads, and thus result in deadlock situation. To fix such issue, the locking policy of these mutexes should be revised and enforced to be uniform. However, a quick code review shows that the number of lock/unlock operations for these mutexes combined is between 100-200, and all these mutex invocations should be checked/fixed. On the other hand, it turns out that LOCK_wsrep_thd is used for protecting access to wsrep variables of THD (wsrep_conflict_state, wsrep_query_state), whereas LOCK_thd_data protects query, db and mysys_var variables in THD. Extending LOCK_thd_data to protect also wsrep variables looks like a viable solution, as there should not be a use case where separate threads need simultaneous access to wsrep variables and THD data variables. In this commit LOCK_wsrep_thd mutex is refactored to be replaced by LOCK_thd_data. By bluntly replacing LOCK_wsrep_thd by LOCK_thd_data, will result in double locking of LOCK_thd_data, and some adjustements have been performed to fix such situations.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-03-251-1/+1
|\ \ \ \ | |/ / /
| * | | MDEV-15409 make sure every sst script is tested in buildbotSergei Golubchik2018-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix galera.galera_sst_mysqldump test to work: * must connect to 127.0.0.1, where mysqld is listening * disable wsrep_sync_wait in wsrep_sst_mysqldump, otherwise sst can deadlock * allow 127.0.0.1 for bind_address and wsrep_sst_receive_address. (it's useful in tests, or when two nodes are on the same box, or when nodes are on different boxes, but the connection is tunelled, or whatever. Don't judge user's setup). MDEV-14070 * don't wait for client connections to die when doing mysqldump sst. they'll die in a due time, and if needed mysql will wait on locks until they do. MDEV-14069 Also don't mark it big, to make sure it's sufficiently tested
* | | | Merge remote-tracking branch 'origin/10.1' into 10.2Vicențiu Ciorbaru2018-03-161-1/+1
|\ \ \ \ | |/ / /
| * | | MDEV-13549 Fix and re-enable test galera.MW-286Daniele Sciascia2018-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test failed to work properly because the fixes it came with were not merged from upstream. The test would fail with a spurious ER_LOCK_DEADLOCK error for a conflict that happened earlier in the test execution, while wsrep is disabled. The original fix was to set THD::wsrep_conflict_state only if wsrep is enabled (see wsrep_thd_set_conflict_state() in sql/wsrep_mysqld.cc)
* | | | Fixed wrong arguments to printf and related functionsMonty2018-01-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Other things, mainly to get create_mysqld_error_find_printf_error tool to work: - Added protection to not include mysqld_error.h twice - Include "unireg.h" instead of "mysqld_error.h" in server - Added protection if ER_XX messages are already defined - Removed wrong calls to my_error(ER_OUTOFMEMORY) as my_malloc() and my_alloc will do this automatically - Added missing %s to ER_DUP_QUERY_NAME - Removed old and wrong calls to my_strerror() when using MY_ERROR_ON_RENAME (wrong merge) - Fixed deadlock error message from Galera. Before the extra information given to ER_LOCK_DEADLOCK was missing because ER_LOCK_DEADLOCK doesn't provide any extra information. I kept #ifdef mysqld_error_find_printf_error_used in sql_acl.h to make it easy to do this kind of check again in the future
View Lorry Controller Status