Details
-
Task
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
None
Description
Now that MDEV-19229 allows the parameter innodb_undo_tablespaces to be increased from its current default value 0, we should enable multiple undo tablespaces by default. Likewise, we should set innodb_undo_log_truncate=ON by default, so that the space occupied by possible bursts of undo log records will be eventually reclaimed.
Edit: Based on some preliminary performance test results presented by axel, innodb_undo_log_truncate=ON seems to reduce throughput. That setting can be changed by SET GLOBAL while the server is running. The main thing here is to run the server with multiple tablespaces by default, so that it will be possible to truncate the undo tablespaces while the server is running.
Space that was occupied by undo logs in the system tablespace will not be reclaimed until MDEV-14795 has been implemented.
Attachments
Issue Links
- causes
-
MDEV-32974 Member fails to join due to old seqno in GTID
-
- Closed
-
- is blocked by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Stalled
-
-
-
- Closed
-
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue is blocked by |
| Link |
This issue is blocked by |
| Link |
This issue relates to |
| Link |
This issue is blocked by |
| Link |
This issue relates to |
| Link |
This issue is blocked by |
Apart from encryption, there were some issues with backup as well.
thiru, can you please check my draft commit and file&fix the bugs separately, in the earliest applicable version?
| Assignee | Marko Mäkelä [ marko ] | Thirunarayanan Balathandayuthapani [ thiru ] |
I applied thiru’s fixes. We have one more problem, which will need to be filed and fixed in 10.6, once we can reproduce it (under RQG, I suppose):
CURRENT_TEST: parts.partition_alter4_innodb
|
--- /mariadb/10.10/mysql-test/suite/parts/r/partition_alter4_innodb.result 2022-10-13 10:57:18.766594249 +0300
|
+++ /mariadb/10.10/mysql-test/suite/parts/r/partition_alter4_innodb.reject 2022-11-28 15:17:30.451478711 +0200
|
@@ -69868,6 +69868,9 @@
|
test.t1 analyze status OK
|
CHECK TABLE t1 EXTENDED;
|
Table Op Msg_type Msg_text
|
+test.t1 check Warning InnoDB: Unpurged clustered index record in table `test`.`t1` /* Partition `part_2` */: COMPACT RECORD(info_bits=32, 8 fields): {[6] OH(0x000000004F48),[6] (0x00000000D185),[7], =(0x2C000001CA0D3D),[4] (0x80000008),[4] (0x80000008),[20]8 (0x3820202020202020202020202020202020202020),[20]8 (0x3820202020202020202020202020202020202020),[7]===8===(0x3D3D3D383D3D3D)}
|
+test.t1 check Warning InnoDB: Unpurged clustered index record in table `test`.`t1` /* Partition `part_3` */: COMPACT RECORD(info_bits=32, 8 fields): {[6] OV(0x000000004F56),[6] (0x00000000D185),[7], K(0x2C000001CA0E4B),[4] (0x8000000E),[4] (0x8000000E),[20]14 (0x3134202020202020202020202020202020202020),[20]14 (0x3134202020202020202020202020202020202020),[8]===14===(0x3D3D3D31343D3D3D)}
|
+test.t1 check Warning InnoDB: Unpurged clustered index record in table `test`.`t1` /* Partition `part_4` */: COMPACT RECORD(info_bits=32, 8 fields): {[6] O^(0x000000004F5E),[6] (0x00000000D185),[7], Y(0x2C000001CA0F59),[4] (0x8000000F),[4] (0x8000000F),[20]15 (0x3135202020202020202020202020202020202020),[20]15 (0x3135202020202020202020202020202020202020),[8]===15===(0x3D3D3D31353D3D3D)}
|
test.t1 check status OK
|
CHECKSUM TABLE t1 EXTENDED;
|
Table Checksum |
| Link |
This issue is blocked by |
| Link |
This issue is blocked by |
| Assignee | Thirunarayanan Balathandayuthapani [ thiru ] | Marko Mäkelä [ marko ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Testing [ 10301 ] |
| Assignee | Marko Mäkelä [ marko ] | Matthias Leich [ mleich ] |
A few issues were caught by the regression test suite:
- Upgrade tests fail (
MDEV-30158):Nov 30 12:36:51 debian-buster-amd64 mariadbd[3973]: 2022-11-30 12:36:51 0 [ERROR] InnoDB: Expected to open innodb_undo_tablespaces=3 but was able to find only 0 - A number of incremental backup tests fail on Microsoft Windows (
MDEV-30114). - Galera snapshot transfer is incompatible with innodb_undo_tablespaces>0 (
MDEV-30157):Failing test(s): galera.galera_sst_encrypted galera.galera_sst_rsync galera.galera_sst_rsync2 galera.galera_sst_rsync_data_dir galera.galera_sst_rsync_recv_auto
| Link |
This issue is blocked by |
| Link |
This issue is blocked by |
| Link |
This issue is blocked by |
| Link |
This issue relates to |
| Link |
This issue is blocked by |
When innodb_undo_log_truncate=ON, the size of the undo tablespace files is controlled by the parameter innodb_max_undo_log_size, which was added in MySQL 5.7.5 and MariaDB 10.2.2. Its default value was changed from 1G to 10M in MariaDB 10.2.6. It is a soft limit.
origin/bb-10.11-new-innodb-defaults c434f870a346fb11a6b5932dbdf860ed7e2d2f74 2022-12-12T10:05:22+02:00
|
which contains MDEV-29986, MDEV-19506, MDEV-29694, MDEV-30136, MDEV-29983
|
performed well in RQG testing. No new problems
|
| Status | In Testing [ 10301 ] | Stalled [ 10000 ] |
| Assignee | Matthias Leich [ mleich ] | Marko Mäkelä [ marko ] |
| Description |
Now that |
Now that Edit: Based on some preliminary performance test results presented by [~axel], {{innodb_undo_log_truncate=ON}} seems to reduce throughput. That setting can be changed by {{SET GLOBAL}} while the server is running. The main thing here is to run the server with multiple tablespaces by default, so that it will be possible to truncate the undo tablespaces while the server is running. Space that was occupied by undo logs in the system tablespace will not be reclaimed until |
| Summary | Set innodb_undo_log_truncate=ON and innodb_undo_tablespaces>2 by default | Set innodb_undo_tablespaces=3 by default |
| issue.field.resolutiondate | 2023-01-13 10:58:23.0 | 2023-01-13 10:58:23.783 |
| Fix Version/s | 11.0.1 [ 28548 ] | |
| Fix Version/s | 11.0 [ 28320 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Link |
This issue relates to |
| Labels | performance | Preview_11.0 performance |
| Link | This issue blocks TODO-4056 [ TODO-4056 ] |
| Labels | Preview_11.0 performance | Cloned |
| Link | This issue blocks TODO-4071 [ TODO-4071 ] |
| Labels | Cloned |
| Link |
This issue is duplicated by |
| Link |
This issue relates to |
| Link |
This issue causes |
| Link | This issue relates to MDEV-35689 [ MDEV-35689 ] |
It turns out that one test hangs when using multiple undo tablespaces:
./mtr --mysqld=--innodb-undo-tablespaces=3 encryption.encrypt_and_grepAfter I forcibly killed the server processes, I got the following output:
10.6 6d40274f65b8d145fbf496e9b1b1d46f258de227
CURRENT_TEST: encryption.encrypt_and_grepmysqltest: In included file "./include/wait_condition.inc":included from /mariadb/10.6/mysql-test/suite/encryption/t/encrypt_and_grep.test at line 65:At line 54: query 'let $success= `$wait_condition`' failed with wrong errno <Unknown> (2013): 'Lost connection to server during query', instead of (0)...…2022-11-24 13:42:23 4 [Note] InnoDB: Deleting the meta-data file './test/t1.cfg'2022-11-24 13:42:23 4 [Note] InnoDB: Deleting the meta-data file './test/t2.cfg'2022-11-24 13:42:23 4 [Note] InnoDB: Deleting the meta-data file './test/t3.cfg'2022-11-24 13:42:23 4 [Note] InnoDB: Resuming purge----------SERVER LOG END-------------We need to analyze this deeper to understand if this is to be expected (and the test merely needs to be adjusted), or a genuine code bug.