mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-30 02:30:06 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/include/mysql/service_wsrep.h

238 lines
12 KiB
C
Raw Normal View History

fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#ifndef MYSQL_SERVICE_WSREP_INCLUDED
Galera4
2019-01-23 15:30:00 +04:00
#define MYSQL_SERVICE_WSREP_INCLUDED
enum Wsrep_service_key_type
{
WSREP_SERVICE_KEY_SHARED,
WSREP_SERVICE_KEY_REFERENCE,
WSREP_SERVICE_KEY_UPDATE,
WSREP_SERVICE_KEY_EXCLUSIVE
};
#if (defined (MYSQL_DYNAMIC_PLUGIN) && defined(MYSQL_SERVICE_WSREP_DYNAMIC_INCLUDED)) || (!defined(MYSQL_DYNAMIC_PLUGIN) && defined(MYSQL_SERVICE_WSREP_STATIC_INCLUDED))
#else
MDEV-22203: WSREP_ON is unnecessarily expensive WITH_WSREP=OFF If the server is compiled WITH_WSREP=OFF, we should avoid evaluating conditions on a global variable that is constant. WSREP_ON_: Renamed from WSREP_ON. Defined only WITH_WSREP=ON. WSREP_ON: Defined as unlikely(WSREP_ON_). wsrep_on(): Defined as WSREP_ON && wsrep_service->wsrep_on_func(). The reason why we have wsrep_on() at all is that the macro WSREP(thd) depends on the definition of THD, and that is intentionally an opaque data type for InnoDB. So, we cannot avoid invoking wsrep_on(), but we can evaluate the less expensive condition WSREP_ON before calling the function.
2020-04-24 15:25:39 +03:00
/* Copyright (c) 2015, 2020, MariaDB Corporation Ab
Galera4
2019-01-23 15:30:00 +04:00
2018 Codership Oy <info@codership.com>
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02: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
Merge branch '5.5' into 10.1
2019-05-11 22:19:05 +03:00
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1335 USA */
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
/**
@file
wsrep service
Interface to WSREP functionality in the server.
For engines that want to support galera.
*/
Galera4
2019-01-23 15:30:00 +04:00
#include <my_pthread.h>
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#ifdef __cplusplus
#endif
struct xid_t;
struct wsrep_ws_handle;
MDEV-15505 Fixes to compilation without -DWITH_WSREP:BOOL=ON Removed including wsrep_api.h from service_wsrep.h. This caused various kinds of collisions with definitions when wsrep is not supposed to be built in. Defined functions wsrep_xid_seqno() and wsrep_xid_uuid() in wsrep_dummy.cc. Replaced wsrep_seqno_t with long long where wsrep_api.h is not included. Removed wsrep_xid_seqno() macro from wsrep_mysqld.h and made wsrep code using wsrep_xid_seqno() in handler.cc to be compiled in only if WITH_WSREP is ON. Included wsrep_api.h for mariabackup if WITH_WSREP is ON.
2018-03-21 12:02:09 +02:00
struct wsrep_buf;
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
Galera4
2019-01-23 15:30:00 +04:00
/* Must match to definition in sql/mysqld.h */
typedef int64 query_id_t;
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
extern struct wsrep_service_st {
Merge branch '10.0-galera' into 10.1
2015-07-14 16:05:29 -04:00
my_bool (*get_wsrep_recovery_func)();
Galera4
2019-01-23 15:30:00 +04:00
bool (*wsrep_consistency_check_func)(MYSQL_THD thd);
int (*wsrep_is_wsrep_xid_func)(const void *xid);
MDEV-15505 Fixes to compilation without -DWITH_WSREP:BOOL=ON Removed including wsrep_api.h from service_wsrep.h. This caused various kinds of collisions with definitions when wsrep is not supposed to be built in. Defined functions wsrep_xid_seqno() and wsrep_xid_uuid() in wsrep_dummy.cc. Replaced wsrep_seqno_t with long long where wsrep_api.h is not included. Removed wsrep_xid_seqno() macro from wsrep_mysqld.h and made wsrep code using wsrep_xid_seqno() in handler.cc to be compiled in only if WITH_WSREP is ON. Included wsrep_api.h for mariabackup if WITH_WSREP is ON.
2018-03-21 12:02:09 +02:00
long long (*wsrep_xid_seqno_func)(const struct xid_t *xid);
MDEV-15505 Fix wsrep XID seqno byte order The problem is that the seqno part of wsrep XID is always stored in host byte order. This may cause issues when a physical backup is restored on a host with different architecture, the seqno part with XID may have incorrect value. In order to fix this, wsrep XID seqno is always written into XID data buffer in little endian byte order using int8store() and read from data buffer using sint8korr(). For backwards compatibility the seqno is read from TRX_SYS page in host byte order during upgrade. This patch implements byte ordering in wsrep_xid_init(), wsrep_xid_seqno(), and exposes functions to read wsrep XID uuid and seqno in wsrep_service_st. Backwards compatibility for upgrade is provided in trx_rseg_init_wsrep_xid().
2018-03-07 18:40:15 +02:00
const unsigned char* (*wsrep_xid_uuid_func)(const struct xid_t *xid);
Galera4
2019-01-23 15:30:00 +04:00
my_bool (*wsrep_on_func)(const MYSQL_THD thd);
bool (*wsrep_prepare_key_for_innodb_func)(MYSQL_THD thd, const unsigned char*, size_t, const unsigned char*, size_t, struct wsrep_buf*, size_t*);
void (*wsrep_thd_LOCK_func)(const MYSQL_THD thd);
void (*wsrep_thd_UNLOCK_func)(const MYSQL_THD thd);
const char * (*wsrep_thd_query_func)(const MYSQL_THD thd);
int (*wsrep_thd_retry_counter_func)(const MYSQL_THD thd);
bool (*wsrep_thd_ignore_table_func)(MYSQL_THD thd);
long long (*wsrep_thd_trx_seqno_func)(const MYSQL_THD thd);
my_bool (*wsrep_thd_is_aborting_func)(const MYSQL_THD thd);
fix failures of innodb_plugin tests in --embedded Post-fix for 7e8ed15b95b Also, apply the same innodb fix to xtradb.
2018-09-03 10:27:36 +02:00
void (*wsrep_set_data_home_dir_func)(const char *data_dir);
Galera4
2019-01-23 15:30:00 +04:00
my_bool (*wsrep_thd_is_BF_func)(const MYSQL_THD thd, my_bool sync);
my_bool (*wsrep_thd_is_local_func)(const MYSQL_THD thd);
void (*wsrep_thd_self_abort_func)(MYSQL_THD thd);
int (*wsrep_thd_append_key_func)(MYSQL_THD thd, const struct wsrep_key* key,
int n_keys, enum Wsrep_service_key_type);
const char* (*wsrep_thd_client_state_str_func)(const MYSQL_THD thd);
const char* (*wsrep_thd_client_mode_str_func)(const MYSQL_THD thd);
const char* (*wsrep_thd_transaction_state_str_func)(const MYSQL_THD thd);
query_id_t (*wsrep_thd_transaction_id_func)(const MYSQL_THD thd);
MDEV-20848 Fixes for MTR test galera_sr.GCF-1060 (#1421) This patch contains two fixes: * wsrep_handle_mdl_conflict(): handle the case where SR transaction is in aborting state. Previously, a BF-BF conflict was reported, and the process would abort. * wsrep_thd_bf_abort(): do not restore thread vars after calling wsrep_bf_abort(). Thread vars are already restored in wsrep-lib if necessary. This also removes the assumption that the caller of wsrep_thd_bf_abort() is the given bf_thd, which is not the case. Also in this patch: * Remove unnecessary check for active victim transaction in wsrep_thd_bf_abort(): the exact same check is performed later in wsrep_bf_abort(). * Make wsrep_thd_bf_abort() and wsrep_log_thd() const-correct. * Change signature of wsrep_abort_thd() to take THD pointers instead of void pointers.
2019-12-04 08:21:14 +01:00
my_bool (*wsrep_thd_bf_abort_func)(MYSQL_THD bf_thd,
Galera4
2019-01-23 15:30:00 +04:00
MYSQL_THD victim_thd,
my_bool signal);
my_bool (*wsrep_thd_order_before_func)(const MYSQL_THD left, const MYSQL_THD right);
void (*wsrep_handle_SR_rollback_func)(MYSQL_THD BF_thd, MYSQL_THD victim_thd);
my_bool (*wsrep_thd_skip_locking_func)(const MYSQL_THD thd);
const char* (*wsrep_get_sr_table_name_func)();
my_bool (*wsrep_get_debug_func)();
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
void (*wsrep_commit_ordered_func)(MYSQL_THD thd);
Fix InnoDB dynamic plugin compile errors on wsrep patch.
2019-04-10 11:19:38 +03:00
my_bool (*wsrep_thd_is_applying_func)(const MYSQL_THD thd);
MDEV-21910 Deadlock between BF abort and manual KILL command When high priority replication slave applier encounters lock conflict in innodb, it will force the conflicting lock holder transaction (victim) to rollback. This is a must in multi-master sychronous replication model to avoid cluster lock-up. This high priority victim abort (aka "brute force" (BF) abort), is started from innodb lock manager while holding the victim's transaction's (trx) mutex. Depending on the execution state of the victim transaction, it may happen that the BF abort will call for THD::awake() to wake up the victim transaction for the rollback. Now, if BF abort requires THD::awake() to be called, then the applier thread executed locking protocol of: victim trx mutex -> victim THD::LOCK_thd_data If, at the same time another DBMS super user issues KILL command to abort the same victim, it will execute locking protocol of: victim THD::LOCK_thd_data -> victim trx mutex. These two locking protocol acquire mutexes in opposite order, hence unresolvable mutex locking deadlock may occur. The fix in this commit adds THD::wsrep_aborter flag to synchronize who can kill the victim This flag is set both when BF is called for from innodb and by KILL command. Either path of victim killing will bail out if victim's wsrep_killed is already set to avoid mutex conflicts with the other aborter execution. THD::wsrep_aborter records the aborter THD's ID. This is needed to preserve the right to kill the victim from different locations for the same aborter thread. It is also good error logging, to see who is reponsible for the abort. A new test case was added in galera.galera_bf_kill_debug.test for scenario where wsrep applier thread and manual KILL command try to kill same idle victim
2020-05-19 11:12:26 +03:00
bool (*wsrep_thd_set_wsrep_aborter_func)(MYSQL_THD bf_thd, MYSQL_THD thd);
Merge 10.3 into 10.4
2020-09-21 12:29:00 +03:00
void (*wsrep_report_bf_lock_wait_func)(const MYSQL_THD thd,
MDEV-23101 : SIGSEGV in lock_rec_unlock() when Galera is enabled Remove incorrect BF (brute force) handling from lock_rec_has_to_wait_in_queue and move condition to correct callers. Add a function to report BF lock waits and assert if incorrect BF-BF lock wait happens. wsrep_report_bf_lock_wait Add a new function to report BF lock wait. wsrep_assert_no_bf_bf_wait Add a new function to check do we have a BF-BF wait and if we have report this case and assert as it is a bug. lock_rec_has_to_wait Use new wsrep_assert_bf_wait to check BF-BF wait. lock_rec_create_low lock_table_create Use new function to report BF lock waits. lock_rec_insert_by_trx_age lock_grant_and_move_on_page lock_grant_and_move_on_rec Assert that trx is not Galera as VATS is not compatible with Galera. lock_rec_add_to_queue If there is conflicting lock in a queue make sure that transaction is BF. lock_rec_has_to_wait_in_queue Remove incorrect BF handling. If there is conflicting locks in a queue all transactions must wait. lock_rec_dequeue_from_page lock_rec_unlock If there is conflicting lock make sure it is not BF-BF case. lock_rec_queue_validate Add Galera record locking rules comment and use new function to report BF lock waits. All attempts to reproduce the original assertion have been failed. Therefore, there is no test case on this commit.
2020-08-26 14:11:17 +03:00
unsigned long long trx_id);
Merge branch 'bb-10.3-release' into bb-10.4-release Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution" was null-merged. 10.4 version of the fix is coming up separately
2021-02-12 17:44:22 +01:00
void (*wsrep_thd_kill_LOCK_func)(const MYSQL_THD thd);
void (*wsrep_thd_kill_UNLOCK_func)(const MYSQL_THD thd);
MDEV-26803 PA unsafety with FK cascade delete operation This commit has a mtr test where two two transactions delete a row from two separate tables, which will cascade a FK delete for the same row in a third table. Second replica node is configured with 2 applier threads, and the test will fail if these two transactions are applied in parallel. The actual fix, in this commit, is to mark a transaction as unsafe for parallel applying when it traverses into cascade delete operation. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-12-09 18:12:20 +02:00
void (*wsrep_thd_set_wsrep_PA_unsafe_func)(MYSQL_THD thd);
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
} *wsrep_service;
Galera4
2019-01-23 15:30:00 +04:00
#define MYSQL_SERVICE_WSREP_INCLUDED
#endif
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#ifdef MYSQL_DYNAMIC_PLUGIN
Galera4
2019-01-23 15:30:00 +04:00
#define MYSQL_SERVICE_WSREP_DYNAMIC_INCLUDED
Merge branch '10.0-galera' into 10.1
2015-07-14 16:05:29 -04:00
#define get_wsrep_recovery() wsrep_service->get_wsrep_recovery_func()
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#define wsrep_consistency_check(T) wsrep_service->wsrep_consistency_check_func(T)
#define wsrep_is_wsrep_xid(X) wsrep_service->wsrep_is_wsrep_xid_func(X)
MDEV-15505 Fix wsrep XID seqno byte order The problem is that the seqno part of wsrep XID is always stored in host byte order. This may cause issues when a physical backup is restored on a host with different architecture, the seqno part with XID may have incorrect value. In order to fix this, wsrep XID seqno is always written into XID data buffer in little endian byte order using int8store() and read from data buffer using sint8korr(). For backwards compatibility the seqno is read from TRX_SYS page in host byte order during upgrade. This patch implements byte ordering in wsrep_xid_init(), wsrep_xid_seqno(), and exposes functions to read wsrep XID uuid and seqno in wsrep_service_st. Backwards compatibility for upgrade is provided in trx_rseg_init_wsrep_xid().
2018-03-07 18:40:15 +02:00
#define wsrep_xid_seqno(X) wsrep_service->wsrep_xid_seqno_func(X)
#define wsrep_xid_uuid(X) wsrep_service->wsrep_xid_uuid_func(X)
MDEV-7962 wsrep_on() takes 0.14% in OLTP RO The reason why we have wsrep_on() at all is that the macro WSREP(thd) depends on the definition of THD, and that is intentionally an opaque data type for InnoDB. So, we cannot avoid invoking wsrep_on(), but we can evaluate the less expensive conditions thd && WSREP_ON before calling the function. Global_read_lock: Use WSREP_NNULL(thd) instead of wsrep_on(thd) because we not only know the definition of THD but also that the pointer is not null. wsrep_open(): Use WSREP(thd) instead of wsrep_on(thd). InnoDB: Replace thd && wsrep_on(thd) with wsrep_on(thd), now that the condition has been merged to the definition of the macro wsrep_on().
2020-04-24 16:01:10 +03:00
#define wsrep_on(thd) (thd) && WSREP_ON && wsrep_service->wsrep_on_func(thd)
Galera4
2019-01-23 15:30:00 +04:00
#define wsrep_prepare_key_for_innodb(A,B,C,D,E,F,G) wsrep_service->wsrep_prepare_key_for_innodb_func(A,B,C,D,E,F,G)
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#define wsrep_thd_LOCK(T) wsrep_service->wsrep_thd_LOCK_func(T)
#define wsrep_thd_UNLOCK(T) wsrep_service->wsrep_thd_UNLOCK_func(T)
galera fixes related to THD::LOCK_thd_kill Since 2017 (c2118a08b1) THD::awake() no longer requires LOCK_thd_data. It uses LOCK_thd_kill, and this latter mutex is used to prevent a thread of dying, not LOCK_thd_data as before.
2021-02-01 16:23:49 +01:00
#define wsrep_thd_kill_LOCK(T) wsrep_service->wsrep_thd_kill_LOCK_func(T)
#define wsrep_thd_kill_UNLOCK(T) wsrep_service->wsrep_thd_kill_UNLOCK_func(T)
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#define wsrep_thd_query(T) wsrep_service->wsrep_thd_query_func(T)
#define wsrep_thd_retry_counter(T) wsrep_service->wsrep_thd_retry_counter_func(T)
Fix to ensure updates in gtid_slave_state table do not get binlogged. Also, renamed wsrep_skip_append_keys to wsrep_ignore_table. Test case : galera.galera_as_slave_gtid.test
2016-02-24 23:32:37 -05:00
#define wsrep_thd_ignore_table(T) wsrep_service->wsrep_thd_ignore_table_func(T)
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#define wsrep_thd_trx_seqno(T) wsrep_service->wsrep_thd_trx_seqno_func(T)
fix failures of innodb_plugin tests in --embedded Post-fix for 7e8ed15b95b Also, apply the same innodb fix to xtradb.
2018-09-03 10:27:36 +02:00
#define wsrep_set_data_home_dir(A) wsrep_service->wsrep_set_data_home_dir_func(A)
Galera4
2019-01-23 15:30:00 +04:00
#define wsrep_thd_is_BF(T,S) wsrep_service->wsrep_thd_is_BF_func(T,S)
#define wsrep_thd_is_aborting(T) wsrep_service->wsrep_thd_is_aborting_func(T)
#define wsrep_thd_is_local(T) wsrep_service->wsrep_thd_is_local_func(T)
#define wsrep_thd_self_abort(T) wsrep_service->wsrep_thd_self_abort_func(T)
#define wsrep_thd_append_key(T,W,N,K) wsrep_service->wsrep_thd_append_key_func(T,W,N,K)
#define wsrep_thd_client_state_str(T) wsrep_service->wsrep_thd_client_state_str_func(T)
#define wsrep_thd_client_mode_str(T) wsrep_service->wsrep_thd_client_mode_str_func(T)
#define wsrep_thd_transaction_state_str(T) wsrep_service->wsrep_thd_transaction_state_str_func(T)
#define wsrep_thd_transaction_id(T) wsrep_service->wsrep_thd_transaction_id_func(T)
#define wsrep_thd_bf_abort(T,T2,S) wsrep_service->wsrep_thd_bf_abort_func(T,T2,S)
#define wsrep_thd_order_before(L,R) wsrep_service->wsrep_thd_order_before_func(L,R)
#define wsrep_handle_SR_rollback(B,V) wsrep_service->wsrep_handle_SR_rollback_func(B,V)
#define wsrep_thd_skip_locking(T) wsrep_service->wsrep_thd_skip_locking_func(T)
#define wsrep_get_sr_table_name() wsrep_service->wsrep_get_sr_table_name_func()
#define wsrep_get_debug() wsrep_service->wsrep_get_debug_func()
Fix InnoDB dynamic plugin compile errors on wsrep patch.
2019-04-10 11:19:38 +03:00
#define wsrep_commit_ordered(T) wsrep_service->wsrep_commit_ordered_func(T)
#define wsrep_thd_is_applying(T) wsrep_service->wsrep_thd_is_applying_func(T)
MDEV-21910 Deadlock between BF abort and manual KILL command When high priority replication slave applier encounters lock conflict in innodb, it will force the conflicting lock holder transaction (victim) to rollback. This is a must in multi-master sychronous replication model to avoid cluster lock-up. This high priority victim abort (aka "brute force" (BF) abort), is started from innodb lock manager while holding the victim's transaction's (trx) mutex. Depending on the execution state of the victim transaction, it may happen that the BF abort will call for THD::awake() to wake up the victim transaction for the rollback. Now, if BF abort requires THD::awake() to be called, then the applier thread executed locking protocol of: victim trx mutex -> victim THD::LOCK_thd_data If, at the same time another DBMS super user issues KILL command to abort the same victim, it will execute locking protocol of: victim THD::LOCK_thd_data -> victim trx mutex. These two locking protocol acquire mutexes in opposite order, hence unresolvable mutex locking deadlock may occur. The fix in this commit adds THD::wsrep_aborter flag to synchronize who can kill the victim This flag is set both when BF is called for from innodb and by KILL command. Either path of victim killing will bail out if victim's wsrep_killed is already set to avoid mutex conflicts with the other aborter execution. THD::wsrep_aborter records the aborter THD's ID. This is needed to preserve the right to kill the victim from different locations for the same aborter thread. It is also good error logging, to see who is reponsible for the abort. A new test case was added in galera.galera_bf_kill_debug.test for scenario where wsrep applier thread and manual KILL command try to kill same idle victim
2020-05-19 11:12:26 +03:00
#define wsrep_thd_set_wsrep_aborter(T) wsrep_service->wsrep_thd_set_wsrep_aborter_func(T1, T2)
Merge 10.3 into 10.4
2020-09-21 12:29:00 +03:00
#define wsrep_report_bf_lock_wait(T,I) wsrep_service->wsrep_report_bf_lock_wait(T,I)
MDEV-26803 PA unsafety with FK cascade delete operation This commit has a mtr test where two two transactions delete a row from two separate tables, which will cascade a FK delete for the same row in a third table. Second replica node is configured with 2 applier threads, and the test will fail if these two transactions are applied in parallel. The actual fix, in this commit, is to mark a transaction as unsafe for parallel applying when it traverses into cascade delete operation. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-12-09 18:12:20 +02:00
#define wsrep_thd_set_PA_unsafe(T) wsrep_service->wsrep_thd_set_PA_unsafe_func(T)
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#else
Galera4
2019-01-23 15:30:00 +04:00
#define MYSQL_SERVICE_WSREP_STATIC_INCLUDED
WSREP debug log levels support Global variable wsrep_debug now can be used to filter wsrep-lib messages based on debug level provided. Type of wsrep_debug is now set to be unsigned int, so tests and configuration files changed accordingly.
2019-02-12 12:32:42 +01:00
extern ulong wsrep_debug;
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
extern my_bool wsrep_log_conflicts;
extern my_bool wsrep_certify_nonPK;
extern my_bool wsrep_load_data_splitting;
extern my_bool wsrep_drupal_282555_workaround;
Merge branch '10.0-galera' into 10.1
2015-07-14 16:05:29 -04:00
extern my_bool wsrep_recovery;
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
extern long wsrep_protocol_version;
Galera4
2019-01-23 15:30:00 +04:00
extern "C" bool wsrep_consistency_check(MYSQL_THD thd);
bool wsrep_prepare_key_for_innodb(MYSQL_THD thd, const unsigned char* cache_key, size_t cache_key_len, const unsigned char* row_id, size_t row_id_len, struct wsrep_buf* key, size_t* key_len);
extern "C" const char *wsrep_thd_query(const MYSQL_THD thd);
extern "C" int wsrep_is_wsrep_xid(const void* xid);
extern "C" long long wsrep_xid_seqno(const struct xid_t* xid);
MDEV-15505 Fix wsrep XID seqno byte order The problem is that the seqno part of wsrep XID is always stored in host byte order. This may cause issues when a physical backup is restored on a host with different architecture, the seqno part with XID may have incorrect value. In order to fix this, wsrep XID seqno is always written into XID data buffer in little endian byte order using int8store() and read from data buffer using sint8korr(). For backwards compatibility the seqno is read from TRX_SYS page in host byte order during upgrade. This patch implements byte ordering in wsrep_xid_init(), wsrep_xid_seqno(), and exposes functions to read wsrep XID uuid and seqno in wsrep_service_st. Backwards compatibility for upgrade is provided in trx_rseg_init_wsrep_xid().
2018-03-07 18:40:15 +02:00
const unsigned char* wsrep_xid_uuid(const struct xid_t* xid);
Galera4
2019-01-23 15:30:00 +04:00
extern "C" long long wsrep_thd_trx_seqno(const MYSQL_THD thd);
Merge branch '10.0-galera' into 10.1
2015-07-14 16:05:29 -04:00
my_bool get_wsrep_recovery();
Galera4
2019-01-23 15:30:00 +04:00
bool wsrep_thd_ignore_table(MYSQL_THD thd);
fix failures of innodb_plugin tests in --embedded Post-fix for 7e8ed15b95b Also, apply the same innodb fix to xtradb.
2018-09-03 10:27:36 +02:00
void wsrep_set_data_home_dir(const char *data_dir);
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
Galera4
2019-01-23 15:30:00 +04:00
/* from mysql wsrep-lib */
#include "my_global.h"
#include "my_pthread.h"
/* Return true if wsrep is enabled for a thd. This means that
wsrep is enabled globally and the thd has wsrep on */
extern "C" my_bool wsrep_on(const MYSQL_THD thd);
/* Lock thd wsrep lock */
extern "C" void wsrep_thd_LOCK(const MYSQL_THD thd);
/* Unlock thd wsrep lock */
extern "C" void wsrep_thd_UNLOCK(const MYSQL_THD thd);
Merge branch 'bb-10.3-release' into bb-10.4-release Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution" was null-merged. 10.4 version of the fix is coming up separately
2021-02-12 17:44:22 +01:00
extern "C" void wsrep_thd_kill_LOCK(const MYSQL_THD thd);
extern "C" void wsrep_thd_kill_UNLOCK(const MYSQL_THD thd);
Galera4
2019-01-23 15:30:00 +04:00
/* Return thd client state string */
extern "C" const char* wsrep_thd_client_state_str(const MYSQL_THD thd);
/* Return thd client mode string */
extern "C" const char* wsrep_thd_client_mode_str(const MYSQL_THD thd);
/* Return thd transaction state string */
extern "C" const char* wsrep_thd_transaction_state_str(const MYSQL_THD thd);
/* Return current transaction id */
extern "C" query_id_t wsrep_thd_transaction_id(const MYSQL_THD thd);
/* Mark thd own transaction as aborted */
extern "C" void wsrep_thd_self_abort(MYSQL_THD thd);
/* Return true if thd is in replicating mode */
extern "C" my_bool wsrep_thd_is_local(const MYSQL_THD thd);
/* Return true if thd is in high priority mode */
/* todo: rename to is_high_priority() */
extern "C" my_bool wsrep_thd_is_applying(const MYSQL_THD thd);
MDEV-21910 Deadlock between BF abort and manual KILL command When high priority replication slave applier encounters lock conflict in innodb, it will force the conflicting lock holder transaction (victim) to rollback. This is a must in multi-master sychronous replication model to avoid cluster lock-up. This high priority victim abort (aka "brute force" (BF) abort), is started from innodb lock manager while holding the victim's transaction's (trx) mutex. Depending on the execution state of the victim transaction, it may happen that the BF abort will call for THD::awake() to wake up the victim transaction for the rollback. Now, if BF abort requires THD::awake() to be called, then the applier thread executed locking protocol of: victim trx mutex -> victim THD::LOCK_thd_data If, at the same time another DBMS super user issues KILL command to abort the same victim, it will execute locking protocol of: victim THD::LOCK_thd_data -> victim trx mutex. These two locking protocol acquire mutexes in opposite order, hence unresolvable mutex locking deadlock may occur. The fix in this commit adds THD::wsrep_aborter flag to synchronize who can kill the victim This flag is set both when BF is called for from innodb and by KILL command. Either path of victim killing will bail out if victim's wsrep_killed is already set to avoid mutex conflicts with the other aborter execution. THD::wsrep_aborter records the aborter THD's ID. This is needed to preserve the right to kill the victim from different locations for the same aborter thread. It is also good error logging, to see who is reponsible for the abort. A new test case was added in galera.galera_bf_kill_debug.test for scenario where wsrep applier thread and manual KILL command try to kill same idle victim
2020-05-19 11:12:26 +03:00
/* set wsrep_aborter for the target THD */
extern "C" bool wsrep_thd_set_wsrep_aborter(MYSQL_THD bf_thd, MYSQL_THD victim_thd);
Galera4
2019-01-23 15:30:00 +04:00
/* Return true if thd is in TOI mode */
extern "C" my_bool wsrep_thd_is_toi(const MYSQL_THD thd);
/* Return true if thd is in replicating TOI mode */
extern "C" my_bool wsrep_thd_is_local_toi(const MYSQL_THD thd);
/* Return true if thd is in RSU mode */
extern "C" my_bool wsrep_thd_is_in_rsu(const MYSQL_THD thd);
/* Return true if thd is in BF mode, either high_priority or TOI */
extern "C" my_bool wsrep_thd_is_BF(const MYSQL_THD thd, my_bool sync);
/* Return true if thd is streaming */
extern "C" my_bool wsrep_thd_is_SR(const MYSQL_THD thd);
extern "C" void wsrep_handle_SR_rollback(MYSQL_THD BF_thd, MYSQL_THD victim_thd);
/* Return thd retry counter */
extern "C" int wsrep_thd_retry_counter(const MYSQL_THD thd);
/* BF abort victim_thd */
MDEV-20848 Fixes for MTR test galera_sr.GCF-1060 (#1421) This patch contains two fixes: * wsrep_handle_mdl_conflict(): handle the case where SR transaction is in aborting state. Previously, a BF-BF conflict was reported, and the process would abort. * wsrep_thd_bf_abort(): do not restore thread vars after calling wsrep_bf_abort(). Thread vars are already restored in wsrep-lib if necessary. This also removes the assumption that the caller of wsrep_thd_bf_abort() is the given bf_thd, which is not the case. Also in this patch: * Remove unnecessary check for active victim transaction in wsrep_thd_bf_abort(): the exact same check is performed later in wsrep_bf_abort(). * Make wsrep_thd_bf_abort() and wsrep_log_thd() const-correct. * Change signature of wsrep_abort_thd() to take THD pointers instead of void pointers.
2019-12-04 08:21:14 +01:00
extern "C" my_bool wsrep_thd_bf_abort(MYSQL_THD bf_thd,
Galera4
2019-01-23 15:30:00 +04:00
MYSQL_THD victim_thd,
my_bool signal);
/* Return true if left thd is ordered before right thd */
extern "C" my_bool wsrep_thd_order_before(const MYSQL_THD left, const MYSQL_THD right);
/* Return true if thd should skip locking. This means that the thd
is operating on shared resource inside commit order critical section. */
extern "C" my_bool wsrep_thd_skip_locking(const MYSQL_THD thd);
/* Return true if thd is aborting */
extern "C" my_bool wsrep_thd_is_aborting(const MYSQL_THD thd);
struct wsrep_key;
struct wsrep_key_array;
extern "C" int wsrep_thd_append_key(MYSQL_THD thd,
const struct wsrep_key* key,
int n_keys,
enum Wsrep_service_key_type);
extern const char* wsrep_sr_table_name_full;
extern "C" const char* wsrep_get_sr_table_name();
extern "C" my_bool wsrep_get_debug();
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
extern "C" void wsrep_commit_ordered(MYSQL_THD thd);
Fix InnoDB dynamic plugin compile errors on wsrep patch.
2019-04-10 11:19:38 +03:00
extern "C" my_bool wsrep_thd_is_applying(const MYSQL_THD thd);
MDEV-21910 Deadlock between BF abort and manual KILL command When high priority replication slave applier encounters lock conflict in innodb, it will force the conflicting lock holder transaction (victim) to rollback. This is a must in multi-master sychronous replication model to avoid cluster lock-up. This high priority victim abort (aka "brute force" (BF) abort), is started from innodb lock manager while holding the victim's transaction's (trx) mutex. Depending on the execution state of the victim transaction, it may happen that the BF abort will call for THD::awake() to wake up the victim transaction for the rollback. Now, if BF abort requires THD::awake() to be called, then the applier thread executed locking protocol of: victim trx mutex -> victim THD::LOCK_thd_data If, at the same time another DBMS super user issues KILL command to abort the same victim, it will execute locking protocol of: victim THD::LOCK_thd_data -> victim trx mutex. These two locking protocol acquire mutexes in opposite order, hence unresolvable mutex locking deadlock may occur. The fix in this commit adds THD::wsrep_aborter flag to synchronize who can kill the victim This flag is set both when BF is called for from innodb and by KILL command. Either path of victim killing will bail out if victim's wsrep_killed is already set to avoid mutex conflicts with the other aborter execution. THD::wsrep_aborter records the aborter THD's ID. This is needed to preserve the right to kill the victim from different locations for the same aborter thread. It is also good error logging, to see who is reponsible for the abort. A new test case was added in galera.galera_bf_kill_debug.test for scenario where wsrep applier thread and manual KILL command try to kill same idle victim
2020-05-19 11:12:26 +03:00
extern "C" bool wsrep_thd_set_wsrep_aborter(MYSQL_THD bf_thd, MYSQL_THD victim_thd);
Merge 10.3 into 10.4
2020-09-21 12:29:00 +03:00
extern "C" void wsrep_report_bf_lock_wait(const THD *thd,
unsigned long long trx_id);
MDEV-26803 PA unsafety with FK cascade delete operation This commit has a mtr test where two two transactions delete a row from two separate tables, which will cascade a FK delete for the same row in a third table. Second replica node is configured with 2 applier threads, and the test will fail if these two transactions are applied in parallel. The actual fix, in this commit, is to mark a transaction as unsafe for parallel applying when it traverses into cascade delete operation. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2021-12-09 18:12:20 +02:00
/* declare parallel applying unsafety for the THD */
extern "C" void wsrep_thd_set_PA_unsafe(MYSQL_THD thd);
fixing embedded: WaaS. Wsrep as a Service.
2014-09-27 22:29:10 +02:00
#endif
Galera4
2019-01-23 15:30:00 +04:00
#endif /* MYSQL_SERVICE_WSREP_INCLUDED */
Reference in a new issue Copy permalink