mysql innodb table 与不一致 row_format
mysql innodb table with inconsistent row_format
我对 MySQL (5.5.59) 有一个奇怪的问题:
我有一个日志数据库(我在其中存储供应商请求的原始数据)。这个table被压缩了:
CREATE TABLE `logs` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`idLogType` tinyint(3) unsigned NOT NULL,
`idAccount` mediumint(8) unsigned NOT NULL,
(...)
`message` text NOT NULL,
`date` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `LOGTYPE` (`idLogType`),
KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
我的目标是通过删除旧记录并重建 table 来清理此 table。由于它很大 table,我使用了 pt-online-schema-change 和 oak-chunk-update 来完成这项工作。
我用 https://shlomi-noach.github.io/openarkkit/oak-chunk-update.html
删除了去年的所有旧记录
然后我执行 table 的重建以释放免费 space(innodb_file_per_table 已启用
pt-online-schema-change
--alter "ENGINE=InnoDB"
--nocheck-replication-filters --execute --statistics --progress=percentage,1
--set-vars='lock_wait_timeout=60' --check-alter
--no-swap-tables --no-drop-triggers --no-drop-old-table --no-drop-new-table
--chunk-time=1 --chunk-size=20 --new-table-name='__new_logs'
h=**HOST_#########**,D=DB_#########,t=logs,u=root --ask-pass
(重点是--alter语句)
所以现在,我有 2 tables:
- 日志(原始日志)
- __new_logs新的(优化)
但它们在结构上并不相同:
SELECT TABLE_NAME, ENGINE, ROW_FORMAT, CREATE_OPTIONS
FROM information_schema.tables
WHERE
ENGINE = 'innodb' AND TABLE_NAME LIKE '%logs'
returns这个结果:
'TABLE_NAME' 'ENGINE' 'ROW_FORMAT' 'CREATE_OPTIONS',
'__new_logs' 'InnoDB' 'Compact' 'row_format=COMPRESSED KEY_BLOCK_SIZE=8',
'logs' 'InnoDB' 'Compressed' 'row_format=COMPRESSED KEY_BLOCK_SIZE=8',
为什么 table __new_logs 被标记为 "compact" 而未压缩,但仍将 "create options" 设置为 row_format=COMPRESSED KEY_BLOCK_SIZE=8
A show create table of the __new_logs table shows:
CREATE TABLE `__new_logs` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`idLogType` tinyint(3) unsigned NOT NULL,
`idAccount` mediumint(8) unsigned NOT NULL,
(...)
`message` text NOT NULL,
`date` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `LOGTYPE` (`idLogType`),
KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
所以它仍然被标记为压缩。
最后一件奇怪的事,table __new_logs 比原始日志大 table...我觉得这个新 table 没有真正完成压缩]...
我想我找到了解决方案...
https://www.percona.com/blog/2014/01/14/innodb-file-formats-here-is-one-pitfall-to-avoid/
SHOW VARIABLES LIKE 'innodb_file_format'
=> 羚羊。
压缩仅适用于梭子鱼。
所以我的 table 日志已经被压缩了,一定是用 innodb_file_format=Barracuda 压缩的,但是变量肯定被恢复为 Antelope...
Si 我需要重新创建 table... 但这次使用良好的文件格式。
我对 MySQL (5.5.59) 有一个奇怪的问题:
我有一个日志数据库(我在其中存储供应商请求的原始数据)。这个table被压缩了:
CREATE TABLE `logs` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`idLogType` tinyint(3) unsigned NOT NULL,
`idAccount` mediumint(8) unsigned NOT NULL,
(...)
`message` text NOT NULL,
`date` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `LOGTYPE` (`idLogType`),
KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
我的目标是通过删除旧记录并重建 table 来清理此 table。由于它很大 table,我使用了 pt-online-schema-change 和 oak-chunk-update 来完成这项工作。
我用 https://shlomi-noach.github.io/openarkkit/oak-chunk-update.html
删除了去年的所有旧记录然后我执行 table 的重建以释放免费 space(innodb_file_per_table 已启用
pt-online-schema-change
--alter "ENGINE=InnoDB"
--nocheck-replication-filters --execute --statistics --progress=percentage,1
--set-vars='lock_wait_timeout=60' --check-alter
--no-swap-tables --no-drop-triggers --no-drop-old-table --no-drop-new-table
--chunk-time=1 --chunk-size=20 --new-table-name='__new_logs'
h=**HOST_#########**,D=DB_#########,t=logs,u=root --ask-pass
(重点是--alter语句)
所以现在,我有 2 tables:
- 日志(原始日志)
- __new_logs新的(优化)
但它们在结构上并不相同:
SELECT TABLE_NAME, ENGINE, ROW_FORMAT, CREATE_OPTIONS
FROM information_schema.tables
WHERE
ENGINE = 'innodb' AND TABLE_NAME LIKE '%logs'
returns这个结果:
'TABLE_NAME' 'ENGINE' 'ROW_FORMAT' 'CREATE_OPTIONS',
'__new_logs' 'InnoDB' 'Compact' 'row_format=COMPRESSED KEY_BLOCK_SIZE=8',
'logs' 'InnoDB' 'Compressed' 'row_format=COMPRESSED KEY_BLOCK_SIZE=8',
为什么 table __new_logs 被标记为 "compact" 而未压缩,但仍将 "create options" 设置为 row_format=COMPRESSED KEY_BLOCK_SIZE=8
A show create table of the __new_logs table shows:
CREATE TABLE `__new_logs` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`idLogType` tinyint(3) unsigned NOT NULL,
`idAccount` mediumint(8) unsigned NOT NULL,
(...)
`message` text NOT NULL,
`date` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `LOGTYPE` (`idLogType`),
KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
所以它仍然被标记为压缩。
最后一件奇怪的事,table __new_logs 比原始日志大 table...我觉得这个新 table 没有真正完成压缩]...
我想我找到了解决方案...
https://www.percona.com/blog/2014/01/14/innodb-file-formats-here-is-one-pitfall-to-avoid/
SHOW VARIABLES LIKE 'innodb_file_format'
=> 羚羊。
压缩仅适用于梭子鱼。
所以我的 table 日志已经被压缩了,一定是用 innodb_file_format=Barracuda 压缩的,但是变量肯定被恢复为 Antelope...
Si 我需要重新创建 table... 但这次使用良好的文件格式。