innodb_file_format梭子鱼


25

对于那些比较熟悉的人,我有几个问题。尽管有梭子鱼的支持,我的大多数实例仍在运行Antelope。

我一直在寻找一些压缩innodb表的方法。我的理解是,这仅在梭子鱼格式下可用。

  1. 我看到innodb_file_format是动态的,因此我可以不跳动地切换。我应该意识到这样做的任何含义。我只能说意味着将使用该格式创建新表或随后更改的表。这一切正确吗?
  2. 我希望不必经历所有表的转换。犹太洁食器是否在同一表空间中同时存在羚羊和梭子鱼表?即使有效,也有什么需要注意的地方吗?

从我阅读并从测试中收集的信息来看,答案是:是的。是。我不确定。

更新资料

自这篇文章发布以来,我一直在各种实例中运行一些动态表和一些压缩表。此外,我 当时忽略了阅读http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html

启用给定的innodb_file_format后,此更改仅适用于新创建的表,而不适用于现有的表。如果您确实创建了一个新表,则包含该表的表空间将被标记为具有该表功能所需的“最早”或“最简单”的文件格式。例如,如果启用文件格式梭子鱼,并创建未压缩且不使用ROW_FORMAT = DYNAMIC的新表,则包含该表的新表空间将被标记为使用文件格式Antelope。

因此,即使您允许梭子鱼,表也将被创建为羚羊。除非您将每个表都指定为row_format动态表或压缩表,否则混合是不可避免的。

没有迹象表明您在引入第一个梭子鱼表时应该进行完整的转储和重新加载(例如在升级主要版本的mysql时建议使用)

Answers:


18

所以我迟了将近四年回答这个问题:

  • InnoDB文件格式是在InnoDB独立于MySQL Server的时候构思的(例如:MySQL 5.1可以运行两个不同版本的InnoDB)。

  • 您不希望运行梭子鱼(2012年)的原因是,它可能会降低降级MySQL的灵活性(即,升级失败后,您想回到无法读取新格式的版本)。也就是说,羚羊更好的原因没有技术上的原因。

  • 在MySQL 5.7中,该innodb_file_format选项已被弃用。由于MySQL和InnoDB不再独立,因此InnoDB可以使用MySQL升级规则以及需要向后兼容的规则。无需混淆设置!

  • 在MySQL 5.7中,默认设置切换为Barracuda/DYNAMIC。由于当前所有受支持的MySQL版本都可以读取此格式,因此可以安全地离开Antelope并仍然提供降级。

  • 在MySQL 5.7服务器上,羚羊表将Barracuda/DYNAMIC在下一次表重建(OPTIMIZE TABLE等)时升级到。除非它们是使用专门创建的ROW_FORMAT=oldrowformat

  • 在MySQL 8.0中,该选项innodb_file_format已删除。


MySQL 5.7还引入了optioninnodb_default_row_format,默认为DYNAMIC。这解决了更新中的要点。


11
Just give a try!!!

mysql> select version();
+------------+
| version()  |
+------------+
| 5.5.21-log |
+------------+
1 row in set (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
| innodb_file_per_table    | ON       |
+--------------------------+----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Antelope  |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format_max = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Barracuda |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

I had observed a single line logged in Error Log file :

[root@dhcppc0 Desktop]# tail -1 /usr/local/mysql/data/dhcppc0.err
120402 11:26:52 [Info] InnoDB: the file format in the system tablespace is
now set to Barracuda.

After switching to barracuda file format, I could also access my Database
and tables without any error :

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| opentaps1          |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> use opentaps1;
Database changed
mysql> select count(*) from product;
+----------+
| count(*) |
+----------+
|     3244 |
+----------+
1 row in set (0.42 sec)

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status: 
=====================================
120402 11:36:29 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 18446744073709534037 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 1_second, 12 sleeps, 1 10_second, 2 background,
2 flush
srv_master_thread log flush and writes: 12
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 5, signal count 5
Mutex spin waits 2, rounds 60, OS waits 2
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter F01
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION F00, not started
MySQL thread id 1, OS thread handle 0x7f38309f9710, query id 28 localhost
root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer
thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
554 OS file reads, 7 OS file writes, 7 OS fsyncs
-0.01 reads/s, 16384 avg bytes/read, -0.00 writes/s, -0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276707, node heap has 15 buffer(s)
-0.15 hash searches/s, -0.12 non-hash searches/s
---
LOG
---
Log sequence number 221536390
Log flushed up to   221536390
Last checkpoint at  221536390
0 pending log writes, 0 pending chkp writes
10 log i/o's done, -0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 3476070
Buffer pool size   8192
Free buffers       7635
Database pages     542
Old database pages 220
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
-0.00 youngs/s, -0.00 non-youngs/s
Pages read 542, created 0, written 1
-0.01 reads/s, -0.00 creates/s, -0.00 writes/s
Buffer pool hit rate 980 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead -0.00/s, evicted without access -0.00/s, Random read ahead
-0.00/s
LRU len: 542, unzip_LRU len: 0
I/O sum[0]:cur[238], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2937, id 139879303665424, state: waiting for server
activity
Number of rows inserted 0, updated 0, deleted 0, read 3244
-0.00 inserts/s, -0.00 updates/s, -0.00 deletes/s, -0.18 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)

9

如果您真的想使用梭子鱼格式使用InnoDB,则应将所有内容都mysqldump到/root/MySQLData.sql之类。这使得数据文件格式独立。

使用另一个带有新的ibdata1和innodb_file_per_table的MySQL实例(可选,根据我的个人喜好)。在ibdata1为空的情况下更改文件格式。然后,重新加载/root/MySQLData.sql并处理数据。

我听说过有关PostgreSQL必须进行tweek设置才能使8.2.4数据库与9.0.1二进制一起使用的一些恐怖故事。如果我们尝试使两种文件格式都驻留在同一系统表空间(ibdata1)和/或.ibd文件中(如果我们知道此类设置),则可能适用相同的说法。

据犹太洁食...

  • 没有人应该将肉类和乳制品存放在同一台冰箱中
  • 没有人应该把公牛和驴子放在同一个轭上(申命记22:10)
  • 没有人应该在相同的ibdata1中存储Antelope和存储Barracuda

更新2013-07-05 14:26 EDT

我刚刚在ServerFault中回答了这个问题:设置MySQL INNODB压缩KEY_BLOCK_SIZE。这使我回想起我在DBA StackExchange中回答的任何讨论Barracuda格式的问题,而我发现了我的这个旧帖子。我将在此处放置相同的信息...

根据有关梭子鱼的InnoDB压缩的 MySQL文档

压缩和InnoDB缓冲池

在压缩的InnoDB表中,每个压缩页(无论是1K,2K,4K还是8K)都对应于一个16K字节的未压缩页。为了访问页面中的数据,InnoDB从磁盘读取压缩的页面(如果它不在缓冲池中),然后将页面解压缩为原始的16K字节格式。本节介绍InnoDB如何针对压缩表的页面管理缓冲池。

为了最大程度地减少I / O并减少解压缩页面的需求,缓冲池有时会同时包含数据库页面的压缩形式和未压缩形式。为了为其他必需的数据库页面腾出空间,InnoDB可以从缓冲池中“退出”未压缩的页面,同时将压缩后的页面保留在内存中。或者,如果一段时间未访问页面,则可以将页面的压缩形式写入磁盘,以释放其他数据的空间。因此,在任何给定时间,缓冲池都可以包含页面的压缩形式和未压缩形式,或者仅包含页面的压缩形式,或者都不包含。

InnoDB使用最近最少使用(LRU)列表来跟踪哪些页面保留在内存中以及哪些页面被逐出,以便“热”或频繁访问的数据倾向于保留在内存中。当访问压缩表时,InnoDB使用自适应LRU算法来实现内存中压缩和未压缩页面的适当平衡。此自适应算法对系统是以I / O绑定还是CPU绑定方式运行很敏感。目的是避免在CPU繁忙时花费过多的处理时间来解压缩页面,并避免在CPU具有可用于解压缩压缩页面(可能已经在内存中)的空闲周期时执行过多的I / O。当系统受I / O限制时,算法更喜欢逐出页面的未压缩副本,而不是两个副本,为其他磁盘页腾出更多空间来驻留内存。当系统受CPU限制时,InnoDB宁愿退出已压缩和未压缩的页面,以便更多的内存可用于“热”页面,从而减少了仅以压缩形式解压缩内存中数据的需求。

请注意,InnoDB缓冲池必须加载数据页和读取的索引页以完成查询。首次读取表及其索引时,压缩页必须解压缩为16K。这意味着缓冲池(压缩和未压缩的数据页)中的数据内容将是原来的两倍。

如果在缓冲池中正在进行这种重复的数据内容,则需要将innodb_buffer_pool_size增加新压缩率的一小部分线性系数。方法如下:

场景

  • 您的数据库服务器具有8G缓冲池
  • 您进行了压缩 key_block_size=8
    • 850.00%16
    • 50.00%8G4G
    • innodb_buffer_pool_size12G8G+ 4G
  • 您进行了压缩 key_block_size=4
    • 425.00%16
    • 25.00%8G2G
    • innodb_buffer_pool_size10G8G+ 2G
  • 您进行了压缩 key_block_size=2
    • 212.50%16
    • 12.50%8G1G
    • innodb_buffer_pool_size9G8G+ 1G
  • 您进行了压缩 key_block_size=1
    • 106.25%16
    • 06.25%8G0.5G512M
    • innodb_buffer_pool_size8704M8G8192M)+ 512M

故事的寓意:处理压缩数据和索引页时,InnoDB缓冲池仅需要更多的喘息空间。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.