Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Categories: connectors experimental galera main
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

connectors experimental galera main
f03e96f7eb6b...
f03e96f7eb6b01041836299c78664827a51ce150
Andrei Elkin
MDEV-38212 MDEV-37686 Breaks Parallel Replication

Re-fixing MDEV-37686.

NULLifying `THD::rgi_slave` pointer in `start_new_trans` ctor harmed
the parallel slave conflict detection.
Now instead of `NULL`ifying of this member a finer approach is taken to
optionally screen `THD::rgi_slave` when it is attempted to be accessed
within `start_new_trans` context, that is when such out-of-band
transaction is run by a slave thread.

The start_new_trans is allowed of course to access server local
non-replicated temporary tables, should it ever need that.

The original MDEV-37686 aspect is tested with 12.3 branch's
rpl.create_or_replace_mix2.
Any possible side effects to temporary table replication is controlled
by existing rpl suite tests.
There is no need for a specific mtr test to prove the parallel slave
side is back to normal, as `THD::rgi_slave` is again available to concurrent
transactions.
dd065fbfeccb...
dd065fbfeccbc8e88a9d94d4058d956600657296
Kristian Nielsen
Binlog-in-engine: More robust binlog recovery

If binlog files are deleted or otherwise unreadable during server restart,
don't make the server unstartable. Instead, start up, recovering what is
available, but complaining in the error log.

Signed-off-by: Kristian Nielsen <[email protected]>
dcf59cc2480d...
dcf59cc2480dbb1920874fa32bd967e8527f4315
Raghunandan Bhat
MDEV-37484: `Sql_cmd_dml::execute_inner`, `Sql_cmd_update::execute_inner` do not call Select handler for the engine involved

Problem:
  After the re-design of `UPDATE` and `DELETE` in MDEV-28883, the call
  to find select handler is missing. This prevents the server from
  handring over multi-update/multi-delete queries to storage engines
  capable of executng such queries on their own (e.g., ColumnStore).

  MDEV-32382 introduced a check in `find_select_handler_inner` function,
  that blocked pushdown of queries involving CTEs, without checking if
  the storage engine is capable of handling such queries.

Fix:
  Add a call to find the select handler for the engine involved in the
  multi-update/multi-delete query, allowing the storage engines to
  execute such queries.

  Fix the `find_select_handler_inner` function by allowing the storage
  engine's create_select functions to decide the pushdown of queries
  involving CTEs.
d75dbb766663...
d75dbb766663f54d86af76356af8dc57b5c71b40
Kristian Nielsen
Binlog-in-engine: Clean up few remaining todos, error handling

Signed-off-by: Kristian Nielsen <[email protected]>
ccc0662a6ac5...
ccc0662a6ac5edb72821f784a5a7aa6d5d300c12
bsrikanth-mariadb
MDEV-36523: Load basic stats from trace into optimizer

This task loads the stats of the tables that are used in a query,
from the trace into the optimizer. This feature is also controlled
by optimizer_record_context, and is not enabled by default.
The stats such as num_of_records present in the table, indexes if present,
their names, along with the average number of records_per_key
with in each index are loaded from the trace.
Additionally, stats from range analysis i.e. ranges, and the
corresponding number of records are also loaded from the trace.

The trace context which is in JSON format is firstly set into the
session variable optimizer_trace_stored_context.
Later, when a user issues a query, the contents of this variable is
parsed and an in memory representation is built using the class
Optimizer_context_replay. This class is then used by the optimizer
to update and save original values of the tables, indexes, and range stats
in the methods "set_statistics_for_table()" of sql_statistics.cc, and
"check_quick_select()" of opt_range.cc.
After the query gets finished, the statistics that were updated
in the optimizer are restored back to the saved original values.

The entry point for parsing the json structure is in
"mysql_execute_command()" of sql_parse.cc, and similarly exit point
i.e. to restore the saved stats of the optimizer is at the end
of the same method.

Two new warning/error messages are introduced:
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_PARSE_FAILED, and
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_MATCH_FAILED
c4264c9e2f6f...
c4264c9e2f6fd9aabc3ed8e6b069c95367eeb060
Denis Protivensky
MDEV-34124: Make sequences work with streaming replication

- extend galera_sequences_transaction test with streaming replication
combinations (it demonstrates the exact results compared to the regular
Wsrep replication)
- remove MDEV-28971 test as it's not applicable after fixing the binlog
statement cache replication with Wsrep
c331d530b726...
c331d530b726366571a2b63017dda911892ef2b6
Marko Mäkelä
Merge 10.6 into 10.11
bdb12452d375...
bdb12452d375002bc55d6364f8800baed13bbded
Kristian Nielsen
Binlog-in-engine: More robust binlog recovery

If binlog files are deleted or otherwise unreadable during server restart,
don't make the server unstartable. Instead, start up, recovering what is
available, but complaining in the error log.

Signed-off-by: Kristian Nielsen <[email protected]>
adf9f56041ff...
adf9f56041ffa9943a03b966a6d9886ecc8b6095
Denis Protivensky
MDEV-34124: Test sequences recovery after crash in Galera cluster
ab5e7c94cbda...
ab5e7c94cbda469f0ba30cf85b9b7113d20bbe50
Kristian Nielsen
Binlog-in-engine: Fix incorrect GTID position at slave connect

The GTID position at slave connect is found from the GTID state records
written at the start and at every --innodb-binlog-state-interval bytes of
the binlog files. There was a bug that for a binlog group commit, the binlog
state written was the one corresponding to the last GTID in the group,
regardless of where during the binlogging of the group it was written. Thus,
it could mistakenly write a GTID state record of 0-1-10, say, followed by a
lower GTID 0-1-9. This could cause a slave connecting at 0-1-10 to receive
an extra GTID 0-1-9, and replication would diverge.

Fix by maintaining a full GTID binlog state inside the engine binlog, same
as is done for the differential state.

Signed-off-by: Kristian Nielsen <[email protected]>
a7528a619080...
a7528a6190807281d3224e4e67a9b76083a202a6
Marko Mäkelä
Merge 11.4 into 11.8
a61a746f08d3...
a61a746f08d3378cb4e5a3ea4452dc867a164b7f
Vladislav Vaintroub
MDEV-38029 my_tzinfo-t fails for certain TZ values on musl

The test fails for TZ values such as `PST8PDT` (present but outdated in
tzdb) and custom forms like `GST-1GDT`. On musl, these values do not
trigger the expected DST transitions, leading to incorrect DST offsets
or abbreviations.

This appears to be a musl libc bug; the same TZ values behave correctly
elsewhere, including Windows. We work around it by skipping the
affected tests when musl is detected.
a117be125591...
a117be125591b35212dfcae01c056e91f3527268
bsrikanth-mariadb
MDEV-36523: Load basic stats from trace into optimizer

This task loads the stats of the tables that are used in a query,
from the trace into the optimizer. This feature is also controlled
by optimizer_record_context, and is not enabled by default.
The stats such as num_of_records present in the table, indexes if present,
their names, along with the average number of records_per_key
with in each index are loaded from the trace.
Additionally, stats from range analysis i.e. ranges, and the
corresponding number of records are also loaded from the trace.

The trace context which is in JSON format is firstly set into the
session variable optimizer_trace_stored_context.
Later, when a user issues a query, the contents of this variable is
parsed and an in memory representation is built using the class
Optimizer_context_replay. This class is then used by the optimizer
to update and save original values of the tables, indexes, and range stats
in the methods "set_statistics_for_table()" of sql_statistics.cc, and
"check_quick_select()" of opt_range.cc.
After the query gets finished, the statistics that were updated
in the optimizer are restored back to the saved original values.

The entry point for parsing the json structure is in
"mysql_execute_command()" of sql_parse.cc, and similarly exit point
i.e. to restore the saved stats of the optimizer is at the end
of the same method.

Two new warning/error messages are introduced:
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_PARSE_FAILED, and
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_MATCH_FAILED
9c6017474f98...
9c6017474f988b926dfc562da3fa7113a7e5a36f
Vlad Lesin
MDEV-36845 InnoDB: Failing assertion: tail.trx_no <= last_trx_no

The scenario of the bug is the following. Before killing the server some
transaction A starts undo log writing in some undo segment U of rseg R.
It writes its trx_id into the undo log header. Then new trx_id is assigned
to transaction B, but undo log hasn't been started yet. Then transaction
A commits and writes trx_no into its undo log header. Transaction B
starts writing undo log into the undo segment U. So we have the
following undo logs in the undo segments U:

... undo log 1...
... undo log 2...
      ...
undo log A, trx_id: L, trx_no: M, ...
undo log B, trx_id: N, trx_no: 0, ...

Where L < N < M.

Then server is killed.

On recovery the maximum trx_no is extracted from each rseg, and the
maximum trx_no among all rsegs plus one is considered as a new value
for server-wide transaction id/no counter.

For each undo segment of each rseg we read the last undo log header. If
the last undo log is committed, then we read trx_no from the header,
otherwise we treat trx_id as trx_no. The maximum trx_no from all undo
log segments of the current rseg is treated as the maximum trx_no of the
rseg.

For the above case the undo log of transaction B is not committed and
its trx_no is 0. So we read trx_id and treat it as trx_no. But M < N. If
U is the last modified undo segment in rseg R, and trx_(id/no) N is the
maximum trx_no among all rsegs, then there can be the case when after
recovery some transaction with trx_no_C, such as N < trx_no_C <= M, is
committed.

During a purging we store trx_no of the last parsed undo log of a
committed transaction in purge_sys.tail.trx_no. So if the last parsed
undo log is the undo log of transaction A(transaction B was rolled back
on recovery and its undo log was also removed from the undo segment U),
then purse_sys.tail.trx_no = M. Than if some other transaction C with
trx_no_C <= M is being committed and purged, we hit
"tail.trx_no <= last_trx_no" assertion failure in
purge_sys_t::choose_next_log(), because purge queue is min-heap of
(trx_no, trx_sys.rseg_array index) pairs, where the key is trx_no, and it
must not be that trx_no of the last parsed undo log of a committed
transaction is greater than the last trx_no of the rseg at the top of
the queue.

The fix is to read the trx_no of the previous to last undo log in undo
segment, if the last undo log in that undo segment is not committed, and
set trx_no=max(trx_id of the last undo log, trx_no of the previous to
last undo log) during recovery.

We can do this because we need to extract the maximum
value of trx_no or trx_id of the undo log segment, and the maximum value
is either trx_id of the last undo log or trx_no of the previous to
last undo log, because undo segment can be assigned only to the one
transaction at time, and undo logs in the undo segment are ordered by
trx_id.

Reviewed by Marko Mäkelä.
94460661d6c4...
94460661d6c4f6e15153d1f903d504940a03d023
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Load system triggers from within a transaction
8e7d42c03b98...
8e7d42c03b9871d130717768b8f93485c3b472fb
Marko Mäkelä
Merge 10.11 into 11.4
8020741dbc78...
8020741dbc78601b0c268e0fd288662d4c31aad4
Kristian Nielsen
Binlog-in-engine: More robust binlog recovery

If binlog files are deleted or otherwise unreadable during server restart,
don't make the server unstartable. Instead, start up, recovering what is
available, but complaining in the error log.

Signed-off-by: Kristian Nielsen <[email protected]>
7dde3ad18b0a...
7dde3ad18b0aefd86d3cdc18aa2d7c39acfaaf70
Andrei Elkin
MDEV-38212 MDEV-37686 Breaks Parallel Replication

Re-fixing MDEV-37686.

NULLifying `THD::rgi_slave` pointer in `start_new_trans` ctor harmed
the parallel slave conflict detection.
Now instead of `NULL`ifying of this member a finer approach is taken to
optionally screen `THD::rgi_slave` when it is attempted to be accessed
within `start_new_trans` context, that is when such out-of-band
transaction is run by a slave thread.

The start_new_trans is allowed of course to access server local
non-replicated temporary tables, should it ever need that.

The original MDEV-37686 aspect is tested with 12.3 branch's
rpl.create_or_replace_mix2.
Any possible side effects to temporary table replication is controlled
by existing rpl suite tests.
There is no need for a specific mtr test to prove the parallel slave
side is back to normal, as `THD::rgi_slave` is again available to concurrent
transactions.
7a1ad32118a1...
7a1ad32118a13d35c5f57d09872a622a548e7916
Jan Lindström
MDEV-37986 : Test failure on galera.galera_provider_options_long

Test configuration fixes only. Test failed because SSL-configuration
was incorrect and was missing ssl_ca parameter. Fixed by adding
correct SSL-configuration.
79926f1c090e...
79926f1c090e6e5e45b457814ab77e2bc4b94352
Jan Lindström
MDEV-36528 : Test failure on galera.mdev-22543

Test case changes only. Replace sleep with wait_condition
that makes sure that node_1 is still Donor after
node_2 has requested SST and is actually stuck on
debug sync wait.
746269d61439...
746269d614393d41ac0a34e5c77d63d81a9a53a7
Sergei Golubchik
fix main.mysqld_option_err test that didn't work for years

the "Test that bad value for plugin enum option is rejected correctly"
needed multiple fixes:

1. don't set plugin-dir based on $MYSQLTEST_VARDIR, all plugins are
  in var/plugins, but $MYSQLTEST_VARDIR is var/1/, var/2/, etc if
  --parallel is used (that is, practically always), thus the ha_example.so
  cannot be loaded, because cannot be found. Test fails with
  "unknown option --plugin-example-enum" as the plugin is not loaded.

2. force --plugin-maturity=experimental, otherwise even if not parallel
  the plugin will fail to load because of low maturity, test still
  fails with "unknown option --plugin-example-enum"

3. set --plugin-example=FORCE otherwise plugin fails to load after reading
  --plugin-example-enum-var=noexist because of unknown enum value,
  the server ignores the failure and starts normally. the test hangs.

4. This needs the fix in sql_plugin.cc to detect that the plugin is
  forced even if some options failed to parse. It used to consider
  plugin forced only if all options parsed correctly, which was wrong.

Now the test passes, testing what it was supposed to test - failure
to parse an enum value of a plugin option.

Without these fixes the test hanged as in 2 when run on the main branch
in non-prarallel (e.g. one test only) mode.
6944e2be6d79...
6944e2be6d79d53fe52a613e5b7bf8eaf00554ce
Monty
Add mariadb-plugin-columnstore.install.generated to .gitignore
6737d68a8e74...
6737d68a8e7440f1b71e347a73f5e7446fb0ba9b
Monty
MDEV-32266 All queries in stored procedures increment empty_queries counter

Fixed by setting server_status SERVER_STATUS_RETURNED_ROW if send_data
is called for stored procedures.

This make the definition of Empty_queries well defined:
"Empty_queries" is the number of SELECT queries that returns 0 rows.
5e6903769ffc...
5e6903769ffc2fd0456f43169b6d294c9bfe1de5
Daniel Black
MDEV-38137 s3.cnf still suggests changing plugin-maturity to alpha

S3 became stable in a49f5525bbe1. Adjust the configuration file
not to require a low plugin-maturity setting.

Thanks Mike Griffin for the bug report.
5b0c2ed25994...
5b0c2ed259943968e0240b94b03474e1d2b29fd4
Sergey Vojtovich
MDEV-13257 - main.kill-2 failed in buildbot

Test output was affected by incompletely closed preceding connections.

Make test agnostic to concurrent connections by querying
information_schema.processlist only for connections that it uses.

Avoid querying for i_s.processlist db column. It is unstable due to
trylock_short(), can be "" if concurrent connection is holding
LOCK_thd_data.
5b05829739fe...
5b05829739fe4e4794dd01e6ff827984e7cc32c6
Thirunarayanan Balathandayuthapani
MDEV-38041: MariaBackup fails during rollback of inplace FTS alter table

Problem:
========
When an inplace ALTER operation is rolled back, InnoDB drops
intermediate tables and their associated FTS internal tables.
However, MariaBackup's DDL tracking can incorrectly report
this as a backup failure.

The issue occurs because backup_set_alter_copy_lock() downgrades the
MDL_BACKUP_DDL lock before the inplace phase of ALTER,
allowing FTS internal tables to be dropped during the
later phases of backup when DDL tracking is still active.

Solution:
========
backup_file_op_fail(): Ignore delete operations on FTS internal
tables when not using --no-lock option, preventing false
positive backup failures.
449e1c6df378...
449e1c6df3786cd7e88299f68230fe5478e2ff0d
Kristian Nielsen
Binlog-in-engine: Small cleanup/formatting

Signed-off-by: Kristian Nielsen <[email protected]>
442a7f1e731f...
442a7f1e731f51235331f664070dd06b1b07a44e
Monty
MDEV-38130 Add Option File Syntax '?' to ignore unreadable directories

This is useful if one has MariaDB config files in /etc that should only be
visible for the super user and the MariaDB server but one still want to
provide options for normal users, like skip-ssl.
3de6d11321ff...
3de6d11321ff371f26d39ed87d611f0eda2671ab
Denis Protivensky
MDEV-34124: Improve sequences replication with Galera

- use shared key for sequence update certification
- employ native replication's code to apply changes for sequences
which handles all corner cases properly
- fix the tests to allow more transactions using sequences to be
accepted

That way the sequence is always updated to the maximum value
independent of the order of updates, and shared certification keys
allow to improve acceptance ratio of concurrent transactions that
use sequences. It's reflected in the test changes.
3491732e749d...
3491732e749d390a39d88f1fd34f7790a0b57818
bsrikanth-mariadb
MDEV-36523: Load basic stats from trace into optimizer

This task loads the stats of the tables that are used in a query,
from the trace into the optimizer. This feature is also controlled
by optimizer_record_context, and is not enabled by default.
The stats such as num_of_records present in the table, indexes if present,
their names, along with the average number of records_per_key
with in each index are loaded from the trace.
Additionally, stats from range analysis i.e. ranges, and the
corresponding number of records are also loaded from the trace.

The trace context which is in JSON format is firstly set into the
session variable optimizer_trace_stored_context.
Later, when a user issues a query, the contents of this variable is
parsed and an in memory representation is built using the class
Optimizer_context_replay. This class is then used by the optimizer
to update and save original values of the tables, indexes, and range stats
in the methods "set_statistics_for_table()" of sql_statistics.cc, and
"check_quick_select()" of opt_range.cc.
After the query gets finished, the statistics that were updated
in the optimizer are restored back to the saved original values.

The entry point for parsing the json structure is in
"mysql_execute_command()" of sql_parse.cc, and similarly exit point
i.e. to restore the saved stats of the optimizer is at the end
of the same method.

Two new warning/error messages are introduced:
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_PARSE_FAILED, and
ER_JSON_OPTIMIZER_REPLAY_CONTEXT_MATCH_FAILED
3167868847e3...
3167868847e3007665ab216292460fc402dbf497
Kristian Nielsen
Binlog-in-engine: Fix incorrect GTID position at slave connect

The GTID position at slave connect is found from the GTID state records
written at the start and at every --innodb-binlog-state-interval bytes of
the binlog files. There was a bug that for a binlog group commit, the binlog
state written was the one corresponding to the last GTID in the group,
regardless of where during the binlogging of the group it was written. Thus,
it could mistakenly write a GTID state record of 0-1-10, say, followed by a
lower GTID 0-1-9. This could cause a slave connecting at 0-1-10 to receive
an extra GTID 0-1-9, and replication would diverge.

Fix by maintaining a full GTID binlog state inside the engine binlog, same
as is done for the differential state.

Signed-off-by: Kristian Nielsen <[email protected]>
2fd25d77f031...
2fd25d77f031f48f501344b5d77aeea62b42da88
Andrei Elkin
MDEV-37541 Race of rolling back and committing transaction to binlog

Two transactions could binlog their completions in opposite to how it
is done in Engine. That is is rare situations ROLLBACK in Engine of
the dependency parent transaction could be scheduled by the
transaction before its binlogging. That give a follower dependency
child one get binlogged ahead of the parent.

For fixing this bug its necessary to ensure the binlogging phase is
always first one in the internal one-phase rollback protocol.

The commit makes sure the binlog handlerton always rollbacks as first
handlerton in no-2pc cases.

An added test demonstrates how the child could otherwise reach binlog
before its parent.
1e89dd450835...
1e89dd4508350fdbc483de4fafcf34f21e871e92
Dmitry Shulga
MDEV-30645: CREATE TRIGGER FOR { STARTUP | SHUTDOWN }

Fixed memory leaks
1893fb4d2bba...
1893fb4d2bbae86300b3ebfbbc08c1774c1abe59
Jan Lindström
MDEV-38201 : Assertion `level != Sql_condition::WARN_LEVEL_ERROR' failed in void push_warning(THD*, Sql_state_errno_level::enum_warning_level, uint, const char*)

Problem was that wrong level of Sql_condition was used on
push_warning_printf and error handling of REFRESH_HOSTS
(and similar) was broken.

Fixed warning printing in wsrep_TOI_begin after enter_toi_local
is called. Fixed also error handling after REFRESH_HOSTS (and others)
if TOI begin failed.
15283527a5df...
15283527a5dfb1ceb56ce858530b0b3c137399ca
Jan Lindström
Galera library 26.4.25 contains gcs protocol change 5-->6
1323b762b209...
1323b762b2092bdd485f0f74692fa37fc7e04bd8
Marko Mäkelä
MDEV-33966: buf_page_make_young() is a contention point

The buf_pool.LRU list needs to reasonably accurately reflect recently
accessed blocks, so that they will not be evicted prematurely.
Because the list is protected by buf_pool.mutex, it is not a good idea
to maintain the position on every page access.

Instead of maintaining the LRU position on each access, we will
set a "recently accessed" flag in the block descriptor. The
buf_flush_page_cleaner() thread as well as some traversal of the
buf_pool.LRU list will test and reset this flag on each visited
block. If the flag was set, the position in the buf_pool.LRU list
may be adjusted.

buf_pool_t::freed_page_clock, buf_page_t::freed_page_clock: Remove.
This is no longer meaningful in the revised design.

page_zip_des_t::state: An atomic 16-bit field that will include
the "accessed" and "old" flags that would more logically belong
to buf_page_t. We maintain them here (along with some
ROW_FORMAT=COMPRESSED specific state that is protected by page
latches) in order to avoid race conditions and unnecessary
memory overhead.

buf_block_t::init(): Replaces buf_block_init().

buf_page_t::invalidate(): Replaces buf_block_modify_clock_inc().
Instead of maintaining a 64-bit counter, we will maintain one
comprising 32+16=48 bits, in modify_clock_low,modify_clock_high.
Worst case there will be exactly n<<48 calls to
buf_page_t::invalidate() before some operation such as
btr_pcur_t::restore_position() is executed. Such a count should
be extremely unlikely but not completely impossible. It is worth
noting that the DB_TRX_ID is only 48 bits, and each transaction
start and commit/rollback will consume an identifier.

buf_page_t::modify_clock(): Replaces the read access of
buf_page_t::modify_clock. Assert that the caller is holding
a page latch. Note: because invalidate() and modify_clock() are
protected with buf_pool.mutex or the buf_page_t::lock, there can
be no issue with regard to the atomicity of accessing the 48-bit field.

buf_page_t::access_time: Store uint16_t(time(nullptr)). Yes, it will
wrap around every 18.2 hours, and in the worst case, a rather recently
accessed block may end up being evicted as "least recently used".
But in this way we will avoid any alignment loss: the adjacent fields
modify_clock_low, modify_clock_high, access_time of 32+16+16 bits
will nicely add up to 64 bits.

buf_page_t::make_young(): Clear the "recently accessed" flag of a block
and move the block to the "not recently used" end of buf_pool.LRU
if it qualifies for that. When we make a block young, we zero out
access_time so that the comparison is more likely to hold on a
subsequent invocation, or so that flag_accessed() will update the
current access time, which due to wrap-around could look like less
than the previously assigned access_time.

buf_LRU_scan_and_free_block(): Declare static.

buf_pool_invalidate(): Define in the same compilation unit with
buf_LRU_scan_and_free_block().

buf_pool.LRU_old_time_threshold: Replaces buf_LRU_old_threshold_ms.

PageConverter::run(): Renamed from fil_iterate(). In debug builds,
acquire a dummy exclusive latch on the block, so that the assertion
in buf_block_t::modify() will be satisfied.

ut_time_ms(): Remove. Invoking my_hrtime_coarse() is sufficient for the
remaining purposes.
0f5e5ced376f...
0f5e5ced376f8904cb3822525b60feba9f5f9105
Brandon Nesterenko
MDEV-37662: Binlog Corruption When tmpdir is Full

The binary log could be corrupted when committing a large transaction
(i.e. one whose data exceeds the binlog_cache_size limit and spills
into a tmp file) in binlog_format=row if the server's --tmp-dir is
full. The corruption that happens is only the GTID of the errored
transaction would be written into the binary log, without any
body/finalizing events.  This would happen because the content of the
transaction wasn't flushed at the proper time, and the transaction's
binlog cache data was not durable while trying to copy the content
from the binlog cache file into the binary log itself. While switching
the tmp file from a WRITE_CACHE to a READ_CACHE, the server would see
there is still data to flush in the cache, and first try to flush it.
This is not a valid time to flush that data to the temporary file
though, as:

  1. The GTID event has already been written directly to the binary
    log. So if this flushing fails, it leaves the binary log in a
    corrupted state.

  2. This is done during group commit, and will slow down other
    concurrent transactions, which are otherwise ready to commit.

This patch fixes these issues by ensuring all transaction data is
fully flushed to its temporary file (if used) before starting any
critical paths, i.e. in binlog_flush_cache(). Note that if the binlog
cache is solely in-memory, this flush-to-temporary-file is skipped.

Reviewed-by: Andrei Elkin <[email protected]>
Signed-off-by: Brandon Nesterenko <[email protected]>
021b979014f0...
021b979014f04db5d5305bbd18bece138690fd77
Denis Protivensky
MDEV-34124: Fix streaming replication offset for binlog stmt cache

As the binlog statement cache is only replicated with the last
fragment, it's safe to pass zero offset instead of the stored
log position, which is used only for the binlog transaction cache.
BuildBot (0.8.9) working for the MariaDB project.
Page built: Sun 30 Nov 2025 03:41:27 (UTC)