Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.2.30, 10.3.21, 10.4.11
Description
The bug fix MDEV-21069 aimed to avoid a server crash when executing DROP TABLE of a corrupted table. Unfortunately, that fix introduced corruption in the function buf_read_ibuf_merge_pages() and caused wrongful deletion of records from the change buffer for tablespaces whose first page had not been read yet. The following should fix it:
diff --git a/storage/innobase/buf/buf0rea.cc b/storage/innobase/buf/buf0rea.cc
|
--- a/storage/innobase/buf/buf0rea.cc
|
+++ b/storage/innobase/buf/buf0rea.cc
|
@@ -772,13 +772,18 @@ buf_read_ibuf_merge_pages(
|
continue;
|
}
|
|
- if (UNIV_UNLIKELY(page_nos[i] >= space->size)) {
|
+ ulint size = space->size;
|
+ if (!size) {
|
+ size = fil_space_get_size(space->id);
|
+ }
|
+
|
+ if (UNIV_UNLIKELY(page_nos[i] >= size)) {
|
do {
|
ibuf_delete_recs(page_id_t(space_ids[i],
|
page_nos[i]));
|
} while (++i < n_stored
|
&& space_ids[i - 1] == space_ids[i]
|
- && page_nos[i] >= space->size);
|
+ && page_nos[i] >= size);
|
i--;
|
next:
|
space->release(); |
MariaDB Server 10.5 is not affected by this, because this code was removed in MDEV-19514. (However, 10.5 is affected by MDEV-25783 without even involving a server restart.)
Also if crash recovery is needed, those tablespaces for which no redo log was applied could be affected by this bug.
I believe that this kind of corruption can be detected by CHECK TABLE, and it can be fixed by dropping and re-creating the secondary indexes:
CHECK TABLE t QUICK; |
ALTER TABLE t DROP INDEX idx1, DROP INDEX idx2; |
ALTER TABLE t ADD INDEX idx1(a), ADD INDEX idx2(b); |
A work-around would be to ensure that the change buffer is empty during shutdown (set innodb_fast_shutdown=0) or to always run with innodb_change_buffering=none.
This bug was originally reported and analyzed in MDEV-22373, but because MDEV-22373 is partly explained by MDEV-24449 and MDEV-25783, it is clearer to file a separate ticket for this specific case.
Attachments
Issue Links
- is caused by
-
MDEV-21069 Crash on DROP TABLE if the data file is corrupted
-
- Closed
-
- relates to
-
MDEV-22373 Unable to find a record to delete-mark ends up crashing mysqld process after upgrading from 10.1.43 to 10.4
-
- Closed
-
-
MDEV-25796 Failing assertion: !cursor->index->is_committed() in row0ins.cc
-
- Open
-
Activity
Field | Original Value | New Value |
---|---|---|
Link |
This issue is caused by |
Link |
This issue relates to |
Status | Open [ 1 ] | In Progress [ 3 ] |
issue.field.resolutiondate | 2021-06-08 12:30:53.0 | 2021-06-08 12:30:53.456 |
Fix Version/s | 10.2.39 [ 25731 ] | |
Fix Version/s | 10.3.30 [ 25732 ] | |
Fix Version/s | 10.4.20 [ 25733 ] | |
Fix Version/s | 10.2 [ 14601 ] | |
Fix Version/s | 10.3 [ 22126 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Link | This issue blocks MENT-1217 [ MENT-1217 ] |
Link | This issue relates to MDEV-25796 [ MDEV-25796 ] |
Labels | not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed | ServiceNow not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed |
Labels | ServiceNow not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed | 76qDvLB8Gju6Hs7nk3VY3EX42G795W5z not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed |
Remote Link | This issue links to "Page (MariaDB Confluence)" [ 31547 ] |
Remote Link | This issue links to "Page (MariaDB Confluence)" [ 31565 ] |
Remote Link | This issue links to "Page (MariaDB Confluence)" [ 31565 ] |
Labels | 76qDvLB8Gju6Hs7nk3VY3EX42G795W5z not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed | not-10.5 regression-10.2 regression-10.3 regression-10.4 rr-profile-analyzed |
Workflow | MariaDB v3 [ 122506 ] | MariaDB v4 [ 159370 ] |
Remote Link | This issue links to "Page (MariaDB Confluence)" [ 32806 ] |
Remote Link | This issue links to "Page (MariaDB Confluence)" [ 33015 ] |
Zendesk Related Tickets | 201658 | |
Zendesk active tickets | 201658 |
We have been using the combination of
innodb_change_buffering=none + rebuilding the tables that got reported by check tables after upgrading to 10.4 and so far it seems ok.