it-swarm-eu.dev

innodb_file_format Barracuda

Ich habe ein paar Fragen an die Vertrauten. Die meisten meiner Instanzen haben Antelope ausgeführt, obwohl ich Barracuda unterstützt habe.

Ich wollte mit ein paar Kompressen an Innodb-Tischen herumspielen. Nach meinem Verständnis 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 Auswirkungen, die mir bewusst sein sollten? Ich kann nur sagen, dass neue Tabellen oder später geänderte Tabellen mit diesem Format erstellt werden. Ist das alles richtig?
  2. Ich hatte gehofft, nicht alle meine Tabellen konvertieren zu müssen. Ist es koscher, Antilopen- und Barrakudetabellen im selben Tabellenbereich zu haben? Auch wenn es funktioniert Gibt es irgendwelche Fallstricke, auf die man achten muss?

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

Update

Ich habe seit diesem Beitrag ohne Probleme in einigen Fällen mit einigen dynamischen und einigen komprimierten Tabellen 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 Tabellen und nicht für vorhandene. Wenn Sie eine neue Tabelle erstellen, wird der Tabellenbereich, der die Tabelle enthält, mit dem Dateiformat "frühestes" oder "einfachstes" gekennzeichnet, das für die Funktionen der Tabelle erforderlich ist. Wenn Sie beispielsweise das Dateiformat Barracuda aktivieren und eine neue Tabelle erstellen, die nicht komprimiert ist und nicht ROW_FORMAT = DYNAMIC verwendet, wird der neue Tabellenbereich, der die Tabelle enthält, als Dateiformat Antelope gekennzeichnet.

So werden Tabellen als Antilope 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 bei der Einführung Ihrer ersten Barracuda-Tabelle einen vollständigen Speicherauszug durchführen und neu laden sollten (wie dies empfohlen wird, wenn Aktualisierung der Hauptversionen von MySQL ).

28
atxdba

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

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

  • Der Grund, warum Sie Barracuda (2012) nicht ausführen möchten, besteht darin, dass dies die Flexibilität beim Downgrade von MySQL verringern könnte (d. H. Nach einem fehlgeschlagenen Upgrade möchten Sie zu einer Version zurückkehren, die kein neueres Format lesen kann). d.h. es sollte keine technischen Gründe geben, warum Antilope besser ist.

  • In MySQL 5.7 war die Option innodb_file_format Veraltet. Da MySQL und InnoDB nicht mehr unabhängig sind und InnoDB somit die MySQL-Regeln für Upgrades verwenden kann und welche Abwärtskompatibilität erforderlich ist. Keine verwirrende Einstellung erforderlich!

  • In MySQL 5.7 wurde die Standardeinstellung auf Barracuda/DYNAMIC Umgeschaltet. 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 beim nächsten erneuten Erstellen der Tabelle (OPTIMIZE TABLE usw.) auf Barracuda/DYNAMIC Aktualisiert. Es sei denn, sie wurden speziell mit ROW_FORMAT=oldrowformat Erstellt.

  • In MySQL 8.0 wurde die Option innodb_file_format Entfernt.


MySQL 5.7 führt auch die Option innodb_default_row_format ein, die standardmäßig DYNAMIC ist. Dies behebt den Punkt in Ihrem Update.

20
Morgan Tocker
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 :

[[email protected] 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
Gopinath

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

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

Ich habe leichte Horrorgeschichten darüber gehört, dass PostgreSQL Einstellungen tweeken 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 im selben Systemtabellenbereich (ibdata1) und/oder in der Datei .ibd Zu speichern, wenn uns solche Einstellungen bekannt sind.

Soweit koscher ...

  • Niemand sollte Fleisch und Milchprodukte im selben Kühlschrank lagern
  • Niemand sollte einen Stier und einen Esel unter dasselbe Joch legen (5. Mose 22:10).
  • Niemand sollte Antelope und Barracuda in denselben 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 im DBA beantwortet hatte. StackExchange hatte das Format Barracuda besprochen und ich fand meinen alten Beitrag. Ich werde die gleichen Informationen hier platzieren ...

Gemäß der MySQL-Dokumentation zur InnoDB-Komprimierung für Barracuda

Komprimierung und der InnoDB-Pufferpool

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

Um die E/A zu minimieren und die Notwendigkeit zu verringern, eine Seite zu dekomprimieren, enthält der Pufferpool manchmal sowohl die komprimierte als auch die unkomprimierte Form einer Datenbankseite. 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 seit einiger Zeit nicht mehr zugegriffen wurde, kann die komprimierte Form der Seite auf die Festplatte geschrieben werden, um Speicherplatz für andere Daten freizugeben. Somit kann der Pufferpool zu jedem Zeitpunkt sowohl die komprimierte als auch die unkomprimierte 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 gespeichert und welche entfernt werden sollen, sodass „heiße“ oder häufig aufgerufene Daten im Speicher bleiben. 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 ist abhängig davon, ob das System E/A-gebunden oder CPU-gebunden ausgeführt wird. Ziel ist es, zu vermeiden, dass zu viel Verarbeitungszeit für das Dekomprimieren von Seiten aufgewendet wird, wenn die CPU ausgelastet ist, und dass keine übermäßigen E/A-Vorgänge ausgeführt werden, wenn die CPU über freie Zyklen verfügt, die zum Dekomprimieren komprimierter Seiten verwendet werden können (die sich möglicherweise bereits im Speicher befinden). Wenn das System E/A-gebunden ist, zieht der Algorithmus es vor, die unkomprimierte Kopie einer Seite anstelle beider Kopien zu entfernen, um mehr Platz für andere Festplattenseiten zu schaffen, die speicherresident werden. Wenn das System CPU-gebunden ist, zieht InnoDB es vor, sowohl die komprimierte als auch die unkomprimierte 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 bedeutet, dass Sie doppelt so viel Dateninhalt im Pufferpool haben, 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 von erhöhen die neue Komprimierungsrate. Hier ist, wie:

SZENARIO

  • Sie haben einen DB-Server mit einem 8G-Pufferpool
  • Sie haben die Komprimierung mit key_block_size=8 Ausgeführt.
    • 8 Ist 50.00% Von 16
    • 50.00% Von 8G Ist 4G
    • erhöhen Sie innodb_buffer_pool_size auf 12G (8G + 4G)
  • Sie haben die Komprimierung mit key_block_size=4 Ausgeführt.
    • 4 Ist 25.00% Von 16
    • 25.00% Von 8G Ist 2G
    • erhöhen Sie innodb_buffer_pool_size auf 10G (8G + 2G)
  • Sie haben die Komprimierung mit key_block_size=2 Ausgeführt.
    • 2 Ist 12.50% Von 16
    • 12.50% Von 8G Ist 1G
    • erhöhen Sie innodb_buffer_pool_size auf 9G (8G + 1G)
  • Sie haben die Komprimierung mit key_block_size=1 Ausgeführt.
    • 1 Ist 06.25% Von 16
    • 06.25% Von 8G Ist 0.5G (512M)
    • erhöhen Sie innodb_buffer_pool_size auf 8704M (8G (8192M) + 512M)

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

9
RolandoMySQLDBA