summaryrefslogtreecommitdiff
path: root/sql/wsrep_mysqld.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-20715 : Implement system variable to disallow local GTIDs in Galerabb-10.6-MDEV-20715Jan Lindström2021-03-011-4/+34
| | | | | | | | | | | | Added a new wsrep_mode feature DISALLOW_LOCAL_GTID for this. Nodes can have GTIDs for local transactions in the following scenarios: A DDL statement is executed with wsrep_OSU_method=RSU set. A DML statement writes to a non-InnoDB table. A DML statement writes to an InnoDB table with wsrep_on=OFF set. If user has set wsrep_mode=DISALLOW_LOCAL_GTID these operations produce a error ERROR HY000: Galera replication not supported
* MENT-411 : Implement wsrep_replicate_ariaJan Lindström2021-02-251-6/+10
| | | | | | | | | | | | | | | Introduced two new wsrep_mode options * REPLICATE_MYISAM * REPLICATE_ARIA Depracated wsrep_replicate_myisam parameter and we use wsrep_mode = REPLICATE_MYISAM instead. This required small refactoring of wsrep_check_mode_after_open_table so that both MyISAM and Aria are handled on required DML cases. Similarly, added Aria to wsrep_should_replicate_ddl to handle DDL for Aria tables using TOI. Added test cases and improved MyISAM testing. Changed use of wsrep_replicate_myisam to wsrep_mode = REPLICATE_MYISAM
* Merge 10.5 into 10.6Marko Mäkelä2021-02-241-2/+15
|\
| * Merge branch '10.4' into 10.5Sergei Golubchik2021-02-231-2/+15
| |\
| | * Merge branch 'bb-10.4-release' into 10.4Sergei Golubchik2021-02-231-21/+5
| | |\
| | * | MDEV-24865 : Server crashes when truncate mysql user tablebb-10.4-MDEV-24865Jan Lindström2021-02-161-17/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For truncate we try to find out possible foreign key tables using open_tables. However, table_list was not cleaned up properly and there was no error handling. Fixed by cleaning table_list and adding proper error handling.
* | | | MDEV-24830 : Write a warning to error log if Galera replicates InnoDB table ↵bb-10.6-MDEV-24830Jan Lindström2021-02-221-4/+263
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with no primary key Two new features for Galera * Write a warning to error log if Galera replicates table with storage engine not supported by Galera (at the moment only InnoDB is supported ** Warning is pushed to client also ** MyISAM is allowed if wsrep_replicate_myisam=ON * Write a warning to error log if Galera replicates table with no primary key ** Warning is pushed to client also ** MyISAM is allowed if wsrep_relicate_myisam=ON * In both cases apply flood control if > 10 same warning is writen to error log (requires log_warnings > 1), flood control will suppress warnings for 300 seconds
* | | | Merge 10.5 into 10.6Marko Mäkelä2021-02-171-24/+15
|\ \ \ \ | |/ / /
| * | | Merge mariadb-10.5.9Marko Mäkelä2021-02-171-21/+5
| |\ \ \
| | * \ \ Merge branch 'bb-10.4-release' into bb-10.5-releaseSergei Golubchik2021-02-151-21/+5
| | |\ \ \ | | | | |/ | | | |/|
| | | * | updating @@wsrep_cluster_address deadlocksSergei Golubchik2021-02-141-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wsrep_cluster_address_update() causes LOCK_wsrep_slave_threads to be locked under LOCK_wsrep_cluster_config, while normally the order should be the opposite. Fix: don't protect @@wsrep_cluster_address value with the LOCK_wsrep_cluster_config, LOCK_global_system_variables is enough. Only protect wsrep reinitialization with the LOCK_wsrep_cluster_config. And make it use a local copy of the global @@wsrep_cluster_address. Also, introduce a helper function that checks whether wsrep_cluster_address is set and also asserts that it can be safely read by the caller.
| | | * | cleanup: THD::abort_current_cond_wait()Sergei Golubchik2021-02-121-12/+1
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * reuse the loop in THD::abort_current_cond_wait, don't duplicate it * find_thread_by_id should return whatever it has found, it's the caller's task not to kill COM_DAEMON (if the caller's a killer) and other minor changes
| * | | MDEV-24833 : Signal 11 on wsrep_can_run_in_toi at wsrep_mysqld.cc:1994Jan Lindström2021-02-121-4/+18
| |/ / | | | | | | | | | | | | | | | | | | Problem was that when engine substitution is allowd (e.g. sql_mode='') we must also check db_type. Additionally, we did not resolve default storage engine on that case and used that to check is TOI possible or not.
* | | MDEV-20008: Galera strict modebb-10.6-MDEV-20008mkaruza2021-01-261-11/+61
|/ / | | | | | | | | | | | | | | | | | | | | | | | | 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.4 into 10.5Marko Mäkelä2021-01-111-18/+21
|\ \ | |/
| * Update wsrep-lib (new logger interface)Alexey Yurchenko2021-01-071-17/+19
| | | | | | | | | | | | Ensure consistent use of logging macros in wsrep-related code Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | MDEV-24546 : AddressSanitizer: initialization-order-fiasco on address ... in ↵Jan Lindström2021-01-091-0/+1
| | | | | | | | | | | | | | | | 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 commit '10.4' into 10.5Oleksandr Byelkin2021-01-061-1/+3
|\ \ | |/
| * MDEV-23468: inline_mysql_socket_send: Assertion `mysql_socket.fd != -1' ↵mkaruza2020-12-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | failed on shutdown Closing remaining threads in `wsrep_close_client_connections` should also check `thd_is_connection_alive` for thd before closing connection. Assert is happening when thread already doing shutdown, but still not removed from threads list. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | Merge 10.4 into 10.5Marko Mäkelä2020-12-021-1/+1
|\ \ | |/
| * MDEV-15532 after-merge fixes from MontyMarko Mäkelä2020-12-021-1/+1
| | | | | | | | The Galera tests were massively failing with debug assertions.
* | Merge 10.4 into 10.5Marko Mäkelä2020-11-131-11/+65
|\ \ | |/
| * MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLEsjaakola2020-11-111-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A follow-up fix, for original fix for MDEV-21577, which did not handle well temporary tables. OPTIMIZE and REPAIR TABLE statements can take a list of tables as argument, and some of the tables may be temporary. Proper handling of temporary tables is to skip them and continue working on the real tables. The bad version, skipped all tables, if a single temporary table was in the argument list. And this resulted so that FK parent tables were not scnanned for the remaining real tables. Some mtr tests, using OPTIMIZE or REPAIR for temporary tables caused regressions bacause of this, e.g. galera.galera_optimize_analyze_multi The fix in this PR opens temporary and real tables first, and in the table handling loop skips temporary tables, FK parent scanning is done only for real tables. The test has new scenario for OPTIMIZE and REPAIR issued for two tables of which one is temporary table. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * MDEV-21577 MDL BF-BF conflictsjaakola2020-11-031-5/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some DDL statements appear to acquire MDL locks for a table referenced by foreign key constraint from the actual affected table of the DDL statement. OPTIMIZE, REPAIR and ALTER TABLE belong to this class of DDL statements. Earlier MariaDB version did not take this in consideration, and appended only affected table in the certification key list in write set. Because of missing certification information, it could happen that e.g. OPTIMIZE table for FK child table could be allowed to apply in parallel with DML operating on the foreign key parent table, and this could lead to unhandled MDL lock conflicts between two high priority appliers (BF). The fix in this patch, changes the TOI replication for OPTIMIZE, REPAIR and ALTER TABLE statements so that before the execution of respective DDL statement, there is foreign key parent search round. This FK parent search contains following steps: * open and lock the affected table (with permissive shared locks) * iterate over foreign key contstraints and collect and array of Fk parent table names * close all tables open for the THD and release MDL locks * do the actual TOI replication with the affected table and FK parent table names as key values The patch contains also new mtr test for verifying that the above mentioned DDL statements replicate without problems when operating on FK child table. The mtr test scenario #1, which can be used to check if some other DDL (on top of OPTIMIZE, REPAIR and ALTER) could cause similar excessive FK parent table locking. Reviewed-by: Aleksey Midenkov <aleksey.midenkov@mariadb.com> Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | MDEV-23638 : DROP TRIGGER in Galera Cluster not replicatingJan Lindström2020-09-081-0/+8
| | | | | | | | | | Drop trigger handling was missing from wsrep_can_run_in_toi in 10.5 for some reason.
* | Merge 10.4 into 10.5Marko Mäkelä2020-09-041-1/+8
|\ \ | |/
| * Merge 10.3 into 10.4Marko Mäkelä2020-09-031-1/+8
| |\
| | * MDEV-21578 : CREATE OR REPLACE TRIGGER in Galera cluster not replicatingJan Lindström2020-09-031-3/+6
| | | | | | | | | | | | In 10.3 OR REPLACE trigger option is part of create_info.
| | * Merge 10.2 into 10.3Marko Mäkelä2020-09-031-1/+5
| | |\
| | | * MDEV-21578 : CREATE OR REPLACE TRIGGER in Galera cluster not replicatingJan Lindström2020-08-281-1/+6
| | | | | | | | | | | | | | | | | | | | While doing TOI buffer OR REPLACE option was not added to replicated string.
| | * | Merge 10.2 into 10.3Marko Mäkelä2020-06-061-1/+8
| | |\ \ | | | |/
| | | * 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.
| | * | | Merge 10.2 into 10.3Marko Mäkelä2020-03-301-0/+11
| | |\ \ \ | | | |/ /
| | | * | 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.2' into 10.3Oleksandr Byelkin2020-01-241-1/+5
| | |\ \ \ | | | |/ /
| | | * | 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).
| | * | | Merge 10.2 into 10.3Marko Mäkelä2019-12-121-1/+2
| | |\ \ \ | | | |/ /
| | | * | 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 10.4 into 10.5Marko Mäkelä2020-08-201-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-22443 wsrep::runtime_error on START TRANSACTIONDaniele Sciascia2020-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happens with global wsrep_on disabled and local wsrep_on enabled. The fix consists in avoiding sync wait when global wsrep_on is disabled.
* | | | | Remove String::lex_string() and String::lex_cstring()Monty2020-07-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Better to use 'String *' directly. - Added String::get_value(LEX_STRING*) for the few cases where we want to convert a String to LEX_CSTRING. Other things: - Use StringBuffer for some functions to avoid mallocs
* | | | | MDEV-19749 MDL scalability regression after backup locksEugene Kosov2020-06-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | use ilist instread of I_P_List because it's generally slightly faster on inserting, removing and iterating
* | | | | Update galera to work with independent sub transactionsMonty2020-05-231-0/+1
| | | | |
* | | | | Performance improvements to test if WSREP if activeMonty2020-05-231-16/+21
| | | | |
* | | | | Move all thread cache specific code to a new classSergey Vojtovich2020-05-061-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Part of MDEV-18353 - Shutdown may miss to wait for connection thread
* | | | | MDEV-22437 make THR_THD* variable thread_localEugene Kosov2020-05-051-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now all access goes through _current_thd() and set_current_thd() functions. Some functions like THD::store_globals() can not fail now.
View Lorry Controller Status