mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-27 09:14:17 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/sql/wsrep_trans_observer.h

609 lines
18 KiB
C
Raw Permalink Normal View History

MDEV-25045 : Assertion `client_state_.mode() != wsrep::client_state::m_toi' failed in int wsrep::transaction::before_commit() CREATE [TEMPORARY] SEQUENCE is internally CREATE+INSERT (initial value) and it is replicated using statement based replication. In Galera we use either TOI or RSU so we should skip commit time hooks for it. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-03-31 12:48:13 +02:00
/* Copyright 2016-2023 Codership Oy <http://www.codership.com>
Galera4
2019-01-23 15:30:00 +04:00
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Fix the FSF address to match the current one in: http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
2022-02-27 04:28:27 +01:00
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA */
Galera4
2019-01-23 15:30:00 +04:00
#ifndef WSREP_TRANS_OBSERVER_H
#define WSREP_TRANS_OBSERVER_H
#include "my_global.h"
#include "mysql/service_wsrep.h"
#include "wsrep_applier.h" /* wsrep_apply_error */
#include "wsrep_xid.h"
#include "wsrep_thd.h"
10.4 wsrep group commit fixes (#1224) * MDEV-16509 Improve wsrep commit performance with binlog disabled Release commit order critical section early after trx_commit_low() if binlog is not transaction coordinator. In order to avoid two phase commit, binlog_hton is not registered for THD during IO_CACHE population. Implemented a test which verifies that the transactions release commit order early. This optimization will change behavior during recovery as the commit is not two phase when binlog is off. Fixed and recorded wsrep-recover-v25 and wsrep-recover to match the behavior. * MDEV-18730 Ordering for wsrep binlog group commit Previously out of order execution was allowed for wsrep commits. Established proper ordering by populating wait_for_commit for every wsrep THD and making group commit leader to wait for prior commits before proceeding to trx_group_commit_leader(). * MDEV-18730 Added a test case to verify correct commit ordering * MDEV-16509, MDEV-18730 Review fixes Use WSREP_EMULATE_BINLOG() macro to decide if the binlog_hton should be registered. Whitespace/syntax fixes and cleanups. * MDEV-16509 Require binlog for galera_var_innodb_disallow_writes test If the commit to InnoDB is done in one phase, the native InnoDB behavior is that the transaction is committed in memory before it is persisted to disk. This means that the innodb_disallow_writes=ON may not prevent transaction to become visible to other readers before commit is completely over. On the other hand, if the commit is two phase (as it is with binlog), the transaction will be blocked in prepare phase. Fixed the test to use binlog, which enforces two phase commit, which in turn makes commit to block before the changes become visible to other connections. This guarantees that the test produces expected result.
2019-03-15 07:09:13 +02:00
#include "wsrep_binlog.h" /* register/deregister group commit */
Galera4
2019-01-23 15:30:00 +04:00
#include "my_dbug.h"
class THD;
Decrease stack space usage of mysql_execute_command() The extensive usage of stack space, especially when used with ASan (AdressSanitizer) of mysql_execute_command caused the test rpl.rpl_row_sp011 to fail because it did run out of stack. In this test case mysql_execute_command is called recursively for each function all. Changes done: - Changed a few functions that used big local variables to be marked __attribute__ ((noinline)) - Moved sub parts that used big local variables to external functions. - Changed wsrep_commit_empty() from inline to normal function as this used more than 1K of stack space and because there is no reason for this rarely used function to be inline. End result (with gcc 7.4.1 on Intel Xeon): Starting point for stack space usage: gcc -O: 7800 gcc with -fsanitize=address -O (ASan) : 27240 After this patch: gcc -O: 1160 gcc -O0 (debug build) 1584 gcc with -fsanitize=address -O (ASan): 4424 gcc with -fsanitize=address -O2 (ASan): 3874 A 6x improvement and will allow us to run all mtr tests with ASan.
2019-08-17 17:05:46 +03:00
void wsrep_commit_empty(THD* thd, bool all);
Galera4
2019-01-23 15:30:00 +04:00
/*
Return true if THD has active wsrep transaction.
*/
static inline bool wsrep_is_active(THD* thd)
{
return (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
thd->wsrep_cs().transaction().active() &&
!thd->internal_transaction());
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
}
/*
Return true if transaction is ordered.
*/
static inline bool wsrep_is_ordered(THD* thd)
{
return thd->wsrep_trx().ordered();
}
/*
Return true if transaction has been BF aborted but has not been
rolled back yet.
It is required that the caller holds thd->LOCK_thd_data.
*/
static inline bool wsrep_must_abort(THD* thd)
{
mysql_mutex_assert_owner(&thd->LOCK_thd_data);
return (thd->wsrep_trx().state() == wsrep::transaction::s_must_abort);
}
Fixed wsrep replaying for stored procedures (#1256) - Changed replaying to always allocate a separate THD object for applying log events. This is to avoid tampering original THD state during replay process. - Return success from sp_instr_stmt::exec_core() if replaying succeeds. - Do not push warnings/errors into diagnostics area if the transaction must be replayed. This is to avoid reporting transient errors to the client. Added two tests galera_sp_bf_abort, galera_sp_insert_parallel. Wsrep-lib position updated.
2019-04-06 12:33:51 +03:00
/*
Return true if the transaction must be replayed.
*/
static inline bool wsrep_must_replay(THD* thd)
{
return (thd->wsrep_trx().state() == wsrep::transaction::s_must_replay);
}
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
/*
Return true if transaction has not been committed.
Note that we don't require thd->LOCK_thd_data here. Calling this method
makes sense only from codepaths which are past ordered_commit state
and the wsrep transaction is immune to BF aborts at that point.
*/
static inline bool wsrep_not_committed(THD* thd)
{
return (thd->wsrep_trx().state() != wsrep::transaction::s_committed);
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Return true if THD is either committing a transaction or statement
is autocommit.
*/
static inline bool wsrep_is_real(THD* thd, bool all)
{
Change THD->transaction to a pointer to enable multiple transactions All changes (except one) is of type thd->transaction. -> thd->transaction-> thd->transaction points by default to 'thd->default_transaction' This allows us to 'easily' have multiple active transactions for a THD object, like when reading data from the mysql.proc table
2020-05-04 14:20:14 +03:00
return (all || thd->transaction->all.ha_list == 0);
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Check if a transaction has generated changes.
*/
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
static inline bool wsrep_has_changes(THD* thd)
Galera4
2019-01-23 15:30:00 +04:00
{
MDEV-31272 Statement rollback causes empty writeset replication This patch fixes cases where a transaction caused empty writeset to be replicated. This could happen in the case where a transaction executes a statement that initially manages to modify some data and therefore appended keys some for certification. The statement is however rolled back at some later stage due to some error (for example, a duplicate key error). After statement rollback the transaction is still alive, has no other changes. When committing such transaction, an empty writeset was replicated through Galera. The fix is to avoid calling into commit hook only when transaction has appended one or keys for certification *and* has some data in binlog cache to replicate. Otherwise, the commit is considered empty, and goes through usual empty commit path. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-10-12 15:40:13 +02:00
// Transaction has changes to replicate if it
// has appended one or more certification keys,
// and has actual changes to replicate in binlog
// cache. Except for streaming replication,
// where commit message may have no payload.
return !thd->wsrep_trx().is_empty() &&
(!wsrep_is_binlog_cache_empty(thd) || thd->wsrep_trx().is_streaming());
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Check if an active transaction has been BF aborted.
*/
static inline bool wsrep_is_bf_aborted(THD* thd)
{
return (thd->wsrep_trx().active() && thd->wsrep_trx().bf_aborted());
}
static inline int wsrep_check_pk(THD* thd)
{
if (!wsrep_certify_nonPK)
{
for (TABLE* table= thd->open_tables; table != NULL; table= table->next)
{
if (table->key_info == NULL || table->s->primary_key == MAX_KEY)
{
WSREP_DEBUG("No primary key found for table %s.%s",
table->s->db.str, table->s->table_name.str);
wsrep_override_error(thd, ER_LOCK_DEADLOCK);
return 1;
}
}
}
return 0;
}
static inline bool wsrep_streaming_enabled(THD* thd)
{
return (thd->wsrep_sr().fragment_size() > 0);
}
MDEV-18585 Avoid excessive Annotate_rows_log_events in binlog Make sure that the Annotate_rows_log_events is written into binlog only for the first fragment of the current statement. Also avoid flusing pending rows event when calculating bytes generated by the transaction. Added and recorded a test which verifies that the binlog contains only one Annotate_rows_log_event per statement with various SR settings. Recrded mysql-wsrep-features#136 which produced different output with excession log events suppressed.
2019-02-14 23:49:07 +02:00
/*
Fix various spelling errors e.g. - dont -> don't - occurence -> occurrence - succesfully -> successfully - easyly -> easily Also remove trailing space in selected files. These changes span: - server core - Connect and Innobase storage engine code - OQgraph, Sphinx and TokuDB storage engines Related to MDEV-21769.
2020-03-04 18:30:08 +02:00
Return number of fragments successfully certified for the
MDEV-18585 Avoid excessive Annotate_rows_log_events in binlog Make sure that the Annotate_rows_log_events is written into binlog only for the first fragment of the current statement. Also avoid flusing pending rows event when calculating bytes generated by the transaction. Added and recorded a test which verifies that the binlog contains only one Annotate_rows_log_event per statement with various SR settings. Recrded mysql-wsrep-features#136 which produced different output with excession log events suppressed.
2019-02-14 23:49:07 +02:00
current statement.
*/
static inline size_t wsrep_fragments_certified_for_stmt(THD* thd)
{
return thd->wsrep_trx().fragments_certified_for_statement();
}
Galera4
2019-01-23 15:30:00 +04:00
static inline int wsrep_start_transaction(THD* thd, wsrep_trx_id_t trx_id)
{
MDEV-22055: Assertion `active() == false' failed in wsrep::transaction::start_transaction upon ROLLBACK AND CHAIN The optional AND CHAIN clause is a convenience for initiating a new transaction as soon as the old transaction terminates. Therefore, do not start new transaction if it is already started at wsrep_start_transaction.
2020-08-24 14:09:40 +03:00
if (thd->wsrep_cs().state() != wsrep::client_state::s_none) {
if (wsrep_is_active(thd) == false)
return thd->wsrep_cs().start_transaction(wsrep::transaction_id(trx_id));
}
return 0;
Galera4
2019-01-23 15:30:00 +04:00
}
/**/
static inline int wsrep_start_trx_if_not_started(THD* thd)
{
int ret= 0;
DBUG_ASSERT(thd->wsrep_next_trx_id() != WSREP_UNDEFINED_TRX_ID);
DBUG_ASSERT(thd->wsrep_cs().mode() == Wsrep_client_state::m_local);
if (thd->wsrep_trx().active() == false)
{
ret= wsrep_start_transaction(thd, thd->wsrep_next_trx_id());
}
return ret;
}
/*
Called after each row operation.
Return zero on succes, non-zero on failure.
*/
Only apply wsrep_trx_fragment_size to InnoDB tables MDEV-22617 Galera node crashes when trying to log to slow_log table in streaming replication mode Other things: - Changed name of wsrep_after_row(two arguments) to wsrep_after_row_internal(one argument) to not depended on the function signature with unused arguments.
2020-05-19 20:15:00 +03:00
static inline int wsrep_after_row_internal(THD* thd)
Galera4
2019-01-23 15:30:00 +04:00
{
if (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
wsrep_thd_is_local(thd))
{
if (wsrep_check_pk(thd))
{
return 1;
}
else if (wsrep_streaming_enabled(thd))
{
return thd->wsrep_cs().after_row();
}
}
return 0;
}
/*
Helper method to determine whether commit time hooks
should be run for the transaction.
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
Commit hooks must be run in the following cases:
- The transaction is local and has generated write set and is committing.
- The transaction has been BF aborted
- Is running in high priority mode and is ordered. This can be replayer,
applier or storage access.
Galera4
2019-01-23 15:30:00 +04:00
*/
static inline bool wsrep_run_commit_hook(THD* thd, bool all)
{
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ENTER("wsrep_run_commit_hook");
DBUG_PRINT("wsrep", ("Is_active: %d is_real %d has_changes %d is_applying %d "
"is_ordered: %d",
wsrep_is_active(thd), wsrep_is_real(thd, all),
wsrep_has_changes(thd), wsrep_thd_is_applying(thd),
wsrep_is_ordered(thd)));
MDEV-24912 : Assertion `state() == s_executing || state() == s_prepared || state() == s_committing || state() == s_must_abort || state() == s_replaying' failed. CACHE INDEX and LOAD INDEX INTO CACHE are local operations. Therefore, do not replicate them with Galera. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-08-08 07:43:37 +03:00
/* skipping non-wsrep threads */
if (!WSREP(thd))
DBUG_RETURN(false);
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
/* Is MST commit or autocommit? */
bool ret= wsrep_is_active(thd) && wsrep_is_real(thd, all);
MDEV-18832 Galera: 10.4 node crashed with Assertion `state() == s_committing' if you create SEQUENCE, use it, then drop and recreate and use again (#1339) We could still end committing to binlog even in rollback. Do not proceed with WSREP commit in this case.
2019-06-18 11:36:29 +02:00
/* Do not commit if we are aborting */
ret= ret && (thd->wsrep_trx().state() != wsrep::transaction::s_aborting);
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
if (ret && !(wsrep_has_changes(thd) || /* Has generated write set */
/* Is high priority (replay, applier, storage) and the
transaction is scheduled for commit ordering */
(wsrep_thd_is_applying(thd) && wsrep_is_ordered(thd))))
{
mysql_mutex_lock(&thd->LOCK_thd_data);
DBUG_PRINT("wsrep", ("state: %s",
wsrep::to_c_string(thd->wsrep_trx().state())));
/* Transaction is local but has no changes, the commit hooks will
be skipped and the wsrep transaction is terminated in
wsrep_commit_empty() */
if (thd->wsrep_trx().state() == wsrep::transaction::s_executing)
{
ret= false;
}
mysql_mutex_unlock(&thd->LOCK_thd_data);
}
MDEV-25045 : Assertion `client_state_.mode() != wsrep::client_state::m_toi' failed in int wsrep::transaction::before_commit() CREATE [TEMPORARY] SEQUENCE is internally CREATE+INSERT (initial value) and it is replicated using statement based replication. In Galera we use either TOI or RSU so we should skip commit time hooks for it. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-03-31 12:48:13 +02:00
mysql_mutex_lock(&thd->LOCK_thd_data);
/* Transaction creating sequence is TOI or RSU,
MDEV-31335 : Create sequence can cause inconsistency Do not start TOI for CREATE TEMPORARY SEQUENCE because object is local only and not replicated. Similarly, avoid starting RSU for TEMPORARY SEQUENCEs. Finally, we need to run commit hooks for TEMPORARY SEQUENCEs because CREATE TEMPORARY SEQUENCE does implicit commit for previous changes that need to be replicated and committed. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-05-25 15:26:46 +03:00
CREATE SEQUENCE = CREATE + INSERT (initial value)
MDEV-25045 : Assertion `client_state_.mode() != wsrep::client_state::m_toi' failed in int wsrep::transaction::before_commit() CREATE [TEMPORARY] SEQUENCE is internally CREATE+INSERT (initial value) and it is replicated using statement based replication. In Galera we use either TOI or RSU so we should skip commit time hooks for it. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-03-31 12:48:13 +02:00
and replicated using statement based replication, thus
MDEV-31335 : Create sequence can cause inconsistency Do not start TOI for CREATE TEMPORARY SEQUENCE because object is local only and not replicated. Similarly, avoid starting RSU for TEMPORARY SEQUENCEs. Finally, we need to run commit hooks for TEMPORARY SEQUENCEs because CREATE TEMPORARY SEQUENCE does implicit commit for previous changes that need to be replicated and committed. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-05-25 15:26:46 +03:00
the commit hooks will be skipped.
For TEMPORARY SEQUENCES commit hooks will be done as
CREATE + INSERT is not replicated and needs to be
committed locally. */
MDEV-25045 : Assertion `client_state_.mode() != wsrep::client_state::m_toi' failed in int wsrep::transaction::before_commit() CREATE [TEMPORARY] SEQUENCE is internally CREATE+INSERT (initial value) and it is replicated using statement based replication. In Galera we use either TOI or RSU so we should skip commit time hooks for it. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-03-31 12:48:13 +02:00
if (ret &&
(thd->wsrep_cs().mode() == wsrep::client_state::m_toi ||
thd->wsrep_cs().mode() == wsrep::client_state::m_rsu) &&
MDEV-31335 : Create sequence can cause inconsistency Do not start TOI for CREATE TEMPORARY SEQUENCE because object is local only and not replicated. Similarly, avoid starting RSU for TEMPORARY SEQUENCEs. Finally, we need to run commit hooks for TEMPORARY SEQUENCEs because CREATE TEMPORARY SEQUENCE does implicit commit for previous changes that need to be replicated and committed. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-05-25 15:26:46 +03:00
thd->lex->sql_command == SQLCOM_CREATE_SEQUENCE &&
!thd->lex->tmp_table())
MDEV-25045 : Assertion `client_state_.mode() != wsrep::client_state::m_toi' failed in int wsrep::transaction::before_commit() CREATE [TEMPORARY] SEQUENCE is internally CREATE+INSERT (initial value) and it is replicated using statement based replication. In Galera we use either TOI or RSU so we should skip commit time hooks for it. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-03-31 12:48:13 +02:00
ret= false;
mysql_mutex_unlock(&thd->LOCK_thd_data);
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_PRINT("wsrep", ("return: %d", ret));
DBUG_RETURN(ret);
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Called before the transaction is prepared.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_before_prepare(THD* thd, bool all)
{
DBUG_ENTER("wsrep_before_prepare");
WSREP_DEBUG("wsrep_before_prepare: %d", wsrep_is_real(thd, all));
int ret= 0;
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(wsrep_run_commit_hook(thd, all));
MDEV-28053 Sysbench data load crashes Galera secondary node in async master slave setup This patch fixes a problem that arises when a Galera node acts as a replica for native replication. When parallel applying is enabled, it is possible to end up with attempts to write binlog events with gtids out of order. This happens because when multiple events are delivered from the native replication stream and applied in concurrently, it is for them to be replicated to the Galera cluster in an order which is different from the original order in which they were committed in the aync replication master. To correct this behavior we now wait_for_prior_commit() before replicating changes though galera. As a consequence, parallel appliers may apply events in parallel until the galera replication step, which is now serialized.
2022-05-11 14:33:20 +02:00
if ((ret= thd->wsrep_parallel_slave_wait_for_prior_commit()))
{
DBUG_RETURN(ret);
}
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
if ((ret= thd->wsrep_cs().before_prepare()) == 0)
Galera4
2019-01-23 15:30:00 +04:00
{
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(!thd->wsrep_trx().ws_meta().gtid().is_undefined());
wsrep_xid_init(&thd->wsrep_xid,
Galera GTID support 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.
2019-04-01 13:23:05 +02:00
thd->wsrep_trx().ws_meta().gtid(),
wsrep_gtid_server.gtid());
Galera4
2019-01-23 15:30:00 +04:00
}
MDEV-29293 MariaDB stuck on starting commit state This commit contains a merge from 10.5-MDEV-29293-squash into 10.6. Although the bug MDEV-29293 was not reproducible with 10.6, the fix contains several improvements for wsrep KILL query and BF abort handling, and addresses the following issues: * MDEV-30307 KILL command issued inside a transaction is problematic for galera replication: This commit will remove KILL TOI replication, so Galera side transaction context is not lost during KILL. * MDEV-21075 KILL QUERY maintains nodes data consistency but breaks GTID sequence: This is fixed as well as KILL does not use TOI, and thus does not change GTID state. * MDEV-30372 Assertion in wsrep-lib state: This was caused by BF abort or KILL when local transaction was in the middle of group commit. This commit disables THD::killed handling during commit, so the problem is avoided. * MDEV-30963 Assertion failure !lock.was_chosen_as_deadlock_victim in trx0trx.h:1065: The assertion happened when the victim was BF aborted via MDL while it was committing. This commit changes MDL BF aborts so that transactions which are committing cannot be BF aborted via MDL. The RQG grammar attached in the issue could not reproduce the crash anymore. Original commit message from 10.5 fix: MDEV-29293 MariaDB stuck on starting commit state The problem seems to be a deadlock between KILL command execution and BF abort issued by an applier, where: * KILL has locked victim's LOCK_thd_kill and LOCK_thd_data. * Applier has innodb side global lock mutex and victim trx mutex. * KILL is calling innobase_kill_query, and is blocked by innodb global lock mutex. * Applier is in wsrep_innobase_kill_one_trx and is blocked by victim's LOCK_thd_kill. The fix in this commit removes the TOI replication of KILL command and makes KILL execution less intrusive operation. Aborting the victim happens now by using awake_no_mutex() and ha_abort_transaction(). If the KILL happens when the transaction is committing, the KILL operation is postponed to happen after the statement has completed in order to avoid KILL to interrupt commit processing. Notable changes in this commit: * wsrep client connections's error state may remain sticky after client connection is closed. This error message will then pop up for the next client session issuing first SQL statement. This problem raised with test galera.galera_bf_kill. The fix is to reset wsrep client error state, before a THD is reused for next connetion. * Release THD locks in wsrep_abort_transaction when locking innodb mutexes. This guarantees same locking order as with applier BF aborting. * BF abort from MDL was changed to do BF abort on server/wsrep-lib side first, and only then do the BF abort on InnoDB side. This removes the need to call back from InnoDB for BF aborts which originate from MDL and simplifies the locking. * Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h. The manipulation of the wsrep_aborter can be done solely on server side. Moreover, it is now debug only variable and could be excluded from optimized builds. * Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more fine grained locking for SR BF abort which may require locking of victim LOCK_thd_kill. Added explicit call for wsrep_thd_kill_LOCK/UNLOCK where appropriate. * Wsrep-lib was updated to version which allows external locking for BF abort calls. Changes to MTR tests: * Disable galera_bf_abort_group_commit. This test is going to be removed (MDEV-30855). * Make galera_var_retry_autocommit result more readable by echoing cases and expectations into result. Only one expected result for reap to verify that server returns expected status for query. * Record galera_gcache_recover_manytrx as result file was incomplete. Trivial change. * Make galera_create_table_as_select more deterministic: Wait until CTAS execution has reached MDL wait for multi-master conflict case. Expected error from multi-master conflict is ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open wsrep transaction when it is waiting for MDL, query gets interrupted instead of BF aborted. This should be addressed in separate task. * A new test galera_bf_abort_registering to check that registering trx gets BF aborted through MDL. * A new test galera_kill_group_commit to verify correct behavior when KILL is executed while the transaction is committing. Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi> Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com> Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-04-19 16:51:55 +03:00
mysql_mutex_lock(&thd->LOCK_thd_kill);
if (thd->killed) wsrep_backup_kill_for_commit(thd);
mysql_mutex_unlock(&thd->LOCK_thd_kill);
Galera4
2019-01-23 15:30:00 +04:00
DBUG_RETURN(ret);
}
/*
Called after the transaction has been prepared.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_after_prepare(THD* thd, bool all)
{
DBUG_ENTER("wsrep_after_prepare");
WSREP_DEBUG("wsrep_after_prepare: %d", wsrep_is_real(thd, all));
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(wsrep_run_commit_hook(thd, all));
int ret= thd->wsrep_cs().after_prepare();
Galera4
2019-01-23 15:30:00 +04:00
DBUG_ASSERT(ret == 0 || thd->wsrep_cs().current_error() ||
thd->wsrep_cs().transaction().state() == wsrep::transaction::s_must_replay);
DBUG_RETURN(ret);
}
/*
Called before the transaction is committed.
This function must be called from both client and
applier contexts before commit.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_before_commit(THD* thd, bool all)
{
DBUG_ENTER("wsrep_before_commit");
WSREP_DEBUG("wsrep_before_commit: %d, %lld",
wsrep_is_real(thd, all),
(long long)wsrep_thd_trx_seqno(thd));
MDEV-26352 : Add new thread states for certain WSREP scenarios This adds following new thread states: * waiting to execute in isolation - DDL is waiting to execute in TOI mode. * waiting for TOI DDL - some other statement is waiting for DDL to complete. * waiting for flow control - some statement is paused while flow control is in effect. * waiting for certification - the transaction is being certified.
2021-08-20 12:54:53 +03:00
THD_STAGE_INFO(thd, stage_waiting_certification);
Galera4
2019-01-23 15:30:00 +04:00
int ret= 0;
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(wsrep_run_commit_hook(thd, all));
MDEV-26352 : Add new thread states for certain WSREP scenarios This adds following new thread states: * waiting to execute in isolation - DDL is waiting to execute in TOI mode. * waiting for TOI DDL - some other statement is waiting for DDL to complete. * waiting for flow control - some statement is paused while flow control is in effect. * waiting for certification - the transaction is being certified.
2021-08-20 12:54:53 +03:00
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
if ((ret= thd->wsrep_cs().before_commit()) == 0)
Galera4
2019-01-23 15:30:00 +04:00
{
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(!thd->wsrep_trx().ws_meta().gtid().is_undefined());
MDEV-26352 : Add new thread states for certain WSREP scenarios This adds following new thread states: * waiting to execute in isolation - DDL is waiting to execute in TOI mode. * waiting for TOI DDL - some other statement is waiting for DDL to complete. * waiting for flow control - some statement is paused while flow control is in effect. * waiting for certification - the transaction is being certified.
2021-08-20 12:54:53 +03:00
if (!thd->variables.gtid_seq_no &&
Galera GTID support 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.
2019-04-01 13:23:05 +02:00
(thd->wsrep_trx().ws_meta().flags() & wsrep::provider::flag::commit))
{
uint64 seqno= 0;
if (thd->variables.wsrep_gtid_seq_no &&
thd->variables.wsrep_gtid_seq_no > wsrep_gtid_server.seqno())
{
seqno= thd->variables.wsrep_gtid_seq_no;
wsrep_gtid_server.seqno(thd->variables.wsrep_gtid_seq_no);
}
else
{
seqno= wsrep_gtid_server.seqno_inc();
}
thd->variables.wsrep_gtid_seq_no= 0;
thd->wsrep_current_gtid_seqno= seqno;
if (mysql_bin_log.is_open() && wsrep_gtid_mode)
{
thd->variables.gtid_seq_no= seqno;
thd->variables.gtid_domain_id= wsrep_gtid_server.domain_id;
thd->variables.server_id= wsrep_gtid_server.server_id;
}
}
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
wsrep_xid_init(&thd->wsrep_xid,
Galera GTID support 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.
2019-04-01 13:23:05 +02:00
thd->wsrep_trx().ws_meta().gtid(),
wsrep_gtid_server.gtid());
10.4 wsrep group commit fixes (#1224) * MDEV-16509 Improve wsrep commit performance with binlog disabled Release commit order critical section early after trx_commit_low() if binlog is not transaction coordinator. In order to avoid two phase commit, binlog_hton is not registered for THD during IO_CACHE population. Implemented a test which verifies that the transactions release commit order early. This optimization will change behavior during recovery as the commit is not two phase when binlog is off. Fixed and recorded wsrep-recover-v25 and wsrep-recover to match the behavior. * MDEV-18730 Ordering for wsrep binlog group commit Previously out of order execution was allowed for wsrep commits. Established proper ordering by populating wait_for_commit for every wsrep THD and making group commit leader to wait for prior commits before proceeding to trx_group_commit_leader(). * MDEV-18730 Added a test case to verify correct commit ordering * MDEV-16509, MDEV-18730 Review fixes Use WSREP_EMULATE_BINLOG() macro to decide if the binlog_hton should be registered. Whitespace/syntax fixes and cleanups. * MDEV-16509 Require binlog for galera_var_innodb_disallow_writes test If the commit to InnoDB is done in one phase, the native InnoDB behavior is that the transaction is committed in memory before it is persisted to disk. This means that the innodb_disallow_writes=ON may not prevent transaction to become visible to other readers before commit is completely over. On the other hand, if the commit is two phase (as it is with binlog), the transaction will be blocked in prepare phase. Fixed the test to use binlog, which enforces two phase commit, which in turn makes commit to block before the changes become visible to other connections. This guarantees that the test produces expected result.
2019-03-15 07:09:13 +02:00
wsrep_register_for_group_commit(thd);
Galera4
2019-01-23 15:30:00 +04:00
}
MDEV-29293 MariaDB stuck on starting commit state This commit contains a merge from 10.5-MDEV-29293-squash into 10.6. Although the bug MDEV-29293 was not reproducible with 10.6, the fix contains several improvements for wsrep KILL query and BF abort handling, and addresses the following issues: * MDEV-30307 KILL command issued inside a transaction is problematic for galera replication: This commit will remove KILL TOI replication, so Galera side transaction context is not lost during KILL. * MDEV-21075 KILL QUERY maintains nodes data consistency but breaks GTID sequence: This is fixed as well as KILL does not use TOI, and thus does not change GTID state. * MDEV-30372 Assertion in wsrep-lib state: This was caused by BF abort or KILL when local transaction was in the middle of group commit. This commit disables THD::killed handling during commit, so the problem is avoided. * MDEV-30963 Assertion failure !lock.was_chosen_as_deadlock_victim in trx0trx.h:1065: The assertion happened when the victim was BF aborted via MDL while it was committing. This commit changes MDL BF aborts so that transactions which are committing cannot be BF aborted via MDL. The RQG grammar attached in the issue could not reproduce the crash anymore. Original commit message from 10.5 fix: MDEV-29293 MariaDB stuck on starting commit state The problem seems to be a deadlock between KILL command execution and BF abort issued by an applier, where: * KILL has locked victim's LOCK_thd_kill and LOCK_thd_data. * Applier has innodb side global lock mutex and victim trx mutex. * KILL is calling innobase_kill_query, and is blocked by innodb global lock mutex. * Applier is in wsrep_innobase_kill_one_trx and is blocked by victim's LOCK_thd_kill. The fix in this commit removes the TOI replication of KILL command and makes KILL execution less intrusive operation. Aborting the victim happens now by using awake_no_mutex() and ha_abort_transaction(). If the KILL happens when the transaction is committing, the KILL operation is postponed to happen after the statement has completed in order to avoid KILL to interrupt commit processing. Notable changes in this commit: * wsrep client connections's error state may remain sticky after client connection is closed. This error message will then pop up for the next client session issuing first SQL statement. This problem raised with test galera.galera_bf_kill. The fix is to reset wsrep client error state, before a THD is reused for next connetion. * Release THD locks in wsrep_abort_transaction when locking innodb mutexes. This guarantees same locking order as with applier BF aborting. * BF abort from MDL was changed to do BF abort on server/wsrep-lib side first, and only then do the BF abort on InnoDB side. This removes the need to call back from InnoDB for BF aborts which originate from MDL and simplifies the locking. * Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h. The manipulation of the wsrep_aborter can be done solely on server side. Moreover, it is now debug only variable and could be excluded from optimized builds. * Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more fine grained locking for SR BF abort which may require locking of victim LOCK_thd_kill. Added explicit call for wsrep_thd_kill_LOCK/UNLOCK where appropriate. * Wsrep-lib was updated to version which allows external locking for BF abort calls. Changes to MTR tests: * Disable galera_bf_abort_group_commit. This test is going to be removed (MDEV-30855). * Make galera_var_retry_autocommit result more readable by echoing cases and expectations into result. Only one expected result for reap to verify that server returns expected status for query. * Record galera_gcache_recover_manytrx as result file was incomplete. Trivial change. * Make galera_create_table_as_select more deterministic: Wait until CTAS execution has reached MDL wait for multi-master conflict case. Expected error from multi-master conflict is ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open wsrep transaction when it is waiting for MDL, query gets interrupted instead of BF aborted. This should be addressed in separate task. * A new test galera_bf_abort_registering to check that registering trx gets BF aborted through MDL. * A new test galera_kill_group_commit to verify correct behavior when KILL is executed while the transaction is committing. Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi> Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com> Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-04-19 16:51:55 +03:00
mysql_mutex_lock(&thd->LOCK_thd_kill);
if (thd->killed) wsrep_backup_kill_for_commit(thd);
mysql_mutex_unlock(&thd->LOCK_thd_kill);
Galera4
2019-01-23 15:30:00 +04:00
DBUG_RETURN(ret);
}
/*
Called after the transaction has been ordered for commit.
This function must be called from both client and
applier contexts after the commit has been ordered.
@param thd Pointer to THD
@param all
@param err Error buffer in case of applying error
Return zero on succes, non-zero on failure.
*/
MDEV-17048 Inconsistency voting support (#1373) * Collect and pass apply error data to provider * Rollback failed transaction and continue operation if provider returns SUCCESS * MTR tests for inconsistency voting
2019-08-28 07:19:24 +01:00
static inline int wsrep_ordered_commit(THD* thd, bool all)
Galera4
2019-01-23 15:30:00 +04:00
{
DBUG_ENTER("wsrep_ordered_commit");
MDEV-29293 MariaDB stuck on starting commit state This commit contains a merge from 10.5-MDEV-29293-squash into 10.6. Although the bug MDEV-29293 was not reproducible with 10.6, the fix contains several improvements for wsrep KILL query and BF abort handling, and addresses the following issues: * MDEV-30307 KILL command issued inside a transaction is problematic for galera replication: This commit will remove KILL TOI replication, so Galera side transaction context is not lost during KILL. * MDEV-21075 KILL QUERY maintains nodes data consistency but breaks GTID sequence: This is fixed as well as KILL does not use TOI, and thus does not change GTID state. * MDEV-30372 Assertion in wsrep-lib state: This was caused by BF abort or KILL when local transaction was in the middle of group commit. This commit disables THD::killed handling during commit, so the problem is avoided. * MDEV-30963 Assertion failure !lock.was_chosen_as_deadlock_victim in trx0trx.h:1065: The assertion happened when the victim was BF aborted via MDL while it was committing. This commit changes MDL BF aborts so that transactions which are committing cannot be BF aborted via MDL. The RQG grammar attached in the issue could not reproduce the crash anymore. Original commit message from 10.5 fix: MDEV-29293 MariaDB stuck on starting commit state The problem seems to be a deadlock between KILL command execution and BF abort issued by an applier, where: * KILL has locked victim's LOCK_thd_kill and LOCK_thd_data. * Applier has innodb side global lock mutex and victim trx mutex. * KILL is calling innobase_kill_query, and is blocked by innodb global lock mutex. * Applier is in wsrep_innobase_kill_one_trx and is blocked by victim's LOCK_thd_kill. The fix in this commit removes the TOI replication of KILL command and makes KILL execution less intrusive operation. Aborting the victim happens now by using awake_no_mutex() and ha_abort_transaction(). If the KILL happens when the transaction is committing, the KILL operation is postponed to happen after the statement has completed in order to avoid KILL to interrupt commit processing. Notable changes in this commit: * wsrep client connections's error state may remain sticky after client connection is closed. This error message will then pop up for the next client session issuing first SQL statement. This problem raised with test galera.galera_bf_kill. The fix is to reset wsrep client error state, before a THD is reused for next connetion. * Release THD locks in wsrep_abort_transaction when locking innodb mutexes. This guarantees same locking order as with applier BF aborting. * BF abort from MDL was changed to do BF abort on server/wsrep-lib side first, and only then do the BF abort on InnoDB side. This removes the need to call back from InnoDB for BF aborts which originate from MDL and simplifies the locking. * Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h. The manipulation of the wsrep_aborter can be done solely on server side. Moreover, it is now debug only variable and could be excluded from optimized builds. * Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more fine grained locking for SR BF abort which may require locking of victim LOCK_thd_kill. Added explicit call for wsrep_thd_kill_LOCK/UNLOCK where appropriate. * Wsrep-lib was updated to version which allows external locking for BF abort calls. Changes to MTR tests: * Disable galera_bf_abort_group_commit. This test is going to be removed (MDEV-30855). * Make galera_var_retry_autocommit result more readable by echoing cases and expectations into result. Only one expected result for reap to verify that server returns expected status for query. * Record galera_gcache_recover_manytrx as result file was incomplete. Trivial change. * Make galera_create_table_as_select more deterministic: Wait until CTAS execution has reached MDL wait for multi-master conflict case. Expected error from multi-master conflict is ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open wsrep transaction when it is waiting for MDL, query gets interrupted instead of BF aborted. This should be addressed in separate task. * A new test galera_bf_abort_registering to check that registering trx gets BF aborted through MDL. * A new test galera_kill_group_commit to verify correct behavior when KILL is executed while the transaction is committing. Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi> Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com> Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-04-19 16:51:55 +03:00
WSREP_DEBUG("wsrep_ordered_commit: %d %lld", wsrep_is_real(thd, all),
(long long) wsrep_thd_trx_seqno(thd));
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
DBUG_ASSERT(wsrep_run_commit_hook(thd, all));
DBUG_RETURN(thd->wsrep_cs().ordered_commit());
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Called after the transaction has been committed.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_after_commit(THD* thd, bool all)
{
DBUG_ENTER("wsrep_after_commit");
WSREP_DEBUG("wsrep_after_commit: %d, %d, %lld, %d",
wsrep_is_real(thd, all),
wsrep_is_active(thd),
(long long)wsrep_thd_trx_seqno(thd),
MDEV-18631 Fix streaming replication with wsrep_gtid_mode=ON With wsrep_gtid_mode=ON, the appropriate commit hooks were not called in all cases for applied streaming transactions. As a fix, removed all special handling of commit order critical section from Wsrep_high_priority_service and Wsrep_storage_service. Now commit order critical section is always entered in ha_commit_trans(). Check for wsrep_run_commit_hook is now done in handler.cc, log.cc. This makes it explicit that the transaction is an active wsrep transaction which must go through commit hooks.
2019-02-21 21:57:52 +02:00
wsrep_has_changes(thd));
DBUG_ASSERT(wsrep_run_commit_hook(thd, all));
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (thd->internal_transaction())
DBUG_RETURN(0);
10.4 wsrep group commit fixes (#1224) * MDEV-16509 Improve wsrep commit performance with binlog disabled Release commit order critical section early after trx_commit_low() if binlog is not transaction coordinator. In order to avoid two phase commit, binlog_hton is not registered for THD during IO_CACHE population. Implemented a test which verifies that the transactions release commit order early. This optimization will change behavior during recovery as the commit is not two phase when binlog is off. Fixed and recorded wsrep-recover-v25 and wsrep-recover to match the behavior. * MDEV-18730 Ordering for wsrep binlog group commit Previously out of order execution was allowed for wsrep commits. Established proper ordering by populating wait_for_commit for every wsrep THD and making group commit leader to wait for prior commits before proceeding to trx_group_commit_leader(). * MDEV-18730 Added a test case to verify correct commit ordering * MDEV-16509, MDEV-18730 Review fixes Use WSREP_EMULATE_BINLOG() macro to decide if the binlog_hton should be registered. Whitespace/syntax fixes and cleanups. * MDEV-16509 Require binlog for galera_var_innodb_disallow_writes test If the commit to InnoDB is done in one phase, the native InnoDB behavior is that the transaction is committed in memory before it is persisted to disk. This means that the innodb_disallow_writes=ON may not prevent transaction to become visible to other readers before commit is completely over. On the other hand, if the commit is two phase (as it is with binlog), the transaction will be blocked in prepare phase. Fixed the test to use binlog, which enforces two phase commit, which in turn makes commit to block before the changes become visible to other connections. This guarantees that the test produces expected result.
2019-03-15 07:09:13 +02:00
int ret= 0;
if (thd->wsrep_trx().state() == wsrep::transaction::s_committing)
{
ret= thd->wsrep_cs().ordered_commit();
}
wsrep_unregister_from_group_commit(thd);
thd->wsrep_xid.null();
DBUG_RETURN(ret || thd->wsrep_cs().after_commit());
Galera4
2019-01-23 15:30:00 +04:00
}
/*
Called before the transaction is rolled back.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_before_rollback(THD* thd, bool all)
{
DBUG_ENTER("wsrep_before_rollback");
int ret= 0;
if (wsrep_is_active(thd))
{
MDEV-21675: Data inconsistency after multirow insert rollback (#1474) * Remove dead code * MDEV-21675 Data inconsistency after multirow insert rollback This patch fixes data inconsistencies that happen after rollback of multirow inserts, with binlog disabled. For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')` that fail with duplicate key error. In such cases the whole statement is rolled back. However, with wsrep_emulate_binlog in effect, the IO_CACHE would not be truncated, and the pending rows events would be replicated to the rest of the cluster. In the above example, it would result in row (1,'a') being replicated, whereas locally the statement is rolled back entirely. Making the cluster inconsistent. The patch changes the code so that prior to statement rollback, pending rows event are removed and the stmt cache reset. That patch also introduces MTR tests that excercise multirow insert statements for regular, and streaming replication.
2020-03-21 08:17:28 +01:00
if (!all && thd->in_active_multi_stmt_transaction())
Galera4
2019-01-23 15:30:00 +04:00
{
MDEV-21675: Data inconsistency after multirow insert rollback (#1474) * Remove dead code * MDEV-21675 Data inconsistency after multirow insert rollback This patch fixes data inconsistencies that happen after rollback of multirow inserts, with binlog disabled. For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')` that fail with duplicate key error. In such cases the whole statement is rolled back. However, with wsrep_emulate_binlog in effect, the IO_CACHE would not be truncated, and the pending rows events would be replicated to the rest of the cluster. In the above example, it would result in row (1,'a') being replicated, whereas locally the statement is rolled back entirely. Making the cluster inconsistent. The patch changes the code so that prior to statement rollback, pending rows event are removed and the stmt cache reset. That patch also introduces MTR tests that excercise multirow insert statements for regular, and streaming replication.
2020-03-21 08:17:28 +01:00
if (wsrep_emulate_bin_log)
{
wsrep_thd_binlog_stmt_rollback(thd);
}
if (thd->wsrep_trx().is_streaming() &&
MDEV-25553 : Avoid unnecessary rollbacks with SR This patch changes statement rollback for streaming replication. Previously, a statement rollback was turned into full transaction rollback in the case where the transaction had already replicated a fragment. This was introduced in the initial implementation of streaming replication due to the fact that we do not have a mechanism to perform a statement rollback on the applying side. This policy is however overly pessimistic, causing full rollbacks even in cases where a local statement rollback, would not require a statement rollback on the applying side. This happens to be case when the statement itself has not replicated any fragments. So the patch changes the condition that determines if a statement rollback should be turned into a full rollback accordingly. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-04-23 11:31:02 +02:00
(wsrep_fragments_certified_for_stmt(thd) > 0))
MDEV-21675: Data inconsistency after multirow insert rollback (#1474) * Remove dead code * MDEV-21675 Data inconsistency after multirow insert rollback This patch fixes data inconsistencies that happen after rollback of multirow inserts, with binlog disabled. For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')` that fail with duplicate key error. In such cases the whole statement is rolled back. However, with wsrep_emulate_binlog in effect, the IO_CACHE would not be truncated, and the pending rows events would be replicated to the rest of the cluster. In the above example, it would result in row (1,'a') being replicated, whereas locally the statement is rolled back entirely. Making the cluster inconsistent. The patch changes the code so that prior to statement rollback, pending rows event are removed and the stmt cache reset. That patch also introduces MTR tests that excercise multirow insert statements for regular, and streaming replication.
2020-03-21 08:17:28 +01:00
{
/* Non-safe statement rollback during SR multi statement
MDEV-25553 : Avoid unnecessary rollbacks with SR This patch changes statement rollback for streaming replication. Previously, a statement rollback was turned into full transaction rollback in the case where the transaction had already replicated a fragment. This was introduced in the initial implementation of streaming replication due to the fact that we do not have a mechanism to perform a statement rollback on the applying side. This policy is however overly pessimistic, causing full rollbacks even in cases where a local statement rollback, would not require a statement rollback on the applying side. This happens to be case when the statement itself has not replicated any fragments. So the patch changes the condition that determines if a statement rollback should be turned into a full rollback accordingly. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-04-23 11:31:02 +02:00
transaction. A statement rollback is considered unsafe, if
the same statement has already replicated one or more fragments.
Self abort the transaction, the actual rollback and error
handling will be done in after statement phase. */
WSREP_DEBUG("statement rollback is not safe for streaming replication");
MDEV-21675: Data inconsistency after multirow insert rollback (#1474) * Remove dead code * MDEV-21675 Data inconsistency after multirow insert rollback This patch fixes data inconsistencies that happen after rollback of multirow inserts, with binlog disabled. For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')` that fail with duplicate key error. In such cases the whole statement is rolled back. However, with wsrep_emulate_binlog in effect, the IO_CACHE would not be truncated, and the pending rows events would be replicated to the rest of the cluster. In the above example, it would result in row (1,'a') being replicated, whereas locally the statement is rolled back entirely. Making the cluster inconsistent. The patch changes the code so that prior to statement rollback, pending rows event are removed and the stmt cache reset. That patch also introduces MTR tests that excercise multirow insert statements for regular, and streaming replication.
2020-03-21 08:17:28 +01:00
wsrep_thd_self_abort(thd);
ret= 0;
}
Galera4
2019-01-23 15:30:00 +04:00
}
else if (wsrep_is_real(thd, all) &&
thd->wsrep_trx().state() != wsrep::transaction::s_aborted)
{
/* Real transaction rolling back and wsrep abort not completed
yet */
/* Reset XID so that it does not trigger writing serialization
history in InnoDB. This needs to be avoided because rollback
may happen out of order and replay may follow. */
thd->wsrep_xid.null();
ret= thd->wsrep_cs().before_rollback();
}
}
DBUG_RETURN(ret);
}
/*
Called after the transaction has been rolled back.
Return zero on succes, non-zero on failure.
*/
static inline int wsrep_after_rollback(THD* thd, bool all)
{
DBUG_ENTER("wsrep_after_rollback");
DBUG_RETURN((wsrep_is_real(thd, all) && wsrep_is_active(thd) &&
thd->wsrep_cs().transaction().state() !=
wsrep::transaction::s_aborted) ?
thd->wsrep_cs().after_rollback() : 0);
}
static inline int wsrep_before_statement(THD* thd)
{
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
return (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction() ?
Galera4
2019-01-23 15:30:00 +04:00
thd->wsrep_cs().before_statement() : 0);
}
static inline
int wsrep_after_statement(THD* thd)
{
DBUG_ENTER("wsrep_after_statement");
MDEV-24062: : Galera test failure on galera_var_replicate_myisam_on 10.5 version
2021-10-13 13:35:49 +03:00
WSREP_DEBUG("wsrep_after_statement for %lu client_state %s "
" client_mode %s trans_state %s",
thd_get_thread_id(thd),
wsrep::to_c_string(thd->wsrep_cs().state()),
wsrep::to_c_string(thd->wsrep_cs().mode()),
wsrep::to_c_string(thd->wsrep_cs().transaction().state()));
MDEV-29293 MariaDB stuck on starting commit state This commit contains a merge from 10.5-MDEV-29293-squash into 10.6. Although the bug MDEV-29293 was not reproducible with 10.6, the fix contains several improvements for wsrep KILL query and BF abort handling, and addresses the following issues: * MDEV-30307 KILL command issued inside a transaction is problematic for galera replication: This commit will remove KILL TOI replication, so Galera side transaction context is not lost during KILL. * MDEV-21075 KILL QUERY maintains nodes data consistency but breaks GTID sequence: This is fixed as well as KILL does not use TOI, and thus does not change GTID state. * MDEV-30372 Assertion in wsrep-lib state: This was caused by BF abort or KILL when local transaction was in the middle of group commit. This commit disables THD::killed handling during commit, so the problem is avoided. * MDEV-30963 Assertion failure !lock.was_chosen_as_deadlock_victim in trx0trx.h:1065: The assertion happened when the victim was BF aborted via MDL while it was committing. This commit changes MDL BF aborts so that transactions which are committing cannot be BF aborted via MDL. The RQG grammar attached in the issue could not reproduce the crash anymore. Original commit message from 10.5 fix: MDEV-29293 MariaDB stuck on starting commit state The problem seems to be a deadlock between KILL command execution and BF abort issued by an applier, where: * KILL has locked victim's LOCK_thd_kill and LOCK_thd_data. * Applier has innodb side global lock mutex and victim trx mutex. * KILL is calling innobase_kill_query, and is blocked by innodb global lock mutex. * Applier is in wsrep_innobase_kill_one_trx and is blocked by victim's LOCK_thd_kill. The fix in this commit removes the TOI replication of KILL command and makes KILL execution less intrusive operation. Aborting the victim happens now by using awake_no_mutex() and ha_abort_transaction(). If the KILL happens when the transaction is committing, the KILL operation is postponed to happen after the statement has completed in order to avoid KILL to interrupt commit processing. Notable changes in this commit: * wsrep client connections's error state may remain sticky after client connection is closed. This error message will then pop up for the next client session issuing first SQL statement. This problem raised with test galera.galera_bf_kill. The fix is to reset wsrep client error state, before a THD is reused for next connetion. * Release THD locks in wsrep_abort_transaction when locking innodb mutexes. This guarantees same locking order as with applier BF aborting. * BF abort from MDL was changed to do BF abort on server/wsrep-lib side first, and only then do the BF abort on InnoDB side. This removes the need to call back from InnoDB for BF aborts which originate from MDL and simplifies the locking. * Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h. The manipulation of the wsrep_aborter can be done solely on server side. Moreover, it is now debug only variable and could be excluded from optimized builds. * Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more fine grained locking for SR BF abort which may require locking of victim LOCK_thd_kill. Added explicit call for wsrep_thd_kill_LOCK/UNLOCK where appropriate. * Wsrep-lib was updated to version which allows external locking for BF abort calls. Changes to MTR tests: * Disable galera_bf_abort_group_commit. This test is going to be removed (MDEV-30855). * Make galera_var_retry_autocommit result more readable by echoing cases and expectations into result. Only one expected result for reap to verify that server returns expected status for query. * Record galera_gcache_recover_manytrx as result file was incomplete. Trivial change. * Make galera_create_table_as_select more deterministic: Wait until CTAS execution has reached MDL wait for multi-master conflict case. Expected error from multi-master conflict is ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open wsrep transaction when it is waiting for MDL, query gets interrupted instead of BF aborted. This should be addressed in separate task. * A new test galera_bf_abort_registering to check that registering trx gets BF aborted through MDL. * A new test galera_kill_group_commit to verify correct behavior when KILL is executed while the transaction is committing. Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi> Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com> Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-04-19 16:51:55 +03:00
int ret= ((thd->wsrep_cs().state() != wsrep::client_state::s_none &&
MDEV-24062: : Galera test failure on galera_var_replicate_myisam_on 10.5 version
2021-10-13 13:35:49 +03:00
thd->wsrep_cs().mode() == Wsrep_client_state::m_local) &&
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
!thd->internal_transaction() ?
Galera4
2019-01-23 15:30:00 +04:00
thd->wsrep_cs().after_statement() : 0);
MDEV-29293 MariaDB stuck on starting commit state This commit contains a merge from 10.5-MDEV-29293-squash into 10.6. Although the bug MDEV-29293 was not reproducible with 10.6, the fix contains several improvements for wsrep KILL query and BF abort handling, and addresses the following issues: * MDEV-30307 KILL command issued inside a transaction is problematic for galera replication: This commit will remove KILL TOI replication, so Galera side transaction context is not lost during KILL. * MDEV-21075 KILL QUERY maintains nodes data consistency but breaks GTID sequence: This is fixed as well as KILL does not use TOI, and thus does not change GTID state. * MDEV-30372 Assertion in wsrep-lib state: This was caused by BF abort or KILL when local transaction was in the middle of group commit. This commit disables THD::killed handling during commit, so the problem is avoided. * MDEV-30963 Assertion failure !lock.was_chosen_as_deadlock_victim in trx0trx.h:1065: The assertion happened when the victim was BF aborted via MDL while it was committing. This commit changes MDL BF aborts so that transactions which are committing cannot be BF aborted via MDL. The RQG grammar attached in the issue could not reproduce the crash anymore. Original commit message from 10.5 fix: MDEV-29293 MariaDB stuck on starting commit state The problem seems to be a deadlock between KILL command execution and BF abort issued by an applier, where: * KILL has locked victim's LOCK_thd_kill and LOCK_thd_data. * Applier has innodb side global lock mutex and victim trx mutex. * KILL is calling innobase_kill_query, and is blocked by innodb global lock mutex. * Applier is in wsrep_innobase_kill_one_trx and is blocked by victim's LOCK_thd_kill. The fix in this commit removes the TOI replication of KILL command and makes KILL execution less intrusive operation. Aborting the victim happens now by using awake_no_mutex() and ha_abort_transaction(). If the KILL happens when the transaction is committing, the KILL operation is postponed to happen after the statement has completed in order to avoid KILL to interrupt commit processing. Notable changes in this commit: * wsrep client connections's error state may remain sticky after client connection is closed. This error message will then pop up for the next client session issuing first SQL statement. This problem raised with test galera.galera_bf_kill. The fix is to reset wsrep client error state, before a THD is reused for next connetion. * Release THD locks in wsrep_abort_transaction when locking innodb mutexes. This guarantees same locking order as with applier BF aborting. * BF abort from MDL was changed to do BF abort on server/wsrep-lib side first, and only then do the BF abort on InnoDB side. This removes the need to call back from InnoDB for BF aborts which originate from MDL and simplifies the locking. * Removed wsrep_thd_set_wsrep_aborter() from service_wsrep.h. The manipulation of the wsrep_aborter can be done solely on server side. Moreover, it is now debug only variable and could be excluded from optimized builds. * Remove LOCK_thd_kill from wsrep_thd_LOCK/UNLOCK to allow more fine grained locking for SR BF abort which may require locking of victim LOCK_thd_kill. Added explicit call for wsrep_thd_kill_LOCK/UNLOCK where appropriate. * Wsrep-lib was updated to version which allows external locking for BF abort calls. Changes to MTR tests: * Disable galera_bf_abort_group_commit. This test is going to be removed (MDEV-30855). * Make galera_var_retry_autocommit result more readable by echoing cases and expectations into result. Only one expected result for reap to verify that server returns expected status for query. * Record galera_gcache_recover_manytrx as result file was incomplete. Trivial change. * Make galera_create_table_as_select more deterministic: Wait until CTAS execution has reached MDL wait for multi-master conflict case. Expected error from multi-master conflict is ER_QUERY_INTERRUPTED. This is because CTAS does not yet have open wsrep transaction when it is waiting for MDL, query gets interrupted instead of BF aborted. This should be addressed in separate task. * A new test galera_bf_abort_registering to check that registering trx gets BF aborted through MDL. * A new test galera_kill_group_commit to verify correct behavior when KILL is executed while the transaction is committing. Co-authored-by: Seppo Jaakola <seppo.jaakola@iki.fi> Co-authored-by: Jan Lindström <jan.lindstrom@galeracluster.com> Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2023-04-19 16:51:55 +03:00
if (wsrep_is_active(thd))
{
mysql_mutex_lock(&thd->LOCK_thd_kill);
wsrep_restore_kill_after_commit(thd);
mysql_mutex_unlock(&thd->LOCK_thd_kill);
}
DBUG_RETURN(ret);
Galera4
2019-01-23 15:30:00 +04:00
}
static inline void wsrep_after_apply(THD* thd)
{
DBUG_ASSERT(wsrep_thd_is_applying(thd));
WSREP_DEBUG("wsrep_after_apply %lld", thd->thread_id);
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (!thd->internal_transaction())
thd->wsrep_cs().after_applying();
Galera4
2019-01-23 15:30:00 +04:00
}
static inline void wsrep_open(THD* thd)
{
DBUG_ENTER("wsrep_open");
Fixed assert in WSREP if one started with --wsrep_provider=.. --wsrep_on=OFF Assert was: mariadbd: /my/maria-10.6/wsrep-lib/src/client_state.cpp:256: int wsrep::client_state::after_statement(): Assertion `state() == s_exec' The reason was because of two faults: - A missing test for WSREP(thd) when checking wsrep_after_statement(() - THD->wsrep_cs().state was set to s_idle instead of s_none
2021-04-12 17:49:36 +03:00
if (WSREP_ON_)
Galera4
2019-01-23 15:30:00 +04:00
{
Fixed assert in WSREP if one started with --wsrep_provider=.. --wsrep_on=OFF Assert was: mariadbd: /my/maria-10.6/wsrep-lib/src/client_state.cpp:256: int wsrep::client_state::after_statement(): Assertion `state() == s_exec' The reason was because of two faults: - A missing test for WSREP(thd) when checking wsrep_after_statement(() - THD->wsrep_cs().state was set to s_idle instead of s_none
2021-04-12 17:49:36 +03:00
/* WSREP_PROVIDER_EXISTS_ cannot be set if WSREP_ON_ is not set */
DBUG_ASSERT(WSREP_PROVIDER_EXISTS_);
Galera4
2019-01-23 15:30:00 +04:00
thd->wsrep_cs().open(wsrep::client_id(thd->thread_id));
thd->wsrep_cs().debug_log_level(wsrep_debug);
if (!thd->wsrep_applier && thd->variables.wsrep_trx_fragment_size)
{
thd->wsrep_cs().enable_streaming(
wsrep_fragment_unit(thd->variables.wsrep_trx_fragment_unit),
size_t(thd->variables.wsrep_trx_fragment_size));
}
}
DBUG_VOID_RETURN;
}
static inline void wsrep_close(THD* thd)
{
DBUG_ENTER("wsrep_close");
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction())
Galera4
2019-01-23 15:30:00 +04:00
{
thd->wsrep_cs().close();
}
DBUG_VOID_RETURN;
}
More fixes to variable wsrep_on * Disallow setting wsrep_on = 1 if wsrep_provider is unset. Also, move wsrep_on_basic from sys_vars to wsrep suite: this test now requires to run with wsrep_provider set * Disallow setting @@session.wsrep_on = 1 when @@global.wsrep_on = 0 * Handle the case where a new connection turns @@global.wsrep_on from off to on. In this case we would miss a call to wsrep_open, causing unexpected states in wsrep::client_state (causing assertions). * Disable wsrep.MDEV-22443 because it is no longer possible to enable wsrep_on, if server is started with wsrep_provider='none' Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-04-14 22:40:46 +02:00
static inline void wsrep_cleanup(THD* thd)
{
DBUG_ENTER("wsrep_cleanup");
if (thd->wsrep_cs().state() != wsrep::client_state::s_none)
{
thd->wsrep_cs().cleanup();
}
DBUG_VOID_RETURN;
}
MDEV-19826 10.4 seems to crash with "pool-of-threads" (#1370) MariaDB 10.4 was crashing when thread-handling was set to pool-of-threads and wsrep was enabled. There were two apparent reasons for the crash: - Connection handling in threadpool_common.cc was missing calls to control wsrep client state. - Thread specific storage which contains thread variables (THR_KEY_mysys) was not handled appropriately by wsrep patch when pool-of-threads was configured. This patch addresses the above issues in the following way: - Wsrep client state open/close was moved in thd_prepare_connection() and end_connection() to have common handling for one-thread-per-connection and pool-of-threads. - Thread local storage handling in wsrep patch was reworked by introducing set of wsrep_xxx_threadvars() calls which replace calls to THD store_globals()/reset_globals() and deal with thread handling specifics internally. Wsrep-lib was updated to version which relaxes internal concurrency related sanity checks. Rollback code from wsrep_rollback_process() was extracted to separate calls for better readability. Post rollback thread was removed as it was completely unused.
2019-08-30 08:42:24 +03:00
static inline void
wsrep_wait_rollback_complete_and_acquire_ownership(THD *thd)
{
DBUG_ENTER("wsrep_wait_rollback_complete_and_acquire_ownership");
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction())
MDEV-19826 10.4 seems to crash with "pool-of-threads" (#1370) MariaDB 10.4 was crashing when thread-handling was set to pool-of-threads and wsrep was enabled. There were two apparent reasons for the crash: - Connection handling in threadpool_common.cc was missing calls to control wsrep client state. - Thread specific storage which contains thread variables (THR_KEY_mysys) was not handled appropriately by wsrep patch when pool-of-threads was configured. This patch addresses the above issues in the following way: - Wsrep client state open/close was moved in thd_prepare_connection() and end_connection() to have common handling for one-thread-per-connection and pool-of-threads. - Thread local storage handling in wsrep patch was reworked by introducing set of wsrep_xxx_threadvars() calls which replace calls to THD store_globals()/reset_globals() and deal with thread handling specifics internally. Wsrep-lib was updated to version which relaxes internal concurrency related sanity checks. Rollback code from wsrep_rollback_process() was extracted to separate calls for better readability. Post rollback thread was removed as it was completely unused.
2019-08-30 08:42:24 +03:00
{
thd->wsrep_cs().wait_rollback_complete_and_acquire_ownership();
}
DBUG_VOID_RETURN;
}
MDEV-24255 MTR test galera_bf_abort fails with --ps-protocol Under ps-protocol, commandsl like COM_STMT_FETCH, COM_STMT_CLOSE and COM_STMT_SEND_LONG_DATA are not supposed to return errors. Therefore, if a transaction is BF aborted and the client is processing one of those commands, then we should not return a deadlock error immediately. Instead wait for the a subsequent client interaction which permits errors to be returned. To handle this, wsrep_before_command() now accepts parameter keep_command_error. If set true, keep_command_error will cause wsrep-lib side to skip result handling, and to keep the current error for the next interaction with the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-10-29 16:30:52 +02:00
static inline int wsrep_before_command(THD* thd, bool keep_command_error)
Galera4
2019-01-23 15:30:00 +04:00
{
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
return (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction() ?
Merge 10.4 into 10.5
2021-01-11 16:29:51 +02:00
thd->wsrep_cs().before_command(keep_command_error) : 0);
MDEV-24255 MTR test galera_bf_abort fails with --ps-protocol Under ps-protocol, commandsl like COM_STMT_FETCH, COM_STMT_CLOSE and COM_STMT_SEND_LONG_DATA are not supposed to return errors. Therefore, if a transaction is BF aborted and the client is processing one of those commands, then we should not return a deadlock error immediately. Instead wait for the a subsequent client interaction which permits errors to be returned. To handle this, wsrep_before_command() now accepts parameter keep_command_error. If set true, keep_command_error will cause wsrep-lib side to skip result handling, and to keep the current error for the next interaction with the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-10-29 16:30:52 +02:00
}
static inline int wsrep_before_command(THD* thd)
{
return wsrep_before_command(thd, false);
Galera4
2019-01-23 15:30:00 +04:00
}
MDEV-24255 MTR test galera_bf_abort fails with --ps-protocol Under ps-protocol, commandsl like COM_STMT_FETCH, COM_STMT_CLOSE and COM_STMT_SEND_LONG_DATA are not supposed to return errors. Therefore, if a transaction is BF aborted and the client is processing one of those commands, then we should not return a deadlock error immediately. Instead wait for the a subsequent client interaction which permits errors to be returned. To handle this, wsrep_before_command() now accepts parameter keep_command_error. If set true, keep_command_error will cause wsrep-lib side to skip result handling, and to keep the current error for the next interaction with the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-10-29 16:30:52 +02:00
Galera4
2019-01-23 15:30:00 +04:00
/*
Called after each command.
Return zero on success, non-zero on failure.
*/
static inline void wsrep_after_command_before_result(THD* thd)
{
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction())
Galera4
2019-01-23 15:30:00 +04:00
{
thd->wsrep_cs().after_command_before_result();
}
}
static inline void wsrep_after_command_after_result(THD* thd)
{
Update galera to work with independent sub transactions
2020-05-19 17:48:22 +03:00
if (thd->wsrep_cs().state() != wsrep::client_state::s_none &&
!thd->internal_transaction())
Galera4
2019-01-23 15:30:00 +04:00
{
thd->wsrep_cs().after_command_after_result();
}
}
static inline void wsrep_after_command_ignore_result(THD* thd)
{
wsrep_after_command_before_result(thd);
DBUG_ASSERT(!thd->wsrep_cs().current_error());
wsrep_after_command_after_result(thd);
}
static inline enum wsrep::client_error wsrep_current_error(THD* thd)
{
return thd->wsrep_cs().current_error();
}
static inline enum wsrep::provider::status
wsrep_current_error_status(THD* thd)
{
return thd->wsrep_cs().current_error_status();
}
#endif /* WSREP_TRANS_OBSERVER */
Reference in a new issue Copy permalink