The test assumes that `@@global.auto_increment_offset` is equal to
`wsrep_local_index + 1`. Which is normally the case if galera runs
with option `wsrep_auto_increment_control` enabled.
However, if some prior test performs a restart of a server, then
`wsrep_local_index` may change, and galera will set the value of
`auto_increment_offset` accordingly.
However, if `auto_increment_offset` changes during a test run, then
mtr will complain. To avoid that, tests that perform restarts include
`auto_increment_offset_save.inc` and `auto_increment_offset_restore.inc`.
Which reset the value of `auto_increment_offset`. And when that
happens, `auto_increment_offset` will no longer be equal to
`wsrep_local_index + 1`, and the test fails.
To avoid this problem, simply check that the offsets are different
on the nodes that compose the cluster.
The test was not deterministic and would occasionally fail, due to the
use of `sleep`.
This patch is a complete rewrite of the test using proper sync points.
The test performs a restart and while doing so it occasionally
fails with "Server did not transition to READY state" in
`include/start_mysqld.inc".
Fix is to wait for the cluster to shrink before restarting
the node.
While the test case crashes a MariaDB 10.2 debug build only,
let us apply the fix to the earliest applicable MariaDB series (10.0)
to avoid any data corruption on a table-rebuilding ALTER TABLE
using ALGORITHM=INPLACE.
innobase_create_key_defs(): Use altered_table->s->primary_key
when a new primary key is being created.
* Increased timeout counter in galera_wait_ready.inc
* Replaced useless include/wait_until_ready.inc after start_mysqld.inc
in galera_st_*.inc with wait_condition on cluster size.
Test galera_sst_mysqldump often fails with error "2013: Lost connection
to MySQL server during query". The connection is lost after the test
restart one of the nodes. This happens because the server closes client
connections if it is joining a cluster through SST method mysqldump.
On unlucky runs of the test it is possible that mysqld is restarted,
and then mtr client is disconnected while it tries to determine if
galera is ready before going on with the test.
This patch rewrites galera_wait_ready.inc so that it is immune to
being disconnected.
ALTER TABLE ... ADD PARTITION modifies the open TABLE structure,
and sets table->need_reopen=1 to reset these modifications
in case of an error.
But under LOCK TABLES the table isn't get reopened, despite need_reopen.
Fixed by reopening need_reopen tables under LOCK TABLE.
disable online alter add primary key for innodb, if the
table is opened/locked more than once in the current connection
(see assert in ha_innobase::add_index())
This patch fixes a lock wait timeout error on `SELECT @@GLOBAL.WSREP_ON`
in `wait_wsrep_ready.inc`:
```
--connection node_2
...
--source include/kill_galera.inc
--connection node_1
--source include/wait_until_connected_again.inc # This includes wait_wsrep_ready.inc
```
The problem is that on node_2, kill_galera.inc may return before
the node is killed. So node_1 may still see that node_1 is alive
and will attempt to sync wait when doing those `SELECT` statements.
But sync wait is doomed to fail given that node_1 is killed, hence
the lock wait timeout.
One possible fix is to disable wsrep_sync_wait before including
wait_until_connected_again.
However, it appears that including wait_until_connected_again is
not necessary at all in node_1, so this patch removes it altogether.
System tablespace can be specified with absolute path, if innodb_data_home_dir
is empty.
This was not handled well by mariabackup
1. In backup phase, empty innodb_data_home_dir variable from server was
not recognized. full paths were stored in backup-my.ini, even if
it stored all files locally. thus prepare phase would not find the system
tablespace files.
2. In copy-back phase, copy would not be done to the absolute destination
path, as path would be stripped with trim_dotslash
This patch fixes the above defects.
This patch makes two changes:
* Remove unnecessary `set SESSION wsrep_sync_wait=0`.
Disabling `wsrep_sync_wait` caused the test to fail occasionally,
due to subsequent `SELECT`s observing stale values.
* Remove redundant `--source include/galera_wait_ready.inc`,
`galera_wait_ready.inc` is already included in the above
`wait_until_connected_again.inc`
Test would occasionally fail as follows:
```
mysqltest: At line 20: query 'SELECT COUNT(*) = 0 FROM t1' failed:
1317: Query execution was interrupted
```
This was due to a `CREATE TABLE` applied concurrently that would
occasionally cause the `SELECT` to be BF aborted, due to MDL
conflict.
The `SELECT` is executed while `wsrep_on=OFF`. The change makes sure
it is executed only after wsrep is enabled again.
The test tends to fail if many parallel instances of it are executed:
```
mysqltest: At line 23: query 'ALTER TABLE t1 ADD PRIMARY KEY (f1)' failed:
1317: Query execution was interrupted
```
The `ALTER` fails because it is BF aborted due to an earlier `INSERT SELECT`
that is being applied:
```
INSERT INTO t1 (f1) SELECT ...
--connection node_2
SET GLOBAL wsrep_desync = TRUE;
SET SESSION wsrep_on = FALSE;
ALTER TABLE t1 ADD PRIMARY KEY (f1);
SET SESSION wsrep_on = TRUE;
SET GLOBAL wsrep_desync = FALSE;
```
And because the `ALTER` is executed with `wsrep_on = OFF`, it does not
run in total order isolation.
To avoid the problem it must be ensured that the `ALTER` only after the
large `INSERT SELECT` is done. To do so it is sufficient to issue
`SELECT COUNT(*) FROM t1;` from `node_2` before turning off wsrep.
The `SELECT` will trigger `wsrep_sync_wait` and proceed only after the
`INSERT SELECT` from node_1 is done.
Problem was that key rotation from encrypted to unecrypted was skipped
when encryption is disabled (i.e. set global innodb-encrypt-tables=OFF).
fil_crypt_needs_rotation
If encryption is disabled (i.e. innodb-encrypt-tables=off)
and there is tablespaces using default encryption (e.g.
system tablespace) that are still encrypted state we need
to rotate them from encrypted state to unencrypted state.
The following changes are committed:
* `RESET MASTER` at the end of the test. This was necessary to allow the test
to run on repeated runs.
* `--source include/galera_wait_ready.inc` after setting `gmcast.isolate=0` to
get back to a primary component.
* Fix for assertion in `Protocol::end_statement()`. The assertion is due to
the fact that function `do_command()` calls `thd->protocol->end_statement()`,
without setting an error, when it is detected that galera is not ready yet.
Following line somehow disappeared in a past merge:
```
my_message(ER_UNKNOWN_COM_ERROR,
"WSREP has not yet prepared node for application use", MYF(0));
```
Test galera checks that a `GRA_x_x.log` file is created whenever
wsrep applier fails to apply some replication event. The file
contains the corresponding binlog event that failed to apply.
The test creates a new file by concatenating a pre-recorded
file containing the binlog header (see `std-data/binlog-header.log`)
and the `GRA_x_x.log` file. The test then checks that the resulting
file, containing the binlog header and the event that failed to
apply, is correctly read by `mysqlbinlog` program.
The test fails in MariaDB because the GRA_x_x.log file created
by MariaDB already contains the binlog header (see MDEV-7867).
This patch fixes/simplifies test `galera.galera_gra_log` so that
it doesn't concatenate `std-data/binlog-header.log` with the
`GRA_x_x.log` file. File `std-data/binlog-header.log` is deleted
altoghether, because not used by any other test.
