Previously, setting `wsrep_sync_wait = 1` would have an effect on
both SELECT and SHOW statements.
This patch changes wsrep_sync_wait so that bitmask value 1 is used
for SELECT statements, while bitmask value 8 is reserved for SHOW
statements.
It is still possible to achieve sync wait on both SELECT and SHOW
statements by setting `wsrep_sync_wait = 9`.
this disables the check, added in d937916c06
Applications shouldn't police OpenSSL versions that users are using.
And 0.9.8 on Mac OS X seems to have new fixes, despite being "0.9.8"
In summary, wsrep_node_address and wsrep_sst_receive_address can now
be set to IPv6 addresses escaped by []. Rsync SST works out ouf the
box thanks to rsync daemon listening on both IPv4 and IPv6 sockets by
default. For xtrabackup SST onver IPv6 one needs to set sockopt in
the [sst] section of joiner's configuration file to ",pf=ip6" if
using socat as a streamer or to "-6" if using netcat.
This patch fixes two problems that may arise when changing the
value of wsrep_slave_threads:
1) Threads may be leaked if wsrep_slave_threads is changed
repeatedly. Specifically, when changing the number of slave
threads, we keep track of wsrep_slave_count_change, the
number of slaves to start / stop. The problem arises when
wsrep_slave_count_change is updated before slaves had a
chance to exit (threads may take some time to exit, as they
exit only after commiting one more replication event).
The fix is to update wsrep_slave_count_change such that it
reflects the number of threads that already exited or are
scheduled to exit.
2) Attempting to set out of range value for wsrep_slave_threads
(below 1 / above 512) results in wsrep_slave_count_change to
be computed based on the out of range value, even though a
warning is generated and wsrep_slave_threads is set to a
truncated value. wsrep_slave_count_change is computed in
wsrep_slave_threads_check(), which is called before mysql
checks for valid range. Fix is to update wsrep_count_change
whenever wsrep_slave_threads is updated with a valid value.
Applier does not reset thd->wsrep_apply_toi if applier thread decides
to exit by setting 'exit= true'. The problem is that galera side may
decide not to kill the applier thread: for instance if we try to
SET wsrep_slave_threads = 0; then galera refuses to kill the last
applier thread. If this happens we are left with a thd which has not
been reset to the initial state.
This patch ensures that the thd is reset regardless of the applier
thread exiting or not.
buf_page_io_complete(): Do not test bpage for NULL, because
it is declared (and always passed) as nonnull.
buf_flush_batch(): Remove the constant local variable count=0.
fil_ibd_load(): Use magic comment to suppress -Wimplicit-fallthrough.
ut_stage_alter_t::inc(ulint): Disable references to an unused parameter.
lock_queue_validate(), sync_array_find_thread(), rbt_check_ordering():
Define only in debug builds.
Problem was that 4k page size is not really supported in
Galera. For reference see:
codership/galera#398
Page size 4k is problematic because WSREP XID info location
that was set to constant UNIV_PAGE_SIZE - 3500 and that is conflicting
with rseg undo slots location if there is lot of undo tablespaces.
Undo tablespace identifiers and page numbers require
at least 126*8=1024 bytes starting from offset 56. Therefore,
WSREP XID startig from offset 596 would overwrite several
space_id,page_no pairs starting from 72th undo log tablespace
space_id,page_no pair at offset 594.
This will cause InnoDB startup failure seen as
[ERROR] InnoDB: Unable to open undo tablespace './undo30579'.
Originally, the undo tablespace ID would always be between
0 and 127. Starting with MySQL 5.6.36 which introduced
Bug #25551311 BACKPORT BUG #23517560 REMOVE SPACE_ID RESTRICTION
FOR UNDO TABLESPACES (merged to MariaDB 10.0.31)
it is possible for an undo tablespace ID to be 0x7773. But in
this case, the page number should be 3, not 0x72650003.
This is just the first collision. The WSREP XID data would
overwrite subsequent slots.
trx0sys.h
trx0sys.cc
Code formatting and add comments.
The bug is result adding ability to have derived tables inside views.
Fixed checks should be a switch between view/derived or select derived and information schema.
Only a relevant subset of the InnoDB changes was merged.
In particular, two follow-up bug fixes for the bugs that
were introduced in 5.7.18 but not MariaDB 10.2.7 were omitted.
Because MariaDB 10.2.7 omitted the risky change
Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
APPLIED BY UNCOMMITTED ROWS
we do not need the follow-up fixes that were introduced in
MySQL 5.6.37 and MySQL 5.7.19:
Bug#25175249 ASSERTION: (TEMPL->IS_VIRTUAL && !FIELD) || ...
Bug#25793677 INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN
Analysis:
=========
During alter table rebuild, InnoDB fails to apply concurrent insert log.
If the insert log record is present across the blocks then apply phase
trying to access the next block without fetching it.
Fix:
====
During virtual column parsing, check whether the record is present
across the blocks before accessing the virtual column information.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 16243
Analysis:
========
During alter table rebuild, InnoDB fails to apply concurrent delete log.
Parsing and validation of merge record happens while applying the
log operation on a table. Validation goes wrong for the virtual column.
Validation assumes that virtual column information can't be the end
of the merge record end.
Fix:
====
Virtual column information in the merge record can be end of the merge
record. Virtual column information is written at the end for
row_log_table_delete().
Reviewed-by: Satya Bodapati<satya.bodapati@oracle.com>
RB: 16155
The test is for a bug that was introduced in MySQL 5.7.18
but not MariaDB 10.2, because MariaDB did not merge the change
that was considered incomplete and too risky for a GA release:
Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
APPLIED BY UNCOMMITTED ROWS
So, we are only merging the test changes from the bug fix in MySQL 5.7.19,
not any code changes:
commit 4f86aca37d551cc756d9187ec901f8c4a68a0543
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date: Wed Apr 26 11:10:41 2017 +0530
Bug #25793677 INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN
MariaDB 10.2 never contained the Oracle change
Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE
INDEX APPLIED BY UNCOMMITTED ROWS
because it was considered risky for a GA release and incomplete.
Remove the references that were added when merging MySQL 5.6.36
to MariaDB 10.0.31, 10.1.24, and 10.2.7.
Analysis:
========
(1) During TRUNCATE of file_per_table tablespace, dict_operation_lock is
released before eviction of dirty pages of a tablespace from the buffer
pool. After eviction, we try to re-acquire
dict_operation_lock (higher level latch) but we already hold lower
level latch (index->lock). This causes latch order violation
(2) Deadlock issue is present if child table is being truncated and it
holds index lock. At the same time, cascade dml happens and it took
dict_operation_lock and waiting for index lock.
Fix:
====
1) Release the indexes lock before releasing the dict operation lock.
2) Ignore the cascading dml operation on the parent table, for the
cascading foreign key, if the child table is truncated or if it is
in the process of being truncated.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
Reviewed-by: Kevin Lewis <kevin.lewis@oracle.com>
RB: 16122
Issue
====
The issue is that the info message that InnoDB prints when a table
is created with a reference which doesn't exist fills up the log as
it's printed for every insert when foreign_key_checks is disabled.
Fix
===
The fix is to display the message only if foreign_key_checks is
enabled.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
Problem:
=======
Offsets allocates memory from row_heap even for deleted row
traversal during table rebuild.
Solution:
=========
Empty the row_heap even for deleted record. So that
offsets don't allocate memory everytime.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 15694
Cherry-pick the commit from MySQL 5.7.19, and adapt the test case:
commit 45c933ac19c73a3e9c756a87ee1ba18ba1ac564c
Author: Aakanksha Verma <aakanksha.verma@oracle.com>
Date: Tue Mar 21 10:31:43 2017 +0530
Bug #25189192 ERRORS WHEN RESTARTING MYSQL AFTER RENAME TABLE.
PROBLEM
While renaming table innodb doesn't update the InnoDB Dictionary table
INNODB_SYS_DATAFILES incase there is change in database while doing
rename table. Hence on a restart the server log shows error that it
couldnt find table with old path before rename which has actually been
renamed. So the errors would only vanish if we update the system
tablespace
FIX
Update the innodb dictionary table with new path in the case there is
not a change in the table but the database holding the table as well.
Reviewed-by: Jimmy Yang<Jimmy.Yang@oracle.com>
RB: 15751
Revert the following change, because Memcached is not present
in MariaDB Server. We had better avoid adding dead code.
commit d9bc5e03d788b958ce8c76e157239953db60adb2
Author: Aakanksha Verma <aakanksha.verma@oracle.com>
Date: Thu May 18 14:31:01 2017 +0530
Bug #24605783 MYSQL GOT SIGNAL 6 ASSERTION FAILURE
This happens because on line 59 of /usr/bin/wsrep_sst_mysqldump
we have a check :
"if ! $MYSQL_CLIENT --version | grep 'Distrib 10.1' >/dev/null"
but the client is 10.2 so it doesnt match the grep expression.
Fixed check to be:
"if ! $MYSQL_CLIENT --version | grep 'Distrib 10.' >/dev/null"
so that every 10. version is accepted.
Disable change buffering, so that some data that was previously
written to the encrypted redo log will not end up being copied
to the unencrypted redo log due to change buffer merge.
The thd_destructor_proxy detects that no transactions are active and
starts srv_shutdown_bg_undo_sources(), but fails to take into account
that new transactions can still start, especially be slave but also
by other threads. In addition there is no mutex when checking for
active transaction so this is not safe.
We relax the failing InnoDB debug assertion by allowing the execution
of user transactions after the purge thread has been shut down.
FIXME: If innodb_fast_shutdown=0, we should somehow guarantee that no
new transactions can start after thd_destructor_proxy observed that
trx_sys_any_active_transactions() did not hold.
NET can only store current_thd if this NET (or its MYSQL) is not
moved between threads. In FederatedX MYSQL is part of the TABLE,
and a TABLE can migrate between threads.
Fix: associate NET with THD in txn->acquire() , and dissociate
in txn->release()
