summaryrefslogtreecommitdiff
path: root/sql/wsrep_hton.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.1 into 10.2Julius Goryavsky2020-06-051-5/+17
|\
| * MDEV-22763 backporting MDEV-20225 fix into 10.1sjaakola2020-06-031-5/+17
| | | | | | | | | | | | 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
* | MDEV-22021: Galera database could get inconsistent with rollback to savepointmkaruza2020-03-311-18/+6
| | | | | | | | | | | | When binlog is disabled, WSREP will not behave correctly when SAVEPOINT ROLLBACK is executed since we don't register handlers for such case. Fixed by registering WSREP handlerton for SAVEPOINT related commands.
* | MDEV-21473 conflicts with async slave BF aborting (#1475)seppo2020-03-241-4/+4
| | | | | | | | | | | | | | | | | | 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 Byelkin2019-12-031-2/+19
|\ \ | |/
| * MDEV-19572 async slave node fails to apply MyISAM only writes (#1418)seppo2019-11-261-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem happens when MariaDB master replicates writes for only non InnoDB tables (e.g. writes to MyISAM table(s)). Async slave node, in Galera cluster, can apply these writes successfully, but it will, in the end, write gtid position in mysql.gtid_slave_pos table. mysql.gtid_slave_pos table is InnoDB engine, and this write makes innodb handlerton part of the replicated "transaction". Note that wsrep patch identifies that write to gtid_slave_pos should not be replicated and skips appending wsrep keys for these writes. However, as InnoDB was present in the transaction, and there are replication events (for MyISAM table) in transaction cache, but there are no appended keys, wsrep raises an error, and this makes the söave thread to stop. The fix is simply to not treat it as an error if async slave tries to replicate a write set with binlog events, but no keys. We just skip wsrep replication and return successfully. This commit contains also a mtr test which forces mysql.gtid_slave_pos table isto be of InnoDB engine, and executes MyISAM only write through asyn replication. There is additional fix for declaring IO and background slave threads as non wsrep. These threads should not write anything for wsrep replication, and this is just a safeguard to make sure nothing leaks into cluster from these slave threads.
* | 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-17262: mysql crashed on galera while node rejoined cluster (#895)sysprg2019-03-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains a fix for the MDEV-17262/17243 issues and new mtr test. These issues (MDEV-17262/17243) have two reasons: 1) After an intermediate commit, a transaction loses its status of "transaction that registered in the MySQL for 2pc coordinator" (in the InnoDB) due to the fact that since version 10.2 the write_row() function (which located in the ha_innodb.cc) does not call trx_register_for_2pc(m_prebuilt->trx) during the processing of split transactions. It is necessary to restore this call inside the write_row() when an intermediate commit was made (for a split transaction). Similarly, we need to set the flag of the started transaction (m_prebuilt->sql_stat_start) after intermediate commit. The table->file->extra(HA_EXTRA_FAKE_START_STMT) called from the wsrep_load_data_split() function (which located in sql_load.cc) will also do this, but it will be too late. As a result, the call to the wsrep_append_keys() function from the InnoDB engine may be lost or function may be called with invalid transaction identifier. 2) If a transaction with the LOAD DATA statement is divided into logical mini-transactions (of the 10K rows) and binlog is rotated, then in rare cases due to the wsrep handler re-registration at the boundary of the split, the last portion of data may be lost. Since splitting of the LOAD DATA into mini-transactions is technical, I believe that we should not allow these mini-transactions to fall into separate binlogs. Therefore, it is necessary to prohibit the rotation of binlog in the middle of processing LOAD DATA statement. https://jira.mariadb.org/browse/MDEV-17262 and https://jira.mariadb.org/browse/MDEV-17243
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-2/+7
|\ \ | |/
| * Merge branch '10.0-galera' into 10.1Sergei Golubchik2018-09-071-2/+7
| |\
| | * MDEV-16799: Test wsrep.variables crash at sql_class.cc:639 thd_get_ha_dataJan Lindström2018-07-241-7/+14
| | | | | | | | | | | | | | | Problem was that binlog_hton was not initialized fully when needed i.e. when wsrep_on = true.
* | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-12/+24
|\ \ \ | |/ /
| * | Merge branch '10.0-galera' into 10.1Vicențiu Ciorbaru2018-06-121-12/+24
| |\ \ | | |/
| | * Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-05-071-13/+25
| | |\
| | | * MariaDB adjustments.Jan Lindström2018-04-241-24/+24
| | | |
| | | * Provider rollback for ineffective trxTeemu Ollakka2018-04-241-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | codership/mysql-wsrep#318 Adapt MTR tests to new Galera status variables and fix exposed leaks In certain cases it is possible that transaction has populated keys in the provider but during commit time the IO cache is empty, so the provider commit does not happen (for example early ROLLBACK TO SAVEPOINT followed by COMMIT). Run provider post_rollback() to clean up the transaction object.
| | | * MDEV-7129 : Galera duplicate error on autoincrement field primary keyNirbhay Choubey2015-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | Merged fix for https://github.com/codership/mysql-wsrep/issues/18.
| | | * Merge lp:codership-mysql/5.5 -r3961..3980.Jan Lindström2014-04-161-0/+6
| | | |
| | | * * Merged revisions 3945, 3946..3950, 3951..3961Nirbhay Choubey2014-02-281-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | from codership-mysql/5.5. * Merged changes in innobase to xtradb. * Updated WSREP_PATCH_REVNO.
| | | * Merging revisions 3934..3944 from codership-mysql/5.5.Nirbhay Choubey2014-02-031-2/+7
| | | |
| | | * Merging revision 3839..3932 from codership-mysql/5.5.Nirbhay Choubey2014-01-091-92/+81
| | | |
| | | * MDEV-5408: Crash in mariadb-wsrep during plugin load at startupJan Lindström2013-12-101-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis: If wsrep_provider is not specified ("none") the wsrep is not initialized. Fix: Add additional guard not to call wsrep->post_rollback if wsrep_provider is not specified.
| | | * Merged revisions 2925--3929 from from lp:~codership/codership-mysql/5.5-23Jan Lindström2013-11-251-54/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------ revno: 3929 [merge] fixes bug: https://launchpad.net/bugs/1243150 committer: Teemu Ollakka <teemu.ollakka@codership.com> branch nick: 5.5-23 timestamp: Wed 2013-10-23 20:05:01 +0300 message: 8kB/s - References lp:1243150 - initial wsrep hton cleanups * Removed wsrep_seqno_changed boolean * wsrep_cleanup_transaction() is now called explicitly whenever it is clear that transaction has come to an end * wsrep_trans_cache_is_empty() now checks from cache_mngr recardless of command type * Separated call to wsrep->post_commit() to own function, called from transaction.cc whenever appropriate * wsrep_thd_is_brute_force() now investigates only thd->wsrep_exec_mode * More comments and debug time assertions * Debug code to check that wsrep position stored in InnoDB is monotinically increasing. Enabled with UNIV_DEBUG ------------------------------------------------------------ revno: 3928 fixes bug: https://launchpad.net/bugs/1237889 committer: Teemu Ollakka <teemu.ollakka@codership.com> branch nick: 5.5-23 timestamp: Tue 2013-10-22 22:01:20 +0300 message: References lp:1237889 - reverting fix in r3926, it broke crash recovery ------------------------------------------------------------ revno: 3927 fixes bug: https://launchpad.net/bugs/1240040 committer: Teemu Ollakka <teemu.ollakka@codership.com> branch nick: 5.5-23 timestamp: Tue 2013-10-15 14:46:15 +0300 message: References lp:1240040 - added WSREP_MYSQL_DB as a key for DROP VIEW ------------------------------------------------------------ revno: 3926 fixes bug: https://launchpad.net/bugs/1237889 committer: Teemu Ollakka <teemu.ollakka@codership.com> branch nick: 5.5-23 timestamp: Thu 2013-10-10 14:22:58 +0300 message: References lp:1237889 - register wsrep hton only if thd->wsrep_exec_mode == LO CAL_STATE ------------------------------------------------------------ revno: 3925 fixes bug: https://launchpad.net/bugs/1235635 committer: Alexey Yurchenko <alexey.yurchenko@codership.com> branch nick: 5.5-23 timestamp: Sat 2013-10-05 18:03:06 +0300 message: References lp:1235635 - fixed the warning by initializing c_lock to NULL.
| | | * Merge revisions 3907--3914 from lp:~codership/codership-mysql/5.5-23Jan Lindström2013-09-261-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------ revno: 3914 3kB/s | committer: Vladislav Klyachin <vladislav.klyachin@codership.com> branch nick: 5.5-23 timestamp: Thu 2013-09-12 15:00:46 +0400 message: References lp:1217653 - fix index-id evaluation of FOREIGN KEY, when referenced table without PRIMARY KEY ------------------------------------------------------------ revno: 3913 committer: Vladislav Klyachin <vladislav.klyachin@codership.com> branch nick: 5.5-23 timestamp: Wed 2013-09-11 13:58:02 +0400 message: References lp:1217653 - fix index-id evaluation of FOREIGN KEY, when referenced table without PRIMARY KEY ------------------------------------------------------------ revno: 3912 committer: Seppo Jaakola <seppo.jaakola@codership.com> branch nick: wsrep-5.5-23 timestamp: Fri 2013-09-06 13:13:48 +0300 message: References: lp:1212955 - releasing MDL after failed BEGIN and "SET AUTOCOMMIT" ------------------------------------------------------------ revno: 3911 committer: Seppo Jaakola <seppo.jaakola@codership.com> branch nick: wsrep-5.5-23 timestamp: Wed 2013-09-04 10:52:31 +0300 message: References: lp:1123233 - avoiding to set wsrep_seqno_changed for replaying transactions Note, also missing transactions don't declare seqno_changed anymore. Earlier they would have caused crash at wsrep_cleanup_transaction phase. ------------------------------------------------------------ revno: 3910 [merge] committer: Vladislav Klyachin <vladislav.klyachin@codership.com> branch nick: 5.5-23 timestamp: Tue 2013-09-03 15:27:02 +0400 message: References lp:1049599 - expose desync functionality to the client ------------------------------------------------------------ revno: 3909 committer: Seppo Jaakola <seppo.jaakola@codership.com> branch nick: wsrep-5.5-23 timestamp: Tue 2013-09-03 09:41:08 +0300 message: References: lp:1123233 - rollback for transaction which has not appended key information ------------------------------------------------------------ revno: 3908 committer: Vladislav Klyachin <vladislav.klyachin@codership.com> branch nick: 5.5-23 timestamp: Sun 2013-09-01 13:29:12 +0400 message: lp:1201893 - fix command for default IP address ------------------------------------------------------------ revno: 3907 committer: Seppo Jaakola <seppo.jaakola@codership.com> branch nick: wsrep-5.5-23 timestamp: Thu 2013-08-29 12:16:42 +0300 message: References: lp:1212955 - releasing transactional MDL locks after commit failures (e.g. certification failure).
| | | * Merged with lp:~codership/codership-mysql/5.5-23, up to revision 3903Seppo Jaakola2013-08-211-1/+6
| | | |
| | | * References: MDEV-4572 - merge with lp:codership-mysql/5.5-23 revisions ↵Seppo Jaakola2013-05-251-0/+1
| | | | | | | | | | | | | | | | 3858..3867
| | | * merged in revisions 3853..3857 from lp:codership-mysql/5.5-23Seppo Jaakola2013-05-211-0/+5
| | | |
| | | * fixes for the merge with codership-mysql, revision 3839Seppo Jaakola2013-02-051-1/+1
| | | |
| | | * merged with codership-mysql up to revision 3839Seppo Jaakola2013-02-051-1/+7
| | | | | | | | | | | | | | | | | | | | bzr merge -r3810..3839 lp:codership-mysql/5.5
| | | * remerging wsrep files from lp:codership-mysqlSeppo Jaakola2013-02-051-0/+449
| | | |
| | | * re-merging wsrep files from lp:codership-mysqlSeppo Jaakola2013-02-051-449/+0
| | | |
| | | * References lp:1066784Seppo Jaakola2012-10-231-0/+9
| | | | | | | | | | | | | | | | | | | | merged with patch: bzr diff lp:codership-mysql/5.5 -r3795..3809
| | | * References lp:1034621 - Merge up to mysql-5.5.25 levelSeppo Jaakola2012-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | merged codership-mysql/5.5 revisions: bzr diff -r3759..3767 merged codership-mysql/5.5 revisions: bzr diff -r3768..3771
| | | * References lp:1011983Seppo Jaakola2012-06-121-2/+9
| | | | | | | | | | | | | | | | | | | | Merged from codership-mysql/5.5 changes revisions 3743-3756
| | | * Merged changes from lp:codership-mysql up to rev 3743Seppo Jaakola2012-04-261-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | -r3725..3737 -r3738..3740 -r3741..3743
| | | * Added wsrep specific filesSeppo Jaakola2012-04-261-0/+419
| | |
* | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-101-22/+22
|\ \ \ | |/ /
| * | MDEV-16005 sporadic failures with galera tests MW-328B and MW-328Csjaakola2018-04-241-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | MDEV-14875: galera_new_cluster crashes mysqld when existing server contains ↵Jan Lindström2018-03-191-4/+4
| | | | | | | | | | | | | | | | | | databases Fortify wsrep_hton so that wsrep calls are not done to NULL-pointers.
* | | MDEV-14875: galera_new_cluster crashes mysqld when existing server contains ↵Jan Lindström2018-01-301-4/+4
| | | | | | | | | | | | | | | | | | databases Fortify wsrep_hton so that wsrep calls are not done to NULL-pointers.
* | | Merge branch '10.1' into 10.2Sergei Golubchik2017-11-211-0/+3
|\ \ \ | |/ /
| * | Merge branch 'github/10.0-galera' into 10.1Sergei Golubchik2017-11-101-0/+3
| |\ \ | | |/
| | * MW-402 cascading FK issuessjaakola2017-11-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | * created tests focusing in multi-master conflicts during cascading foreign key processing * in row0upd.cc, calling wsrep_row_ups_check_foreign_constraints only when running in cluster * in row0ins.cc fixed regression from MW-369, which caused crash with MW-402.test
* | | Merge 10.1 into 10.2Marko Mäkelä2017-09-181-0/+1
|\ \ \ | |/ /
| * | Silence a -Wimplicit-fallthrough warningMarko Mäkelä2017-09-171-0/+1
| | |
* | | Merge 10.1 into 10.2Marko Mäkelä2017-08-311-0/+1
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For running the Galera tests, the variable my_disable_leak_check was set to true in order to avoid assertions due to memory leaks at shutdown. Some adjustments due to MDEV-13625 (merge InnoDB tests from MySQL 5.6) were performed. The most notable behaviour changes from 10.0 and 10.1 are the following: * innodb.innodb-table-online: adjustments for the DROP COLUMN behaviour change (MDEV-11114, MDEV-13613) * innodb.innodb-index-online-fk: the removal of a (1,NULL) record from the result; originally removed in MySQL 5.7 in the Oracle Bug #16244691 fix https://github.com/mysql/mysql-server/commit/377774689bf6a16af74182753fe950d514c2c6dd * innodb.create-index-debug: disabled due to MDEV-13680 (the MySQL Bug #77497 fix was not merged from 5.6 to 5.7.10) * innodb.innodb-alter-autoinc: MariaDB 10.2 behaves like MySQL 5.6/5.7, while MariaDB 10.0 and 10.1 assign different values when auto_increment_increment or auto_increment_offset are used. Also MySQL 5.6/5.7 exhibit different behaviour between LGORITHM=INPLACE and ALGORITHM=COPY, so something needs to be tested and fixed in both MariaDB 10.0 and 10.2. * innodb.innodb-wl5980-alter: disabled because it would trigger an InnoDB assertion failure (MDEV-13668 may need additional effort in 10.2)
| * | Merge remote-tracking branch 'origin/10.0-galera' into 10.1Jan Lindström2017-08-211-0/+1
| |\ \ | | |/
| | * Refs: MW-360 * splitting DROP TABLE query in separate DROP commands for ↵sjaakola2017-08-111-0/+1
| | | | | | | | | | | | temporary and real tables * not replicating temporary table DROP command * using wsrep_sidno GTID group only for innodb table drop command part all this follows more or less the logic of how mysql wants to split drop table list
| | * refs: MW-319sjaakola2017-03-141-1/+1
| | | | | | | | | | | | | | | * silenced the WSREP_ERROR, this fires for all replication filtered DDL, and is false positive
View Lorry Controller Status