| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The galera.galera_parallel_autoinc_manytrx mtr test opens and runs test
scenario through 3 connections to node 1 and one connection to node 2.
In the test initialization phase, the test creates two tables 't1' and 'ten'
and then creates a stored procedure 'p1' to operate on these tables.
These 3 create DDL statements are issued through same connection to node 1.
In the next test phase, the mtr script uses send command to launch the call
for the p1 stored procedure through all 3 connections to node 1 and through
one connection to node 2. As the mtr send command is asynchronous,
this test phase is non blocking and fast operation.
Now, if the replication between nodes is slow, it may happen that the
initialization phase DDL statements have not been received or have not been
fully applied in node 2. Therefore there is no guarantee that the test tables
and the stored procedure have been created in node 2. Yet, the test is trying
to call p1 in node 2.
In the failure case error logs, there is error message
"MTR failed: query 'reap' failed: 1305: PROCEDURE test.p1 does not exist"
The reap command through connection to node 2, is the first place where test
execution may observe that test tables and/or stored procedure are not yet
created in node 2.
The fix in this commit adds a wait condition in connection to node 2, to wait
until the stored procedure is created before calling the stored procedure.
The wait is implemented by looking in information_schema.routines for the p1
stored procedure.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
drop database `fts`.`` though there are still open handles
MDEV-22140 galera.galera_drop_database MTR failed: InnoDB: MySQL is trying to drop database `fts`.`` though there are still open handles
Add wait conditions to wait that all operations are done in both
nodes.
|
| | |
| |
| |
| |
| |
| | |
galera.galera_var_innodb_disallow_writes: Result length mismatch
Add wait_conditions to force desired execution.
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Backported the support for aborting and replaying stored procedure and fix for trigger
key assigments from 10.4 version.
Backported also two mtr tests: wsrep_sp_bf_abort and MDEV-20225
|
| | |
| |
| |
| |
| |
| | |
'reap' succeeded - should have failed with errno 1213
Test cleanup.
|
| | |
| |
| |
| |
| | |
Enable tests with additional galera output to find out actual
reason for test failures.
|
| | |
| |
| |
| |
| |
| |
| | |
galera.galera_as_slave_gtid_myisam: Result length mismatch
Add wait_condition so that drop table has time to replicate to
Galera cluster.
|
| | |
| |
| |
| |
| |
| |
| | |
galera.galera_wsrep_new_cluster: Result content mismatch
Test starts two servers and we do not know order they really start,
thus wsrep_local_index can be 1 or 2.
|
| | |
| |
| |
| |
| |
| |
| | |
Result content mismatch
Add wait_condition to make sure that node contains all the rows
expected.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a backport of the applicable part of
commit 93475aff8de80a0ef53cbee924bcb70de6e86f2c and
commit 2c39f69d34e64a5cf94720e82e78c0ee91bd4649
from 10.4.
Before 10.4 and Galera 4, WSREP_ON is a macro that points to
a global Boolean variable, so it is not that expensive to
evaluate, but we will add an unlikely() hint around it.
WSREP_ON_NEW: Remove. This macro was introduced in
commit c863159c320008676aff978a7cdde5732678f975
when reverting WSREP_ON to its previous definition.
We replace some use of WSREP_ON with WSREP(thd), like it was done
in 93475aff8de80a0ef53cbee924bcb70de6e86f2c. Note: the macro
WSREP() in 10.1 is equivalent to WSREP_NNULL() in 10.4.
Item_func_rand::seed_random(): Avoid invoking current_thd
when WSREP is not enabled.
|
| | |
| |
| |
| |
| |
| |
| | |
'dbug
Test do we have galera debug library with debug_sync functionality
needs to be earlier.
|
| | |
| |
| |
| |
| |
| | |
When binlog is disabled, WSREP will not behave correctly when
SAVEPOINT ROLLBACK is executed since we don't register handlers for such case.
Fixed by registering WSREP handlerton for SAVEPOINT related commands.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If async replication slave thread conflicts with cluster replication,
then the async slave transaction should be BF aborted, and depending on the
state of async slave transaction execution, potentially also replayed.
There were problems in such BF abort implementation and the replaying was not
started.
This pull request contains fixes which make sure that if async slave thread is
marked to abort and replay, it will complete carry out the rollback and
release all locks and resources before starting the replaying. After replaying,
async slave transactions is treated as successful, so the slave thread will
continue as usual, handling next replication event.
There is also new mtr test: galera.galera_slave_replay, which stresses both a
certification failure for async slave thread and a successful BF abort
followed by replaying.
|
| | |
| |
| |
| | |
Add missing wait condition before we check the end database state.
|
| | |
| |
| |
| | |
Add wait condition and cleanup.
|
| | |
| |
| |
| |
| |
| |
| | |
galera.galera_wsrep_new_cluster: Result content mismatch
Use correct configuration and wait for nodes to reach correct state
with wait conditions.
|
| | |
| |
| |
| |
| |
| |
| | |
galera.galera_as_slave_gtid_myisam: Result length mismatch
In Galera 3 nodes 2 and 3 are galera nodes and node_1 should be
non galera.
|
| | |
| |
| |
| | |
Add proper wait condition instead of sleeps.
|
| | |
| |
| |
| |
| |
| | |
Problem seems to be the fact that we did not enforce correct
applier thread numbers after every command that effects them.
Test changes only.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names
This should not be merged upwards.
|
| | |
| |
| |
| |
| | |
Add wait conditions to make sure correct number of rows have
been replicated.
|
| | |
| |
| |
| | |
Add wait condition for event creation.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The long semaphore wait appeared to be the caused by the following
pattern in the MTR test:
```
SET DEBUG_SYNC = "now SIGNAL wsrep_after_certification_continue";
SET DEBUG_SYNC = "now SIGNAL signal.wsrep_apply_cb;
```
Raising two signals, one right after another, caused one signal to
overwrite the other, before the signal was consumed by the thread.
This caused one thread to be stuck until the debug sync point would
timeout.
|
| | |
| |
| |
| |
| |
| |
| | |
sql_log_bin = 0' cases the galera node to hang
Test cleanup. Best practice for using RSU, is to isolate the node
up-front, so this test did not reflect real world scenario
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sql_log_bin = 0' cases the galera node to hang
Found two bugs
(1) have_committing_connections was missing mutex unlock on one
exit case. As this function is called on a loop it caused mutex
lock when we already owned the mutex. This could cause hang.
(2) wsrep_RSU_begin did set up error code when partition to
be dropped could not be MDL-locked because of concurrent
operations but wrong error code was propagated to upper layer
causing error to be ignored. This could have also caused
the hang.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem happens when MariaDB master replicates writes for only non InnoDB
tables (e.g. writes to MyISAM table(s)). Async slave node, in Galera cluster,
can apply these writes successfully, but it will, in the end, write gtid position in
mysql.gtid_slave_pos table. mysql.gtid_slave_pos table is InnoDB engine, and
this write makes innodb handlerton part of the replicated "transaction".
Note that wsrep patch identifies that write to gtid_slave_pos should not be replicated
and skips appending wsrep keys for these writes. However, as InnoDB was present
in the transaction, and there are replication events (for MyISAM table) in transaction
cache, but there are no appended keys, wsrep raises an error, and this makes the söave
thread to stop.
The fix is simply to not treat it as an error if async slave tries to replicate a write
set with binlog events, but no keys. We just skip wsrep replication and return successfully.
This commit contains also a mtr test which forces mysql.gtid_slave_pos table isto be
of InnoDB engine, and executes MyISAM only write through asyn replication.
There is additional fix for declaring IO and background slave threads as non wsrep.
These threads should not write anything for wsrep replication, and this is just a safeguard
to make sure nothing leaks into cluster from these slave threads.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(#1410)
This PR contains a mtr test for reproducing a failure with replicating create table as select statement (CTAS) through asynchronous mariadb replication to mariadb galera cluster.
The problem happens when CTAS replication contains both create table statement followed by row events for populating the table. In such situation, the galera node operating as mariadb replication slave, will first replicate only the create table part into the cluster, and then perform another replication containing both the create table and row events. This will lead all other nodes to fail for duplicate table create attempt, and crash due to this failure.
PR contains also a fix, which identifies the situation when CTAS has been replicated, and makes further scan in async replication stream to see if there are following row events. The slave node will replicate either single TOI in case the CTAS table is empty, or if CTAS table contains rows, then single bundled write set with create table and row events is replicated to galera cluster.
This fix should keep master server's GTID's for CTAS replication in sync with GTID's in galera cluster.
|
| | |
| |
| |
| | |
Add proper wsrep sync wait.
|
| | |
| |
| |
| |
| | |
galera_2nodes.cnf did not contain wsrep_on=1 on correct places. Fixed
restart options to use correct configuration.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Command COM_SHUTDOWN was rejected in non-Primary because
server_command_flags[COM_SHUTDOWN] had value CF_NO_COM_MULTI
instead of CF_SKIP_WSREP_CHECK.
As a fix removed assignment
server_command_flags[CF_NO_COM_MULTI]= CF_NO_COM_MULTI
which overwrote server_command_flags[COM_SHUTDOWN].
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
After SST from master node (the one where event is ENABLED) - you will end up with the event enabled on two nodes, hence it's now being executed twice. It can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED'
Changes to be committed:
new file: mysql-test/suite/galera/r/galera_events2.result
new file: mysql-test/suite/galera/t/galera_events2.test
modified: sql/events.cc
|
| | | |
|
| | |
| |
| |
| | |
Test changes only.
|
| | |
| |
| |
| |
| | |
Add wait conditions and compare cardinality etc information
between nodes and print something only if they differ.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The execution of mtr in the Windows environment fails due to
the fact that the new code from MDEV-18565 does not take into
account the need to add the ".exe" extension to the names of
executable files when searching for pre-requisites that are
needed to run SST scripts (especially when using mariabackup)
and when searching paths to some other Galera utilities.
This patch fixes this flaw.
Also adding paths to the PATH environment variable is now
done with the correct delimiter character.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Galera threads were not registered to performance schema and
used pthread_create when mysql_thread_create should have been
used.
Added test case to verify current galera performance schema
instrumentation does work.
|
| | |
| |
| |
| | |
Test changes only.
|
