summaryrefslogtreecommitdiff
path: root/mysql-test/suite/galera_sr
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.9 into 10.10Marko Mäkelä2022-09-211-1/+1
|\
| * Merge 10.5 into 10.6Marko Mäkelä2022-09-201-1/+1
| |\
| | * Merge remote-tracking branch 'origin/10.4' into 10.5Alexander Barkov2022-09-141-1/+1
| | |\
| | | * A cleanup for MDEV-29446 Change SHOW CREATE TABLE to display default collationAlexander Barkov2022-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recording test results according to MDEV-29446 changes: mysql-test/suite/galera/r/MDEV-25494.result mysql-test/suite/galera/r/galera_ctas.result mysql-test/suite/galera/r/galera_schema.result mysql-test/suite/galera_3nodes/r/galera_wsrep_schema.result mysql-test/suite/galera_sr/r/galera_sr_create_drop.result
* | | | galera tests fail with "TLS/SSL error: Success (0)"Sergei Golubchik2022-09-131-0/+4
|/ / / | | | | | | | | | fix the error in C/C, disable tests until the C/C is updated
* | | Merge 10.5 into 10.6Marko Mäkelä2022-05-251-4/+1
|\ \ \ | |/ /
| * | Update galera_sr disabled.def filebb-10.5-galeraJan Lindström2022-05-241-4/+1
| | |
* | | Merge branch '10.5' into 10.6mariadb-10.6.8Sergei Golubchik2022-05-182-0/+4
|\ \ \ | |/ /
| * | Merge branch '10.4' into 10.5mariadb-10.5.16Sergei Golubchik2022-05-182-0/+4
| |\ \ | | |/
| | * galera.MDEV-26575 and galera_sr.galera_sr_shutdown_slave failuresSergei Golubchik2022-05-162-0/+4
| | |
* | | Merge branch '10.5' into 10.6Sergei Golubchik2022-05-101-1/+0
|\ \ \ | |/ /
| * | Merge branch '10.4' into 10.5Sergei Golubchik2022-05-091-1/+0
| |\ \ | | |/
| | * Enable fixed test casesJan Lindström2022-05-031-1/+0
| | |
* | | Merge 10.5 into 10.6Marko Mäkelä2022-03-293-15/+76
|\ \ \ | |/ /
| * | Merge 10.4 into 10.5Marko Mäkelä2022-03-293-15/+76
| |\ \ | | |/
| | * Disable failing Galera testsJan Lindström2022-03-291-0/+1
| | |
| | * Fixup for MDEV-27553Daniele Sciascia2022-03-182-15/+75
| | | | | | | | | | | | | | | | | | | | | | | | Update wsrep-lib which contains a fixup introduced with MDEV-27553. Also, adapt the corresponding test: after apply failure on ROLLBACK, node will disconnect from cluster Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | update test resultSergei Golubchik2022-02-061-1/+1
| | |
* | | Merge branch '10.5' into 10.6Oleksandr Byelkin2022-02-036-0/+157
|\ \ \ | |/ /
| * | Merge branch '10.4' into 10.5Oleksandr Byelkin2022-02-014-0/+155
| |\ \ | | |/
| | * MDEV-27615 Assertion `server_id.is_undefined() == false' failedDaniele Sciascia2022-01-272-0/+99
| | | | | | | | | | | | | | | | | | | | | Add test case that reproduces the issue and update wsrep-lib submodule to include the fix. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| | * Add have_debug.incJan Lindström2022-01-251-0/+1
| | |
| | * MDEV-27553 Assertion `inited==INDEX' failed: in ha_index_end()Daniele Sciascia2022-01-242-0/+55
| | | | | | | | | | | | | | | | | | | | | In wsrep_schema code, call ha_index_end() only if the corresponding ha_index_init() call succeeded. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
| * | MDEV-26223 Galera cluster node consider old server_id value even after ↵mkaruza2022-01-272-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | modification of server_id [wsrep_gtid_mode=ON] Variable `wsrep_new_cluster` now will be TRUE also when there is only `gcomm://` used in configuration. This configuration, even without --wsrep-new-cluster, is considered to bootstrap new cluster. Updated galera GTID test to ignore warning message when non bootstrap node have server-id different thant one cluster is initialized with. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | Merge 10.5 into 10.6Marko Mäkelä2022-01-042-0/+24
|\ \ \ | |/ /
| * | Merge branch 10.4 into 10.5st-10.5-juliusJulius Goryavsky2021-12-262-0/+24
| |\ \ | | |/
| | * Only apply wsrep_trx_fragment_size to InnoDB tablesMonty2021-12-232-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com> Added test case
| | * Enable galera_sr.GCF-1060 test case as it is now fixed.Jan Lindström2021-12-171-1/+0
| | |
* | | Merge 10.5 into 10.6Marko Mäkelä2021-09-242-12/+8
|\ \ \ | |/ /
| * | Merge 10.4 into 10.5Marko Mäkelä2021-09-242-12/+8
| |\ \ | | |/
| | * MDEV-26571 : galera_sr.GCF-627 MTR failed: Result length mismatchJan Lindström2021-09-232-12/+8
| | | | | | | | | | | | | | | Test changes only: do not output mysql.wsrep_streaming_log contents.
* | | Merge 10.5 into 10.6Marko Mäkelä2021-09-163-0/+63
|\ \ \ | |/ /
| * | Merge branch '10.4' into 10.5Monty2021-09-153-0/+63
| |\ \ | | |/ | | | | | | Fixed also an error in suite/perfschema/t/transaction_nested_events-master.opt
| | * MDEV-21613 Failed to open table mysql.wsrep_streaming_log for writingbb-10.4-MDEV-21613Daniele Sciascia2021-09-143-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix sporadic failure for MTR test galera_sr.GCF-1018B. The test sometimes fails due to an error that is logged to the error log unnecessarily. A deterministic test case (included in this patch) shows that the error is loggen when a transaction is BF aborted right before it opens the streaming log table to perform fragment removal. When that happens, the attempt to open the table fails and consequently an error is logged. There is no need to log this error, as an ER_LOCK_DEADLOCK error is returned to the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | Merge 10.5 into 10.6Marko Mäkelä2021-09-113-0/+97
|\ \ \ | |/ /
| * | Merge remote-tracking branch 'upstream/10.4' into 10.5Vicențiu Ciorbaru2021-09-103-0/+97
| |\ \ | | |/
| | * MDEV-25718 Assertion `transaction.is_streaming()' failedDaniele Sciascia2021-09-063-0/+97
| | | | | | | | | | | | | | | | | | | | | * Update wsrep-lib which contains the fix * Add deterministic test case that reproduces the assertion Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | Merge 10.5 to 10.6Marko Mäkelä2021-08-192-0/+160
|\ \ \ | |/ /
| * | Merge 10.4 into 10.5Marko Mäkelä2021-08-182-0/+160
| |\ \ | | |/
| | * MDEV-25717 Assertion `owning_thread_id_ == wsrep::this_thread::get_id()'Daniele Sciascia2021-08-182-0/+160
| | | | | | | | | | | | | | | | | | | | | A test case to reproduce the issue. The actual fix is in galera library. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | Merge 10.5 into 10.6Marko Mäkelä2021-06-014-8/+166
|\ \ \ | |/ /
| * | Merge 10.4 into 10.5Marko Mäkelä2021-06-014-8/+166
| |\ \ | | |/
| | * MDEV-25769 : Galera test failure on galera_sr.GCF-627Jan Lindström2021-05-262-8/+11
| | | | | | | | | | | | Add wait_condition to wait until streaming log is empty.
| | * MDEV-25551 applying crash with tables without PKsjaakola2021-05-262-0/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The underlying problem with MDEV-25551 turned out to be that transactions having changes for tables with no primary key, were not safe to apply in parallel. This is due to excessive locking in innodb side, and even non related row modifications could end up in lock conflict during applying. The fix for MDEV-25551 has disabled parallel applying for tables with no PK. This fix depends on change for wsrep-lib, where a separate PR allows application to modify transaction flags in wsrep-lib. This commit has also separate mtr test for verifying that transactions modifying a table with no primary key, will not apply in parallel. This test is a modified version of initial test created by Gabor Orosz, the reporterr of MDEV-25551. Another mtr test was added in galera_sr suite, for testing if modifying tables with no primary key would causes issues for streaming replication use cases. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | | MDEV-22189: Change error messages inside code to have mariadb instead ofRucha Deodhar2021-05-241-2/+2
| | | | | | | | | | | | | | | | | | | | | mysql Fix: Changed error messages, rerecorded results and changed other relevant files.
* | | MDEV-24576 Atomic CREATE TABLEMonty2021-05-192-21/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few different cases to consider Logging of CREATE TABLE and CREATE TABLE ... LIKE - If REPLACE is used and there was an existing table, DDL log the drop of the table. - If discovery of table is to be done - DDL LOG create table else - DDL log create table (with engine type) - create the table - If table was created - Log entry to binary log with xid - Mark DDL log completed Crash recovery: - If query was in binary log do nothing and exit - If discoverted table - Delete the .frm file -else - Drop created table and frm file - If table was dropped, write a DROP TABLE statement in binary log CREATE TABLE ... SELECT required a little more work as when one is using statement logging the query is written to the binary log before commit is done. This was fixed by adding a DROP TABLE to the binary log during crash recovery if the ddl log entry was not closed. In this case the binary log will contain: CREATE TABLE xxx ... SELECT .... DROP TABLE xxx; Other things: - Added debug_crash_here() functionality to Aria to be able to test crash in create table between the creation of the .MAI and the .MAD files.
* | | Merge 10.5 into 10.6Marko Mäkelä2021-05-046-19/+103
|\ \ \ | |/ /
| * | Merge 10.4 into 10.5Marko Mäkelä2021-05-036-19/+103
| |\ \ | | |/
| | * MDEV-25553 : Avoid unnecessary rollbacks with SRbb-10.4-MDEV-25553Daniele Sciascia2021-04-286-19/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge 10.5 into 10.6Marko Mäkelä2021-04-211-1/+1
|\ \ \ | |/ /
View Lorry Controller Status