innodb_file_format Barracuda


25

Ich habe ein paar Fragen für die Vertrauten. Die meisten meiner Instanzen haben Antelope ausgeführt, obwohl sie Barracuda unterstützen.

Ich wollte mit ein paar Kompressen an Innodb-Tischen herumspielen. Meines Wissens ist dies nur im Barracuda-Format verfügbar.

  1. Ich sehe, dass innodb_file_format dynamisch ist, so dass ich einfach ohne einen Sprung umschalten kann. Gibt es irgendwelche Implikationen, die ich beachten sollte? Ich kann nur sagen, dass neue Tabellen oder nachträglich geänderte mit diesem Format erstellt werden. Ist das alles richtig?
  2. Ich hatte gehofft, nicht alle meine Tabellen durchgehen und konvertieren zu müssen. Ist es koscher, wenn Antilopen- und Barrakude-Tische im selben Tablespace existieren? Auch wenn es funktioniert, gibt es irgendwelche Fallstricke, auf die man achten muss?

Nach dem, was ich gelesen und aus meinen Tests entnommen habe, lauten die Antworten: Ja. Ja. Ich bin mir nicht sicher.

Aktualisieren

Ich habe seit diesem Post mit einigen dynamischen und einigen komprimierten Tabellen in verschiedenen Instanzen ohne Problem ausgeführt. Außerdem habe ich es versäumt, http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html zu lesen .

Nachdem Sie ein bestimmtes innodb_file_format aktiviert haben, gilt diese Änderung nur für neu erstellte und nicht für vorhandene Tabellen. Wenn Sie eine neue Tabelle erstellen, wird der Tabellenbereich, der die Tabelle enthält, mit dem „frühesten“ oder „einfachsten“ Dateiformat gekennzeichnet, das für die Tabellenfunktionen erforderlich ist. Wenn Sie beispielsweise das Dateiformat Barracuda aktivieren und eine neue Tabelle erstellen, die nicht komprimiert ist und ROW_FORMAT = DYNAMIC nicht verwendet, wird der neue Tabellenbereich, der die Tabelle enthält, mit dem Dateiformat Antelope gekennzeichnet.

Daher werden Tabellen als Antelope erstellt, auch wenn Sie Barracuda zulassen. Das Mischen ist unvermeidlich, es sei denn, Sie geben jede Tabelle als row_format dynamic oder als komprimierte Tabelle an.

Es gibt keinen Hinweis darauf, dass Sie beim Einführen Ihrer ersten Barracuda-Tabelle einen vollständigen Dump und ein erneutes Laden durchführen sollten (wie es beim Upgrade der Hauptversionen von mysql empfohlen wird ).

Antworten:


18

Also beantworte ich diese Frage fast 4 Jahre zu spät:

  • InnoDB-Dateiformate wurden zu einer Zeit entwickelt, als InnoDB unabhängig von MySQL Server war (Beispiel: MySQL 5.1 konnte zwei verschiedene Versionen von InnoDB ausführen).

  • Der Grund, warum Sie Barracuda (2012) nicht ausführen möchten, ist, dass es die Flexibilität beim Downgrade von MySQL verringern kann (dh, Sie möchten nach einem fehlgeschlagenen Upgrade auf eine Version zurückkehren, die kein neueres Format lesen kann). dh es sollte keine technischen Gründe geben, warum Antelope besser ist.

  • In MySQL 5.7 war die innodb_file_formatOption veraltet. Da MySQL und InnoDB nicht mehr unabhängig voneinander sind, kann InnoDB die MySQL-Regeln für Upgrades verwenden und festlegen, welche Abwärtskompatibilität erforderlich ist. Keine verwirrende Einstellung erforderlich!

  • In MySQL 5.7 wurde der Standard auf umgestellt Barracuda/DYNAMIC. Da alle derzeit unterstützten Versionen von MySQL dieses Format lesen können, ist es sicher, sich von Antelope zu entfernen und dennoch ein Downgrade anzubieten.

  • Auf einem MySQL 5.7-Server werden Antelope-Tabellen Barracuda/DYNAMICbeim nächsten Neuaufbau der Tabelle (OPTIMIZE TABLE usw.) aktualisiert. Das heißt, es sei denn, sie wurden speziell mit erstellt ROW_FORMAT=oldrowformat.

  • In MySQL 8.0 wurde die Option innodb_file_formatentfernt.


MySQL 5.7 führt auch die Option eininnodb_default_row_format , die standardmäßig DYNAMIC verwendet. Hiermit wird der Punkt in Ihrem Update behoben.


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

Wenn Sie wirklich mit InnoDB im Barracuda-Format spielen möchten, sollten Sie alles in etwas wie /root/MySQLData.sql verschieben. Das macht das Dateiformat unabhängig.

Verwenden Sie eine andere MySQL-Instanz mit einem frischen ibdata1 und innodb_file_per_table (optional, meine persönliche Präferenz). Ändern Sie das Dateiformat, indem Sie ibdata1 leer lassen. Laden Sie dann /root/MySQLData.sql neu und spielen Sie mit den Daten.

Ich habe leichte Horrorgeschichten darüber gehört, dass PostgreSQL die Einstellungen zwischendurch ändern muss, damit eine 8.2.4-Datenbank mit 9.0.1-Binärdateien funktioniert. Dieselbe Geschichte könnte zutreffen, wenn wir versuchen würden, beide Dateiformate in demselben Systemtabellenbereich (ibdata1) und / oder in derselben .ibdDatei zu speichern, wenn wir solche Einstellungen kennen.

Soweit koscher zu sein ...

  • Niemand sollte Fleisch und Milchprodukte im selben Kühlschrank lagern
  • Niemand sollte einen Stier und einen Esel unter das gleiche Joch stellen (5. Mose 22:10)
  • Niemand sollte Antelopeund Barracudainnerhalb derselben ibdata1 speichern

UPDATE 2013-07-05 14:26 EDT

Ich habe diese Frage gerade in ServerFault beantwortet: Festlegen der MySQL INNODB-Komprimierung KEY_BLOCK_SIZE . Dies ließ mich auf alle Fragen zurückblicken, die ich in dem DBA StackExchange beantwortet hatte, der das BarracudaFormat besprochen hatte , und ich fand diesen alten Beitrag von mir. Ich werde die gleichen Informationen hier platzieren ...

Laut der MySQL-Dokumentation zur InnoDB-Komprimierung für Barracuda

Komprimierung und der InnoDB-Pufferpool

In einer komprimierten InnoDB-Tabelle entspricht jede komprimierte Seite (1K, 2K, 4K oder 8K) einer nicht komprimierten Seite von 16K Bytes. Um auf die Daten auf einer Seite zuzugreifen, liest InnoDB die komprimierte Seite von der Festplatte, sofern sie nicht bereits im Pufferpool enthalten ist, und dekomprimiert die Seite in die ursprüngliche 16-KB-Form. In diesem Abschnitt wird beschrieben, wie InnoDB den Pufferpool in Bezug auf Seiten komprimierter Tabellen verwaltet.

Manchmal enthält der Pufferpool sowohl die komprimierte als auch die unkomprimierte Form einer Datenbankseite, um die E / A zu minimieren und die Dekomprimierung einer Seite zu reduzieren. Um Platz für andere erforderliche Datenbankseiten zu schaffen, kann InnoDB eine nicht komprimierte Seite aus dem Pufferpool "entfernen", während die komprimierte Seite im Speicher verbleibt. Wenn auf eine Seite längere Zeit nicht zugegriffen wurde, wird die komprimierte Form der Seite möglicherweise auf die Festplatte geschrieben, um Speicherplatz für andere Daten freizugeben. Somit kann der Pufferpool zu jeder Zeit sowohl die komprimierte als auch die nicht komprimierte Form der Seite oder nur die komprimierte Form der Seite oder keine enthalten.

InnoDB verfolgt mithilfe einer LRU-Liste (Least Recent Used), welche Seiten im Speicher aufbewahrt werden sollen, und welche, damit häufig aufgerufene Daten im Speicher verbleiben. Beim Zugriff auf komprimierte Tabellen verwendet InnoDB einen adaptiven LRU-Algorithmus, um ein angemessenes Gleichgewicht zwischen komprimierten und nicht komprimierten Seiten im Speicher zu erreichen. Dieser adaptive Algorithmus reagiert darauf, ob das System E / A- oder CPU-gebunden ausgeführt wird. Das Ziel besteht darin, zu vermeiden, dass zu viel Verarbeitungszeit für das Dekomprimieren von Seiten aufgewendet wird, wenn die CPU ausgelastet ist, und dass übermäßige E / A-Vorgänge durchgeführt werden, wenn die CPU über Reservezyklen verfügt, die zum Dekomprimieren komprimierter Seiten (die sich möglicherweise bereits im Speicher befinden) verwendet werden können. Wenn das System E / A-gebunden ist, entfernt der Algorithmus lieber die nicht komprimierte Kopie einer Seite als beide Kopien. um mehr Platz für andere Plattenseiten zu schaffen, damit diese im Arbeitsspeicher gespeichert werden können. Wenn das System CPU-gebunden ist, zieht InnoDB es vor, sowohl die komprimierte als auch die nicht komprimierte Seite zu entfernen, damit mehr Speicher für "heiße" Seiten verwendet werden kann und die Notwendigkeit verringert wird, Daten im Speicher nur in komprimierter Form zu dekomprimieren.

Beachten Sie, dass der InnoDB-Pufferpool Datenseiten und Indexseiten laden muss, um Abfragen zu erfüllen. Beim erstmaligen Lesen einer Tabelle und ihrer Indizes muss die komprimierte Seite auf 16 KB dekomprimiert werden. Das heißt, Sie haben doppelt so viel Dateninhalt im Pufferpool, der komprimierten und der unkomprimierten Datenseite.

Wenn diese Duplizierung des Dateninhalts im Pufferpool stattfindet , müssen Sie innodb_buffer_pool_size um einen kleinen linearen Faktor der neuen Komprimierungsrate erhöhen. Hier ist, wie:

SZENARIO

  • Sie haben einen DB Server mit einem 8G Buffer Pool
  • Sie haben die Komprimierung mit ausgeführt key_block_size=8
    • 8ist 50.00%von16
    • 50.00%von 8Gist4G
    • erhöhen innodb_buffer_pool_sizeauf 12G( 8G+ 4G)
  • Sie haben die Komprimierung mit ausgeführt key_block_size=4
    • 4ist 25.00%von16
    • 25.00%von 8Gist2G
    • erhöhen innodb_buffer_pool_sizeauf 10G( 8G+ 2G)
  • Sie haben die Komprimierung mit ausgeführt key_block_size=2
    • 2ist 12.50%von16
    • 12.50%von 8Gist1G
    • erhöhen innodb_buffer_pool_sizeauf 9G( 8G+ 1G)
  • Sie haben die Komprimierung mit ausgeführt key_block_size=1
    • 1ist 06.25%von16
    • 06.25%von 8Gis 0.5G( 512M)
    • erhöhen innodb_buffer_pool_sizeauf 8704M( 8G( 8192M) + 512M)

MORAL DER GESCHICHTE : Der InnoDB- Pufferpool benötigt nur zusätzlichen Freiraum für den Umgang mit komprimierten Daten und Indexseiten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.