summaryrefslogtreecommitdiff
path: root/mysql-test/suite/galera/r
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-293-76/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mutex order violation when wsrep bf thread kills a conflicting trx, the stack is wsrep_thd_LOCK() wsrep_kill_victim() lock_rec_other_has_conflicting() lock_clust_rec_read_check_and_lock() row_search_mvcc() ha_innobase::index_read() ha_innobase::rnd_pos() handler::ha_rnd_pos() handler::rnd_pos_by_record() handler::ha_rnd_pos_by_record() Rows_log_event::find_row() Update_rows_log_event::do_exec_row() Rows_log_event::do_apply_event() Log_event::apply_event() wsrep_apply_events() and mutexes are taken in the order lock_sys->mutex -> victim_trx->mutex -> victim_thread->LOCK_thd_data When a normal KILL statement is executed, the stack is innobase_kill_query() kill_handlerton() plugin_foreach_with_mask() ha_kill_query() THD::awake() kill_one_thread() and mutexes are victim_thread->LOCK_thd_data -> lock_sys->mutex -> victim_trx->mutex This patch is the plan D variant for fixing potetial mutex locking order exercised by BF aborting and KILL command execution. In this approach, KILL command is replicated as TOI operation. This guarantees total isolation for the KILL command execution in the first node: there is no concurrent replication applying and no concurrent DDL executing. Therefore there is no risk of BF aborting to happen in parallel with KILL command execution either. Potential mutex deadlocks between the different mutex access paths with KILL command execution and BF aborting cannot therefore happen. TOI replication is used, in this approach, purely as means to provide isolated KILL command execution in the first node. KILL command should not (and must not) be applied in secondary nodes. In this patch, we make this sure by skipping KILL execution in secondary nodes, in applying phase, where we bail out if applier thread is trying to execute KILL command. This is effective, but skipping the applying of KILL command could happen much earlier as well. This also fixed unprotected calls to wsrep_thd_abort that will use wsrep_abort_transaction. This is fixed by holding THD::LOCK_thd_data while we abort transaction. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* Merge 10.4 into 10.5Marko Mäkelä2021-10-211-8/+8
|\
| * Merge 10.3 into 10.4Marko Mäkelä2021-10-211-8/+8
| |\
| | * Merge 10.2 into 10.3Marko Mäkelä2021-10-211-8/+8
| | |\
| | | * MDEV-26815 : galera.galera_ftwrl_drain fails with wrong errno 1146bb-10.2-MDEV-26815-galeraJan Lindström2021-10-131-8/+8
| | | | | | | | | | | | | | | | Add wait_conditions to stabilize
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-10-135-87/+31
|\ \ \ \ | |/ / /
| * | | Update galera disabled.defJan Lindström2021-10-072-69/+0
| | | |
| * | | MDEV-22996 : Hang on galera_toi_truncate test caseJan Lindström2021-10-071-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | Actual problem was earlier fixed. This contains only test case change. We use debug_sync to force concurrent DML and TRUNCATE.
| * | | MDEV-24062 : Galera test failure on galera_var_replicate_myisam_onJan Lindström2021-10-071-3/+12
| | | | | | | | | | | | | | | | We should do after_statement only for local transactions.
| * | | Fix galera_var_reject_queries test caseJan Lindström2021-10-071-8/+3
| | | |
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-10-042-0/+67
|\ \ \ \ | |/ / /
| * | | Merge 10.3 into 10.4Marko Mäkelä2021-10-041-0/+56
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2021-10-041-0/+56
| | |\ \ | | | |/
| | | * MDEV-24978 crash with transaction on table with no PK and long fulltext columnbb-10.2-MDEV-24978-galerasjaakola2021-09-301-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a table has no unique indexes, write set key information will be collected on all columns in the table. The write set key information has space only for max 3500 bytes for individual column, and if a varchar colummn of such non-primary key table is longer than this limit, currently a crash follows. The fix in this commit, is to truncate key values extracted from such long varhar columns to max 3500 bytes. This may potentially lead to false positive certification failures for transactions, which operate on separate cluster nodes, and update/insert/delete table rows, which differ only in the part of such long columns after 3500 bytes border. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * | | MDEV-22708 Assertion `!mysql_bin_log.is_open() || ↵mkaruza2021-10-011-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thd.is_current_stmt_binlog_format_row()' failed in Delayed_insert::handle_inserts and in Diagnostics_area::set_eof_status Variable wsrep_forced_binlog_format has higher priority than binlog_format. In situation where STATEMENT is used and DELAYED INSERT is executing we should fall back to non-delay INSERT. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-09-302-28/+2
|\ \ \ \ | |/ / / | | | | | | | | | | | | FIXME: Part of the MDEV-20699 test is disabled due to nonderterministic result.
| * | | Merge 10.3 into 10.4Marko Mäkelä2021-09-291-28/+0
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2021-09-291-28/+0
| | |\ \ | | | |/
| | | * Remove test from galera_fulltext until MDEV-24978 is fixed.bb-10.2-jan-galeraJan Lindström2021-09-271-28/+0
| | | |
| * | | MDEV-21806 : galera.galera_partition MTR failed: failed to recover from ↵bb-10.4-MDEV-20451-galeraJan Lindström2021-09-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | DONOR state Add wait_condition to wait until all nodes are in cluster
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-09-241-28/+0
|\ \ \ \ | |/ / /
| * | | Merge 10.3 into 10.4Marko Mäkelä2021-09-241-28/+0
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2021-09-241-28/+0
| | |\ \ | | | |/
| | | * Revert MDEV-25114Marko Mäkelä2021-09-243-170/+16
| | | | | | | | | | | | | | | | | | | | | | | | Revert 88a4be75a5f3b8d59ac8f6347ff2c197813c05dc and 9d97f92febc89941784d17d59c60275e21140ce0, which had been prematurely pushed by accident.
| | | * Revert "MDEV-24978 : SIGABRT in __libc_message"bb-10.2-MDEV-24978-fJan Lindström2021-09-241-28/+0
| | | | | | | | | | | | | | | | This reverts commit 30dea4599e44e3008fb9bc5fe79ab5747841f21f.
| | | * MDEV-25114 Crash: WSREP: invalid state ROLLED_BACK (FATAL)sjaakola2021-09-243-16/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the plan D variant for fixing potetial mutex locking order exercised by BF aborting and KILL command execution. In this approach, KILL command is replicated as TOI operation. This guarantees total isolation for the KILL command execution in the first node: there is no concurrent replication applying and no concurrent DDL executing. Therefore there is no risk of BF aborting to happen in parallel with KILL command execution either. Potential mutex deadlocks between the different mutex access paths with KILL command execution and BF aborting cannot therefore happen. TOI replication is used, in this approach, purely as means to provide isolated KILL command execution in the first node. KILL command should not (and must not) be applied in secondary nodes. In this patch, we make this sure by skipping KILL execution in secondary nodes, in applying phase, where we bail out if applier thread is trying to execute KILL command. This is effective, but skipping the applying of KILL command could happen much earlier as well. This patch also fixes mutex locking order and unprotected THD member accesses on bf aborting case. We try to hold THD::LOCK_thd_data during bf aborting. Only case where it is not possible is at wsrep_abort_transaction before call wsrep_innobase_kill_one_trx where we take InnoDB mutexes first and then THD::LOCK_thd_data. This will also fix possible race condition during close_connection and while wsrep is disconnecting connections. Added wsrep_bf_kill_debug test case Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-09-241-0/+114
|\ \ \ \ | |/ / /
| * | | MDEV-26566 : galera.galera_var_cluster_address MTR failed: InnoDB: Assertion ↵Jan Lindström2021-09-231-0/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | failure in file row0ins.cc line 3206 Actual problem was that we tried to calculate persistent statistics to wsrep_schema tables in this case wsrep_streaming_log. These tables should not have persistent statistics. Therefore, in table creation tables should be created with STATS_PERSISTENT=0 table option. During rolling-upgrade tables naturally already exists, thus we need to alter them to contain STATS_PERSISTENT=0 table option.
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-09-172-0/+50
|\ \ \ \ | |/ / /
| * | | MDEV-19950 addendum: galera_ssl_upgrade removed from the list of disabled ↵bb-10.4-MDEV-19950-addendum-galeraJulius Goryavsky2021-09-171-0/+3
| | | | | | | | | | | | | | | | tests and adapted for 10.4+
| * | | MDEV-26053 : TRUNCATE on table with Foreign Key Constraint no longer ↵bb-10.4-truncateJan Lindström2021-09-171-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | replicated to other nodes Problem was that there was extra condition !thd->lex->no_write_to_binlog before call to begin TOI. It seems that this variable is not initialized. TRUNCATE does not support [NO_WRITE_TO_BINLOG | LOCAL] keywords, thus we should not check this condition. All this was hidden in a macro, so I decided to remove those macros that were used only a few places with actual function calls.
* | | | Merge remote-tracking branch 'upstream/10.4' into 10.5Vicențiu Ciorbaru2021-09-102-0/+63
|\ \ \ \ | |/ / /
| * | | post-merge fixSergei Golubchik2021-09-091-0/+2
| | | |
| * | | Merge remote-tracking branch 'upstream/10.3' into 10.4Vicențiu Ciorbaru2021-09-092-0/+61
| |\ \ \ | | |/ /
| | * | Merge branch '10.2' into 10.3Vicențiu Ciorbaru2021-09-072-0/+61
| | |\ \ | | | |/
| | | * MDEV-26518 ; Galera incorrectly handles primary or unique keys with any ↵bb-10.2-MDEV-26517Jan Lindström2021-09-022-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | multi-byte character set We need to set temporary buffer large enough to fit also multi-byte characters.
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-08-261-1/+2
|\ \ \ \ | |/ / /
| * | | After-merge fix f84e28c119b495da77e197f7cd18af4048fc3126Marko Mäkelä2021-08-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a rebase of the merge, two preceding commits were accidentally reverted: commit 112b23969a30ba6441efa5e22a3017435febfa17 (MDEV-26308) commit ac2857a5fbf851d90171ac55f23385869ee6ba83 (MDEV-25717) Thanks to Daniele Sciascia for noticing this.
* | | | Merge 10.4 into 10.5Marko Mäkelä2021-08-181-4/+14
|\ \ \ \ | |/ / /
| * | | Merge 10.3 into 10.4Marko Mäkelä2021-08-181-2/+1
| |\ \ \ | | |/ /
| * | | MDEV-26308 : Galera test failure on galera.galera_split_brainLeandro Pacheco2021-08-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Contains following fixes: * allow TOI commands to timeout while trying to acquire TOI with override lock_wait_timeout with a LONG_TIMEOUT only after succesfully entering TOI * only ignore lock_wait_timeout on TOI * fix galera_split_brain test as TOI operation now returns ER_LOCK_WAIT_TIMEOUT after lock_wait_timeout * explicitly test for TOI Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * | | Fix test failure on galera_as_slave_replay by adding wait_conditionsJan Lindström2021-08-061-4/+14
| | | |
* | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2021-07-315-3/+151
|\ \ \ \ | |/ / /
| * | | Merge branch '10.3' into 10.4Oleksandr Byelkin2021-07-311-0/+54
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2021-07-271-0/+52
| | |\ \ | | | |/
| | | * MDEV-26062 : InnoDB: WSREP: referenced FK check fail: Lock wait index ↵Jan Lindström2021-07-261-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `PRIMARY` table `schema`.`child_table` Problem was that not all normal error codes where not handled after wsrep_row_upd_check_foreign_constraints() call. Furhermore, debug assertion did not contain all normal error cases. Changed ib:: calls to WSREP_ calls to use wsrep instrumentation.
| | | * MDEV-26080 fixup: fixed .result file for galera_roles test (one word must be ↵Julius Goryavsky2021-07-231-2/+2
| | | | | | | | | | | | | | | | enclosed in single quotes).
| * | | MDEV-25740 Assertion `!wsrep_has_changes(thd) || (thd->lex->sql_command == ↵mkaruza2021-07-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row())' failed in void wsrep_commit_empty(THD*, bool) Using ROLLBACK with `completion_type = CHAIN` result in start of transaction and implicit commit before previous WSREP internal data is cleared. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * | | MDEV-22421 Galera assertion !wsrep_has_changes(thd) || ↵mkaruza2021-07-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (thd->lex->sql_command == SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row()) Updates to transaction registry table shouldn't be replicated in cluster so there is no need to append wsrep keys. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * | | MDEV-23080: desync and pause node on BACKUP STAGE BLOCK_DDLLeandro Pacheco2021-07-272-3/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make BACKUP STAGE behave as FTWRL, desyncing and pausing the node to prevent BF threads (appliers) from interfering with blocking stages. This is needed because BF threads don't respect BACKUP MDL locks. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
View Lorry Controller Status