主页 / dba / 问题 / 14246
Accepted
atxdba
Asked: 2012-03-02 17:29:42 +0800 CST

innodb_file_format 梭子鱼

  • 772

我有几个问题要问那些更熟悉的人。尽管支持 Barracuda，但我的大多数实例都在运行 Antelope。

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

  1. 我看到 innodb_file_format 是动态的，所以我可以切换而不会反弹。我应该注意这样做是否有任何影响。我只能说这意味着将使用该格式创建新表或随后更改的表。这一切都正确吗？
  2. 我希望不必经历并转换我所有的表格。羚羊和梭子鱼表在同一个表空间中共存是否符合犹太教规？即使它有效，是否有任何需要注意的问题？

根据我阅读并从测试中收集的内容，答案是：是的。是的。我不确定。

更新

自从这篇文章以来，我一直在各种情况下运行一些动态表和一些压缩表，没有问题。 此外，我当时 忽略了阅读http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html 。

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

因此，即使您允许 Barracuda，表格也会被创建为 Antelope。除非您将每个表指定为 row_format 动态表或压缩表，否则混合是不可避免的。

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

mysql innodb

3 个回答

  1. Best Answer

    所以我迟了将近 4 年才回答这个问题：

    • InnoDB 文件格式是在 InnoDB 独立于 MySQL 服务器时构思的（例如：MySQL 5.1 可以运行两个不同版本的 InnoDB）。

    • 您不想运行 Barracuda（2012 年）的原因是它可能会降低 MySQL 降级的灵活性（即在升级失败后，您想回到无法读取更新格式的版本）。即羚羊更好的原因不应该是技术原因。

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

    • 在 MySQL 5.7 中，默认切换到Barracuda/DYNAMIC. 由于所有当前支持的 MySQL 版本都可以读取这种格式，因此离开 Antelope 并仍然提供降级是安全的。

    • 在 MySQL 5.7 服务器上，Antelope 表将Barracuda/DYNAMIC在下一次表重建（OPTIMIZE TABLE 等）时升级。那是除非它们是专门用ROW_FORMAT=oldrowformat.

    • 在 MySQL 8.0 中，该选项innodb_file_format被删除。

    MySQL 5.7 还引入了 optioninnodb_default_row_format，默认为 DYNAMIC。这解决了您更新中的问题。

    • 26 
  2. 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)
    • 11

  3. 如果你真的想使用 Barracuda 格式来玩 InnoDB，你应该 mysqldump 一切到 /root/MySQLData.sql 之类的东西。这使得数据文件格式独立。

    使用另一个带有新 ibdata1 和 innodb_file_per_table 的 MySQL 实例（可选，我个人偏好）。更改 ibdata1 为空的文件格式。然后，重新加载 /root/MySQLData.sql 并使用数据。

    我听说过一些关于 PostgreSQL 不得不调整设置以使 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格式，我找到了我的这篇旧帖子。我将在这里放置相同的信息...

    根据 MySQL Documentation on InnoDB Compression for Barracuda

    压缩和 InnoDB 缓冲池

    在压缩的 InnoDB 表中，每个压缩页面（无论是 1K、2K、4K 还是 8K）都对应一个 16K 字节的未压缩页面。为了访问页面中的数据，InnoDB 从磁盘中读取压缩页面（如果它还没有在缓冲池中），然后将页面解压缩为其原始的 16K 字节形式。本节描述 InnoDB 如何管理关于压缩表页面的缓冲池。

    为了最小化 I/O 并减少解压缩页面的需要，缓冲池有时会同时包含数据库页面的压缩和未压缩形式。为了为其他所需的数据库页面腾出空间，InnoDB 可能会从缓冲池中“驱逐”一个未压缩的页面，同时将压缩页面留在内存中。或者，如果某个页面有一段时间没有被访问，则可以将该页面的压缩形式写入磁盘，为其他数据腾出空间。因此，在任何给定时间，缓冲池都可能包含页面的压缩形式和未压缩形式，或者仅包含页面的压缩形式，或者两者都不包含。

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

    请注意，InnoDB 缓冲池必须加载读取的数据页和索引页才能完成查询。首次读取表及其索引时，必须将压缩页解压缩到 16K。这意味着您将在缓冲池中拥有两倍的数据内容，即压缩和未压缩的数据页。

    如果缓冲池中发生这种数据内容的重复，则需要将innodb_buffer_pool_size增加新压缩率的一个小的线性因子。方法如下：

    设想

    • 你有一个带有 8G 缓冲池的数据库服务器
    • 你运行压缩key_block_size=8
      • 8是50.00%_16
      • 50.00%8G是_4G
      • 升到( + ) innodb_buffer_pool_size_12G8G4G
    • 你运行压缩key_block_size=4
      • 4是25.00%_16
      • 25.00%8G是_2G
      • 升到( + ) innodb_buffer_pool_size_10G8G2G
    • 你运行压缩key_block_size=2
      • 2是12.50%_16
      • 12.50%8G是_1G
      • 升到( + ) innodb_buffer_pool_size_9G8G1G
    • 你运行压缩key_block_size=1
      • 1是06.25%_16
      • 06.25%是( ) 8G_0.5G512M
      • 提高innodb_buffer_pool_size到8704M( 8G( 8192M) + 512M)

    故事的寓意：InnoDB 缓冲池在处理压缩数据和索引页面时只需要额外的喘息空间。

    • 9

相关问题