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`.
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.
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.
Following merge from 5.6.36, this merge also rejects changes that
collided with the rejection of 6ca4f693c1ce472e2b1bf7392607c2d1124b4293.
We initially rejected 6ca4f693c1ce472e2b1bf7392607c2d1124b4293 because
it was introducing a new storage engine API method.
