innodb_file_format Barracuda


25

もっとよく知っている人たちにいくつか質問があります。私のインスタンスのほとんどは、Barracudaをサポートしているにもかかわらず、Antelopeを実行しています。

私はいくつかの圧縮innodbテーブルをいじりたいと思っていました。私の理解では、これはBarracuda形式でのみ利用可能です。

  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動的または圧縮テーブルとして指定しない限り、混合は避けられません。

最初のBarracudaテーブルを導入するときに、完全なダンプとリロードを行う必要があることを示すものはありません(mysqlのメジャーバージョンをアップグレードするときに推奨されます)。

回答:


18

だから私はこの質問にほぼ4年遅れて答えています。

  • InnoDBファイル形式は、InnoDBがMySQL Serverから独立していたときに考案されました(たとえば、MySQL 5.1はInnoDBの2つの異なるバージョンを実行できました)。

  • Barracuda(2012年)を実行したくない理由は、MySQLのダウングレードの柔軟性が低下する可能性があるためです(つまり、アップグレードに失敗した後、新しい形式を読み取れないバージョンに戻す必要がある)。すなわち、Antelopeの方が技術的な理由がないはずです。

  • MySQL 5.7では、このinnodb_file_formatオプションは廃止されました。MySQLとInnoDBはもはや独立していないため、InnoDBはMySQLのアップグレードルールと後方互換性が必要なものを使用できます。複雑な設定は必要ありません!

  • MySQL 5.7では、デフォルトがに切り替わりましたBarracuda/DYNAMIC。現在サポートされているMySQLのすべてのリリースはこの形式を読み取ることができるため、Antelopeから離れてダウングレードを提供しても安全です。

  • MySQL 5.7サーバーでBarracuda/DYNAMICは、次のテーブルの再構築(OPTIMIZE TABLEなど)でAntelopeテーブルがアップグレードされます。それは、特にで作成された場合を除きROW_FORMAT=oldrowformatます。

  • MySQL 8.0では、オプションinnodb_file_formatは削除されました。


MySQL 5.7には、デフォルトのDYNAMICのオプションinnodb_default_row_formatも導入されています。これは、更新のポイントに対処します。


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

本当にBarracuda形式を使用してInnoDBを使用したい場合は、すべてをmysqldumpして/root/MySQLData.sqlのようなものにする必要があります。これにより、データファイル形式が独立します。

新しいibdata1とinnodb_file_per_tableで別のMySQLインスタンスを使用します(オプション、個人設定)。ibdata1を空にしてファイル形式を変更します。次に、/ root / MySQLData.sqlをリロードして、データを操作します。

PostgreSQLが9.0.1バイナリで動作するように8.2.4データベースを取得するために設定をtweekしなければならないというちょっとした恐ろしい話を聞きました。両方のファイル形式を同じシステム表領域(ibdata1)に配置しようとした場合、および/または.ibdそのような設定を認識している場合はファイルを作成しようとした場合も、同じ話が当てはまります。

コーシャである限り...

  • 誰も肉と乳製品を同じ冷蔵庫に保管してはならない
  • 誰も同じくびきの下に雄牛とろばを置かないでください(申命記22:10)
  • 誰も同じibdata1の中に保存AntelopeBarracudaてはいけません

更新2013-07-05 14:26 EDT

ServerFaultでこの質問に答えました:MySQL INNODB圧縮KEY_BLOCK_SIZEの設定。これにより、DBA StackExchangeで回答した質問を振り返り、Barracuda形式について議論し、この古い投稿を見つけました。ここに同じ情報を配置します...

InnoDB Compression for Barracudaに関する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に圧縮解除されなければなりません。つまり、バッファプールには圧縮されたデータページと圧縮されていないデータページの2倍のデータコンテンツがあります。

このデータコンテンツの複製がバッファプールで行われている場合、新しい圧縮率の小さな線形係数だけinnodb_buffer_pool_sizeを増やす必要があります。方法は次のとおりです。

シナリオ

  • 8Gバッファープールを備えたDBサーバーがある
  • 圧縮を実行しました key_block_size=8
    • 850.00%16
    • 50.00%8GIS4G
    • 昇給innodb_buffer_pool_sizeへの12G8G+ 4G
  • 圧縮を実行しました key_block_size=4
    • 425.00%16
    • 25.00%8GIS2G
    • 昇給innodb_buffer_pool_sizeへの10G8G+ 2G
  • 圧縮を実行しました key_block_size=2
    • 212.50%16
    • 12.50%8GIS1G
    • 昇給innodb_buffer_pool_sizeへの9G8G+ 1G
  • 圧縮を実行しました key_block_size=1
    • 106.25%16
    • 06.25%8GIS 0.5G512M
    • 昇給innodb_buffer_pool_size8704M8G8192M)+ 512M

ストーリーの道徳:InnoDBバッファープールは、圧縮されたデータとインデックスページを処理するときに、追加のブリージングルームを必要とするだけです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.