| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test was changing wsrep_on option in node_3, which is native
MariaDB server (i.e. not a cluster node). Native NariaDB server
should not manipulate wsrep replication state, this problem is fixed.
galera.galera_slave_replay test phase 2 will cause certification failure
for async slave SQL handler thread. This certification failure is now
monitored and required to happen in the test.
The test phase 2, generates scenario, where async slave SQL handler faces
certification failure and galera slave applier is paused when this happens.
This makes the test vulnerable for anomaly described in MDEV-22632.
Therefore the fix in this commit depends on MDEV-22632, and should be merged
after the fix for MDEV-22632.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The parser must reject DDL operations on temporary objects when
they may modify or alter such object, including temporary tables and sequences.
The rejection is regardless (has been already in place for bin-loggable DML:s)
of the binlogging capability of the server or connection.
The patch implements the requirement. A binlog test is added.
|
| |
|
|
| |
Added a new test file for tests with delete using INNODB.
|
| |
|
|
|
|
|
|
|
| |
Backport this fix:
CLX-105: UPDATE query causes crash
LEX::print() should not crash when the UPDATE has no WHERE clause
Fixes CLX-373.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mtr_t::m_freed_pages: Renamed from m_freed_ranges and made it as
pointer indirection.
mtr_t::add_freed_offset(): Allocates m_freed_pages.
mtr_t:clear_freed_ranges(): Removed.
mtr_t::init(): Added debug assertion to check whether m_freed_pages
is not yet initialized.
btr_page_alloc_low(): Remove #ifdef UNIV_DEBUG_SCRUBBING.
mtr_t::commit(): Delete m_freed_pages, reset m_trim_pages and
m_freed_in_system_tablespace.
fil_space_t::clear_freed_ranges(): Added a comment to explain how
undo log tablespaces uses it.
|
| |
|
|
|
| |
A new state has been added to the wait condition,
which eliminates the error during the test.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit bf3c862faa8efed4a662725ec27586cd69e9228e
accidentally introduced two bugs.
btr_search_update_hash_ref(): Pass the correct parameter part->heap.
btr_search_sys_t::free(): Free all memory.
Thanks to Michael Widenius and Thirunarayanan Balathandayuthapani
for pointing out these bugs.
|
| |
|
|
|
|
|
|
|
| |
Second attempt to fix same bug:
Use the same queue for all READ operations.
Release queues for all used pages.
This fixes a hang in the s3.alter2 test case
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When converting a table (test.s3_table) from S3 to another engine, the
following will be logged to the binary log:
DROP TABLE IF EXISTS test.t1;
CREATE OR REPLACE TABLE test.t1 (...) ENGINE=new_engine
INSERT rows to test.t1 in binary-row-log-format
The bug is that the above statements are logged one by one to the binary
log. This means that a fast slave, configured to use the same S3 storage
as the master, would be able to execute the DROP and CREATE from the
binary log before the master has finished the ALTER TABLE.
In this case the slave would ignore the DROP (as it's on a S3 table) but
it will stop on CREATE of the local tale, as the table is still exists in
S3. The REPLACE part will be ignored by the slave as it can't touch the
S3 table.
The fix is to ensure that all the above statements is written to binary
log AFTER the table has been deleted from S3.
|
| | |
|
| |
|
|
| |
- Added missing test for binlog_filter to ALTER TABLE
|
| |
|
|
|
|
|
|
| |
- Rewrote bool Query_compressed_log_event::write() to make it more readable
(no logic changes).
- Changed DBUG_PRINT of 'is_error:' to 'is_error():' to make it easier to
find error: in traces.
- Ensure that 'db' is never null in Query_log_event (Simplified code).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rw_lock_s_lock() calls for the buf_pool.page_hash became a
clear bottleneck after MDEV-15053 reduced the contention on
buf_pool.mutex. We will replace that use of rw_lock_t with a
special implementation that is optimized for memory bus traffic.
The hash_table_locks instrumentation will be removed.
buf_pool_t::page_hash: Use a special implementation whose API is
compatible with hash_table_t, and store the custom rw-locks
directly in buf_pool.page_hash.array, intentionally sharing
cache lines with the hash table pointers.
rw_lock: A low-level rw-lock implementation based on std::atomic<uint32_t>
where read_trylock() becomes a simple fetch_add(1).
buf_pool_t::page_hash_latch: The special of rw_lock for the page_hash.
buf_pool_t::page_hash_latch::read_lock(): Assert that buf_pool.mutex
is not being held by the caller.
buf_pool_t::page_hash_latch::write_lock() may be called while not holding
buf_pool.mutex. buf_pool_t::watch_set() is such a caller.
buf_pool_t::page_hash_latch::read_lock_wait(),
page_hash_latch::write_lock_wait(): The spin loops.
These will obey the global parameters innodb_sync_spin_loops and
innodb_sync_spin_wait_delay.
buf_pool_t::freed_page_hash: A singly linked list of copies of
buf_pool.page_hash that ever existed. The fact that we never
free any buf_pool.page_hash.array guarantees that all
page_hash_latch that ever existed will remain valid until shutdown.
buf_pool_t::resize_hash(): Replaces buf_pool_resize_hash().
Prepend a shallow copy of the old page_hash to freed_page_hash.
buf_pool_t::page_hash_table::n_cells: Declare as Atomic_relaxed.
buf_pool_t::page_hash_table::lock(): Explain what prevents a
race condition with buf_pool_t::resize_hash().
|
| |
|
|
|
|
|
|
|
|
|
|
| |
hash_get_n_cells(): Remove. Access n_cells directly.
hash_get_nth_cell(): Remove. Access array directly.
hash_table_clear(): Replaced with hash_table_t::clear().
hash_table_create(), hash_table_free(): Remove.
hash0hash.cc: Remove.
|
| |
|
|
|
|
|
|
|
|
|
| |
btr_search_sys::parts[]: A single structure for the partitions of
the adaptive hash index. Replaces the 3 separate arrays:
btr_search_latches[], btr_search_sys->hash_tables,
btr_search_sys->hash_tables[i]->heap.
hash_table_t::heap, hash_table_t::adaptive: Remove.
ha0ha.cc: Remove. Move all code to btr0sea.cc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HASH_TABLE_SYNC_MUTEX was kind-of used for the adaptive hash index,
even though that hash table is already protected by btr_search_latches[].
HASH_TABLE_SYNC_RWLOCK was only being used for buf_pool.page_hash.
It is cleaner to decouple that synchronization from hash_table_t,
and move it to the actual user.
buf_pool_t::page_hash_latches[]: Synchronization for buf_pool.page_hash.
LATCH_ID_HASH_TABLE_MUTEX: Remove.
hash_table_t::sync_obj, hash_table_t::n_sync_obj: Remove.
hash_table_t::type, hash_table_sync_t: Remove.
HASH_ASSERT_OWN(), hash_get_mutex(), hash_get_nth_mutex(): Remove.
ib_recreate(): Merge to the only caller, buf_pool_resize_hash().
ib_create(): Merge to the callers.
ha_clear(): Merge to the only caller buf_pool_t::close().
buf_pool_t::create(): Merge the ib_create() and
hash_create_sync_obj() invocations.
ha_insert_for_fold_func(): Clarify an assertion.
buf_pool_t::page_hash_lock(): Simplify the logic.
hash_assert_can_search(), hash_assert_can_modify(): Remove.
These predicates were only being invoked for the adaptive hash index,
while they only are effective for buf_pool.page_hash.
HASH_DELETE_AND_COMPACT(): Merge to ha_delete_hash_node().
hash_get_sync_obj_index(): Remove.
hash_table_t::heaps[], hash_get_nth_heap(): Remove. It was actually unused!
hash_get_heap(): Remove. It was only used in ha_delete_hash_node(),
where we always use hash_table_t::heap.
hash_table_t::calc_hash(): Replaces hash_calc_hash().
|
| |
|
|
|
|
|
|
| |
MRI scripts cannot handle + in paths, and ubuntu CI makes use of
these.
So we remove the top level build dir from the script and
transform it into a relative path script.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of common dependencies between the
static libraries list can contain duplicates.
We reduce these down to the single last one in
the list.
This reduces the relative time of a rebuild from:
$ (cd builddir/; time make -j)
...
real 0m30.789s
user 1m33.477s
sys 0m19.678s
and the LIB entries
$ grep ADDLIB builddir/libmysqld/mysqlserver-\$\<CONFIG\>.mri.tpl | wc -l
179
$ du -h builddir/libmysqld/libmariadbd.a
4.1G builddir/libmysqld/libmariadbd.a
To:
$ (cd builddir/; time make -j)
...
real 0m20.139s
user 1m32.423s
sys 0m12.208s
$ grep ADDLIB builddir/libmysqld/mysqlserver-\$\<CONFIG\>.mri.tpl | wc -l
25
$ du -h builddir/libmysqld/libmariadbd.a
688M builddir/libmysqld/libmariadbd.a
|
| |\ |
|
| | |
| |
| |
| | |
from configuration files
|
| | |
| |
| |
| |
| | |
Post-push fix: add mysqd options in backup string in mariabackup sst
script for the case of logging not in syslog.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The test mariabackup.mdev-14447 started failing due to the option
--apply-log-only that became invalid since
commit 9bdf35e90f36d9be8cc7591e2ed5e62feadc5515
and had been removed in
commit 8c71c6aa8b9f4c78cfa164fad1d324ba0cf9b888.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
btr_pcur_store_position
- There is a possiblity that metadata record is the only record in
the leftmost leaf page. So change the assertion to check only
previous page.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
plugin are enabled
Make sure to initialize SSL early enough, when encryption plugins is loaded
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
increased scalability through even distribution
Rollback segments are allocated to transactions in round-robin fashion.
This is controlled by incrementing a static-scope counter named rseg_slot.
Said logic is not protected by any mutex or use of atomic for the counter.
This potentially can cause the same rollback segment to get allocated to
N different transactions (requesting allocation at the same time).
While this is not an issue as a rollback segment can host multiple
transactions from contention (performance) perspective it is better to
allocate these rollback segments in round-robin fashion.
Fix for the said issue ports use of atomic for the said counter that would
ensure the original design semantic (even distribution through round-robin)
is retained.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
/data/src/10.4-bug/sql/rpl_parallel.cc, line 470 upon shutdown during FTWRL
Problem:- When we issue FTWRL with shutdown in parallel, there is race between
FTWRL and shutdown. Shutdown might destroy the mutex (pool->LOCK_rpl_thread_pool)
before FTWRL can lock it. So we can get crash on FTWRL thread
Solution:- mysql_mutex_destroy(pool->LOCK_rpl_thread_pool) should wait for
FTWRL thread to complete its work , and then destroy.
So slave_prepare_for_shutdown will just deactivate the pool, and mutex is destroyed
later in end_slave()
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The galera.galera_parallel_autoinc_manytrx mtr test opens and runs test
scenario through 3 connections to node 1 and one connection to node 2.
In the test initialization phase, the test creates two tables 't1' and 'ten'
and then creates a stored procedure 'p1' to operate on these tables.
These 3 create DDL statements are issued through same connection to node 1.
In the next test phase, the mtr script uses send command to launch the call
for the p1 stored procedure through all 3 connections to node 1 and through
one connection to node 2. As the mtr send command is asynchronous,
this test phase is non blocking and fast operation.
Now, if the replication between nodes is slow, it may happen that the
initialization phase DDL statements have not been received or have not been
fully applied in node 2. Therefore there is no guarantee that the test tables
and the stored procedure have been created in node 2. Yet, the test is trying
to call p1 in node 2.
In the failure case error logs, there is error message
"MTR failed: query 'reap' failed: 1305: PROCEDURE test.p1 does not exist"
The reap command through connection to node 2, is the first place where test
execution may observe that test tables and/or stored procedure are not yet
created in node 2.
The fix in this commit adds a wait condition in connection to node 2, to wait
until the stored procedure is created before calling the stored procedure.
The wait is implemented by looking in information_schema.routines for the p1
stored procedure.
|
| | |
| |
| |
| | |
galera_ipv6_mariabackup MTR tests
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MDEV-21298: mariabackup doesn't read from the [mariadbd] and [mariadbd-X.Y]
server option groups from configuration files
MDEV-21301: mariabackup doesn't read [mariadb-backup] option group in
configuration file
All three issues require to change the same code, that is why their
fixes are joined in one commit.
The fix is in invoking load_defaults_or_exit() and handle_options() for
backup-specific groups separately from client-server groups to let the last
handle_options() call fail on unknown backup-specific options.
The order of options procesing is the following:
1) Load server groups and process server options, ignore unknown
options
2) Load client groups and process client options, ignore unknown
options
3) Load backup groups and process client-server options, exit on
unknown option
4) Process --mysqld-args command line options, ignore unknown options
New global flag my_handle_options_init_variables was added to have
ability to invoke handle_options() for the same allowed options set
several times without re-initialising previously set option values.
--password value destroying is moved from option processing callback to
mariabackup's handle_options() function to have ability to invoke server's
handle_options() several times for the same possible allowed options
set.
Galera invokes wsrep_sst_mariabackup.sh with mysqld command line
options to configure mariabackup as close to the server as possible.
It is not known what server options are supported by mariabackup when the
script is invoked. That is why new mariabackup option "--mysqld-args" is added,
all unknown options that follow this option will be silently ignored.
wsrep_sst_mariabackup.sh was also changed to:
- use "--mysqld-args" mariabackup option to pass mysqld options,
- remove deprecated innobackupex mode,
- remove unsupported mariabackup options:
--encrypt
--encrypt-key
--rebuild-indexes
--rebuild-threads
|
| | |\ |
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The test case that was added for MDEV-21217
(commit b68f1d847f1fc00eed795e20162effc8fbc4119b)
should have only two possible outcomes for the locking SELECT statement:
(1) The statement is blocked, and the test will eventually fail
with a lock wait timeout. This is what I observed when the
code fix for MDEV-21217 was missing.
(2) The lock conflict will ensure that the statement will execute
after the rollback has completed, and an empty table will be observed.
This is the expected outcome with the recovery fix.
What occasionally happens (in some of our CI environments only, so far)
is that the locking SELECT will return all 1,000 rows of the table that
had been inserted by the transaction that was never supposed to be
committed. One possibility is that the transaction was unexpectedly
committed when the server was killed.
Let us disable the test until the reason of the failure has been
determined and addressed.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
and put them all together in mysqld.cc
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
(if this option is present). perf, and other tools that do stack walking
works much better with it.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- This is a regression of MDEV-21174(56f6dab1d0e5a464ea49c1e5efb0032a0f5cea3e).
InnoDB resets the BTR_EXTERN_LEN value at wrong offset.
|
| | | | |
| | | |
| | | |
| | | | |
galera_ipv6_mariabackup MTR tests
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The galera.galera_parallel_autoinc_manytrx mtr test opens and runs test
scenario through 3 connections to node 1 and one connection to node 2.
In the test initialization phase, the test creates two tables 't1' and 'ten'
and then creates a stored procedure 'p1' to operate on these tables.
These 3 create DDL statements are issued through same connection to node 1.
In the next test phase, the mtr script uses send command to launch the call
for the p1 stored procedure through all 3 connections to node 1 and through
one connection to node 2. As the mtr send command is asynchronous,
this test phase is non blocking and fast operation.
Now, if the replication between nodes is slow, it may happen that the
initialization phase DDL statements have not been received or have not been
fully applied in node 2. Therefore there is no guarantee that the test tables
and the stored procedure have been created in node 2. Yet, the test is trying
to call p1 in node 2.
In the failure case error logs, there is error message
"MTR failed: query 'reap' failed: 1305: PROCEDURE test.p1 does not exist"
The reap command through connection to node 2, is the first place where test
execution may observe that test tables and/or stored procedure are not yet
created in node 2.
The fix in this commit adds a wait condition in connection to node 2, to wait
until the stored procedure is created before calling the stored procedure.
The wait is implemented by looking in information_schema.routines for the p1
stored procedure.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
drop database `fts`.`` though there are still open handles
MDEV-22140 galera.galera_drop_database MTR failed: InnoDB: MySQL is trying to drop database `fts`.`` though there are still open handles
Add wait conditions to wait that all operations are done in both
nodes.
|
| | | | | |
|
