innodb_file_formatバラクーダ
よく知っている人にいくつか質問があります。私のインスタンスのほとんどは、バラクーダをサポートしているにもかかわらず、アンテロープを実行しています。
私はいくつかの圧縮innodbテーブルをいじくり回そうとしていました。私の理解では、これはバラクーダ形式でのみ利用可能です。
- Innodb_file_formatは動的であるため、バウンスせずに切り替えることができます。私が知っておくべきこれを行うことの影響はありますか？私が言えることは、新しいテーブルまたは後で変更されたテーブルがそのフォーマットで作成されるということです。これはすべて正しいですか？
- 私は自分のテーブルをすべて変換して変換する必要がないことを望んでいました。コーシャーは、カモシカとバラクーデのテーブルを同じテーブルスペースに共存させることですか？それが機能しても気を付けなければならないことはありますか？
私がテストから読んで収集したものから、答えは次のとおりです。はい。はい。よく分かりません。
更新
問題のないこの投稿以来、さまざまなインスタンスで動的テーブルと圧縮テーブルをいくつか実行しています。さらに、私は http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html を読むことを怠っていました。
特定のinnodb_file_formatを有効にすると、この変更は既存のテーブルではなく、新しく作成されたテーブルにのみ適用されます。新しいテーブルを作成する場合、テーブルを含むテーブルスペースは、テーブルの機能に必要な「最も古い」または「最も単純な」ファイル形式でタグ付けされます。たとえば、ファイル形式バラクーダを有効にし、圧縮されておらず、ROW_FORMAT = DYNAMICを使用しない新しいテーブルを作成すると、そのテーブルを含む新しいテーブルスペースは、ファイル形式Antelopeを使用するものとしてタグ付けされます。
そのため、バラクーダを許可しても、テーブルはアンテロープとして作成されます。すべてのテーブルをrow_format動的テーブルまたは圧縮テーブルとして指定しない限り、混合は避けられません。
最初のバラクーダテーブルを導入するときに完全なダンプとリロードを実行する必要があることを示すものはありません（たとえば mysqlのメジャーバージョンをアップグレードする場合 ）
だから私はこの質問にほぼ4年遅れで答えています：
InnoDBファイル形式は、InnoDBがMySQLサーバーから独立しているときに考案されました（たとえば、MySQL 5.1は2つの異なるバージョンのInnoDBを実行できました）。
Barracuda（2012年）を実行したくない理由は、MySQLをダウングレードする際の柔軟性が低下する可能性があるためです（つまり、アップグレードが失敗した後、新しい形式を読み取れないバージョンに戻したい）。つまり、Antelopeの方が優れている技術的な理由はないはずです。
MySQL 5.7では、
innodb_file_formatオプションは廃止されました。 MySQLとInnoDBは独立していないため、InnoDBはアップグレードのMySQLルールと、下位互換性が必要なものを使用できます。紛らわしい設定は必要ありません！MySQL 5.7では、デフォルトが
Barracuda/DYNAMICに切り替わりました。 MySQLの現在サポートされているすべてのリリースでこの形式を読み取ることができるため、Antelopeから離れてもダウングレードを提供しても安全です。MySQL 5.7サーバーでは、Antelopeテーブルは次のテーブル再構築（OPTIMIZE TABLEなど）で
Barracuda/DYNAMICにアップグレードされます。特にROW_FORMAT=oldrowformatで作成された場合を除きます。MySQL 8.0では、オプション
innodb_file_formatが削除されました。
MySQL 5.7は オプションinnodb_default_row_format も導入します。デフォルトはDYNAMICです。これは、更新のポイントに対処します。
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)
本当にバラクーダ形式を使用してInnoDBでプレイしたい場合は、mysqldumpをすべて/root/MySQLData.sqlのようなものにダンプする必要があります。これにより、データファイル形式が独立します。
新しいibdata1とinnodb_file_per_tableを使用して別のMySQLインスタンスを使用します（オプション、私の好み）。 ibdata1を空にしてファイル形式を変更します。次に、/ root/MySQLData.sqlをリロードして、データを操作します。
PostgreSQLが8.0.1データベースを9.0.1バイナリで動作させるために設定をtweekに設定する必要があるというちょっとした恐ろしい話を聞いたことがあります。両方のファイル形式を同じシステムテーブルスペース（ibdata1）や.ibdファイルに配置しようとした場合、そのような設定がわかっていれば、同じことが当てはまります。
コーシャである限り...
- 肉と乳製品を同じ冷蔵庫に保管してはいけません
- 雄牛とお尻を同じヨークの下に置くべきではありません（申命記22:10）
AntelopeとBarracudaを同じibdata1内に保存することはできません
UPDATE 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は、メモリに保持するページと、Least-Recently-Used（LRU）リストを使用して削除するページを追跡するため、「ホット」または頻繁にアクセスされるデータがメモリに留まる傾向があります。圧縮テーブルにアクセスすると、InnoDBは適応LRUアルゴリズムを使用して、メモリ内の圧縮ページと非圧縮ページの適切なバランスを実現します。この適応アルゴリズムは、システムがI/Oバウンドで実行されているか、CPUバウンドで実行されているかに影響を受けます。目標は、CPUがビジーなときにページの圧縮を解除するのに多くの処理時間を費やしたり、圧縮されたページ（既にメモリにある可能性がある）の圧縮解除に使用できるスペアサイクルがCPUにあるときに過剰なI/Oを実行したりするのを避けることです。システムがI/Oバウンドの場合、アルゴリズムは、他のディスクページがメモリに常駐するためのスペースを作るために、両方のコピーではなく、ページの非圧縮コピーを削除することを優先します。システムがCPUにバインドされている場合、InnoDBは圧縮ページと非圧縮ページの両方を削除することを好むため、「ホット」ページに使用できるメモリを増やし、メモリ内のデータを圧縮形式でのみ解凍する必要性を減らすことができます。
InnoDBバッファープールは、クエリを実行するために読み込まれたデータページとインデックスページをロードする必要があることに注意してください。テーブルとそのインデックスを初めて読み取るときは、圧縮されたページを16Kに解凍する必要があります。つまり、バッファープールには、圧縮されたデータページと圧縮されていないデータページの2倍のデータコンテンツがあります。
バッファープールでこのデータコンテンツの重複が発生している場合は、 innodb_buffer_pool_size を次の小さな線形係数で増やす必要があります。新しい圧縮率。方法は次のとおりです。
シナリオ
- 8Gバッファープールを備えたDBサーバーがある
key_block_size=8[.____を使用して圧縮を実行しました。]8は50.00%/16です50.00%/8Gは4Gですinnodb_buffer_pool_sizeを12Gにレイズします（8G+4G）
key_block_size=4[.____を使用して圧縮を実行しました。]4は25.00%/16です25.00%/8Gは2Gですinnodb_buffer_pool_sizeを10Gにレイズします（8G+2G）
key_block_size=2[.____を使用して圧縮を実行しました。]2は12.50%/16です12.50%/8Gは1Gですinnodb_buffer_pool_sizeを9Gにレイズします（8G+1G）
key_block_size=1[.____を使用して圧縮を実行しました。]1は06.25%/16です06.25%/8Gは0.5G（512M）ですinnodb_buffer_pool_sizeを8704Mにレイズします（8G（8192M）+512M）
MORAL OF THE STORY：圧縮されたデータとインデックスページを処理する場合、InnoDBバッファープールには追加の呼吸スペースが必要です。