mirror of
https://github.com/MariaDB/server.git
synced 2025-01-30 02:30:06 +01:00
e581396b7a
Before commit6112853cda
in MySQL 4.1.1 introduced the parameter innodb_file_per_table, all InnoDB data was written to the InnoDB system tablespace (often named ibdata1). A serious design problem is that once the system tablespace has grown to some size, it cannot shrink even if the data inside it has been deleted. There are also other design problems, such as the server hang MDEV-29930 that should only be possible when using innodb_file_per_table=0 and innodb_undo_tablespaces=0 (storing both tables and undo logs in the InnoDB system tablespace). The parameter innodb_change_buffering was deprecated in commitb5852ffbee
. Starting with commitbaf276e6d4
(MDEV-19229) the number of innodb_undo_tablespaces can be increased, so that the undo logs can be moved out of the system tablespace of an existing installation. If all these things (tables, undo logs, and the change buffer) are removed from the InnoDB system tablespace, the only variable-size data structure inside it is the InnoDB data dictionary. DDL operations on .ibd files was optimized in commit86dc7b4d4c
(MDEV-24626). That should have removed any thinkable performance advantage of using innodb_file_per_table=0. Since there should be no benefit of setting innodb_file_per_table=0, the parameter should be deprecated. Starting with MySQL 5.6 and MariaDB Server 10.0, the default value is innodb_file_per_table=1.
37 lines
1.6 KiB
Text
37 lines
1.6 KiB
Text
set global innodb_compression_algorithm = 1;
|
|
# Create and populate a tables
|
|
CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
|
|
CREATE TABLE t2 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB ROW_FORMAT=COMPRESSED ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
|
|
CREATE TABLE t3 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB ROW_FORMAT=COMPRESSED ENCRYPTED=NO;
|
|
CREATE TABLE t4 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB PAGE_COMPRESSED=1;
|
|
CREATE TABLE t5 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB PAGE_COMPRESSED=1 ENCRYPTED=YES ENCRYPTION_KEY_ID=4;
|
|
CREATE TABLE t6 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT) ENGINE=InnoDB;
|
|
# Run innochecksum on t1, check -S does not cause crash for encrypted file
|
|
# Run innochecksum on t2
|
|
# Run innochecksum on t3
|
|
# Run innochecksum on t4
|
|
# Run innochecksum on t4
|
|
# Run innochecksum on t5
|
|
# Run innochecksum on t6
|
|
# Backup tables before corrupting
|
|
# Corrupt FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION
|
|
# Run innochecksum on t2
|
|
# Run innochecksum on t3
|
|
# no encryption corrupting the field should not have effect
|
|
# Run innochecksum on t6
|
|
# In new checksum format, checksum calculated for whole page.
|
|
# So It should affected.
|
|
# Restore the original tables
|
|
# Corrupt FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION+4 (post encryption checksum)
|
|
# Run innochecksum on t2
|
|
# Run innochecksum on t3
|
|
# Run innochecksum on t6
|
|
# Space ID mismatch
|
|
# Restore the original tables
|
|
# Corrupt FIL_DATA+10 (data)
|
|
# Run innochecksum on t2
|
|
# Run innochecksum on t3
|
|
# Run innochecksum on t6
|
|
# Restore the original tables
|
|
# restart
|
|
DROP TABLE t1, t2, t3, t4, t5, t6;
|