mirror of
https://github.com/MariaDB/server.git
synced 2025-11-19 12:09:41 +01:00
9c6017474f
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ä.
|
||
|---|---|---|
| .. | ||
| archive | ||
| atomic | ||
| binlog | ||
| binlog_encryption | ||
| client | ||
| compat | ||
| csv | ||
| encryption | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| galera | ||
| galera_3nodes | ||
| galera_3nodes_sr | ||
| galera_sr | ||
| gcol | ||
| handler | ||
| heap | ||
| innodb | ||
| innodb_fts | ||
| innodb_gis | ||
| innodb_i_s | ||
| innodb_zip | ||
| jp | ||
| json | ||
| large_tests | ||
| maria | ||
| mariabackup | ||
| mtr/t | ||
| mtr2 | ||
| multi_source | ||
| optimizer_unfixed_bugs | ||
| parts | ||
| perfschema | ||
| perfschema_stress | ||
| period | ||
| plugins | ||
| roles | ||
| rpl | ||
| s3 | ||
| sql_sequence | ||
| storage_engine | ||
| stress | ||
| sys_vars | ||
| sysschema | ||
| unit | ||
| vcol | ||
| versioning | ||
| wsrep | ||