For running the Galera tests, the variable my_disable_leak_check
was set to true in order to avoid assertions due to memory leaks
at shutdown.
Some adjustments due to MDEV-13625 (merge InnoDB tests from MySQL 5.6)
were performed. The most notable behaviour changes from 10.0 and 10.1
are the following:
* innodb.innodb-table-online: adjustments for the DROP COLUMN
behaviour change (MDEV-11114, MDEV-13613)
* innodb.innodb-index-online-fk: the removal of a (1,NULL) record
from the result; originally removed in MySQL 5.7 in the
Oracle Bug #16244691 fix
377774689b
* innodb.create-index-debug: disabled due to MDEV-13680
(the MySQL Bug #77497 fix was not merged from 5.6 to 5.7.10)
* innodb.innodb-alter-autoinc: MariaDB 10.2 behaves like MySQL 5.6/5.7,
while MariaDB 10.0 and 10.1 assign different values when
auto_increment_increment or auto_increment_offset are used.
Also MySQL 5.6/5.7 exhibit different behaviour between
LGORITHM=INPLACE and ALGORITHM=COPY, so something needs to be tested
and fixed in both MariaDB 10.0 and 10.2.
* innodb.innodb-wl5980-alter: disabled because it would trigger an
InnoDB assertion failure (MDEV-13668 may need additional effort in 10.2)
- fixes in innodb to skip wsrep processing (like kill victim) when running in native mysql mode
- similar fixes in mysql server side
- forcing tc_log_dummy in native mysql mode when no binlog used. wsrep hton messes up handler counter
and used to lead in using tc_log_mmap instead. Bad news is that tc_log_mmap does not seem to work at all
This patch includes two fixes:
1) Rollback when wsrep_max_ws_rows is exceeded would not switch
back to previous autocommit mode; and 2) Internal rows counter
would not be reset on implicit commits.
The admin commands in question are:
> OPTIMIZE
> REPAIR
> ANALYZE
For LOCAL or NO_WRITE_TO_BINLOG invocations of these commands, ie
OPTIMIZE LOCAL TABLE <t1>
they are not binlogged as expected.
Also, in addition, they are not executed under TOI.
Hence, they are not propagated to other nodes.
The effect is same as that of wsrep_on=0.
Also added tests for this.
A WSREP_DEBUG for wsrep_register_hton has also been added.
The galera_flush_local test has also been updated for verifying that effects
of NO_WRITE_TO_BINLOG / LOCAL are equivalent to wsrep_on=0 from wsrep
perspective.
(cherry picked from commit 5065122f94a8002d4da231528a46f8d9ddbffdc2)
Conflicts:
sql/sql_admin.cc
sql/sql_reload.cc
sql/wsrep_hton.cc
1. factored XID-related functions to a separate wsrep_xid.cc unit.
2. refactored them to take refrences instead of pointers where appropriate
3. implemented wsrep_get/set_SE_position to take wsrep_uuid_t and wsrep_seqno_t instead of XID
4. call wsrep_set_SE_position() in wsrep_sst_received() to reinitialize SE checkpoint after SST was received, avoid assert() in setting code by first checking current position.
crash of MariaDB/Galera
mysqld crashes during startup when its started with --wsrep-recover
(mysqld_safe.sh). The problem was that during server startup "wsrep"
handle is not initialized for --wsrep-recover and since the condition
to register wsrep hton depended only on 'wsrep_on' global/session
variables (WSREP(thd) macro), it can eventually get registered and
calls to wsrep handle's functions (commit, rollback, etc.) can be
made (SIGSEGV!).
Fixed by adding a check for "wsrep" pointer in WSREP(thd) macro
(added by lp:1367173). Additionally, a check for WSREP(thd)
(instead of checking the availability of wsrep provider) has been
added before invoking wsrep handle's commit & rollback functions.
Merged lp:maria/maria-10.0-galera up to revision 3879.
Added a new functions to handler API to forcefully abort_transaction,
producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These
were added for future possiblity to add more storage engines that
could use galera replication.
This is now otherwise on level wsrep-25.9, but storage/innobase has not been fully merged
wsrep-5.5 is not good source for that, so we probably have to cherry pick innodb changes from wsrep-5.6
