InnoDB_File_Format Barracuda

dba.stackexchange https://dba.stackexchange.com/questions/14246

  •  16-10-2019
  •  | 
  •  

Frage

Ich habe ein paar Fragen an die bekannteren. Die meisten meiner Fälle haben Antilopen durchgeführt, obwohl er Barracuda unterstützt hat.

Ich wollte mit einigen Compresses InnoDB -Tischen herumspielen. Mein Verständnis ist, dass dies nur im Barracuda -Format verfügbar ist.

  1. Ich sehe, dass innoDB_File_Format dynamisch ist, damit ich einfach ohne Sprung umschalten kann. Gibt es Auswirkungen darauf, dass ich dies bewusst sein sollte. Ich kann nur beurteilen, dass mit diesem Format neue Tabellen oder anschließend geändert werden. Ist das alles richtig?
  2. Ich hatte gehofft, nicht alle meine Tische durchzugehen und umzuwandeln. Ist koscher, wenn sie Antilopen- und Barrakude -Tabellen in derselben Tablespace koexistieren? Selbst wenn es Arbeiten Gibt es Gotcha's, auf die man achten kann?

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

Aktualisieren

Ich habe seit diesem Beitrag ohne Ausgabe mit einigen dynamischen und einigen komprimierten Tabellen in verschiedenen Fällen ausgeführt. Weiter versäumte ich es zu lesen http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identify.html damals.

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, ist der Tablespace, der die Tabelle enthält, mit dem Dateiformat „früheste“ oder „einfachste“ Dateiformat mit dem Tag der Features der Tabelle markiert. 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 Tablespace, der die Tabelle enthält, mit der Verwendung von Dateiformat -Antilopen markiert.

Daher werden Tabellen als Antilope erstellt, auch wenn Sie Barracuda zulassen. Die Mischung ist unvermeidlich, es sei denn, Sie geben jede Tabelle als Row_Format -Dynamik oder eine komprimierte Tabelle an.

Es gibt keinen Hinweis darauf, dass Sie bei der Einführung Ihrer ersten Barracuda -Tabelle einen vollständigen Müllkippe durchführen und neu laden sollten (z. B. wird empfohlen, wenn dies empfohlen wird Aktualisieren der wichtigsten Versionen von MySQL)

War es hilfreich?

Lösung

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 (z. B.: 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 bei der Herabstufung von MySQL verringern kann (dh nach einem fehlgeschlagenen Upgrade möchten Sie zu einer 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 die innodb_file_format Die Option wurde veraltet. Da MySQL und InnoDB nicht mehr unabhängig sind, kann InnoDB die MySQL -Regeln von Upgrades und welche Rückwärtskompatibilität benötigen. Keine verwirrende Einstellung erforderlich!

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

  • Auf einem MySQL 5.7 -Server werden Antelope -Tabellen auf aktualisiert Barracuda/DYNAMIC Auf dem nächsten Tisch wieder aufbauen (Tabelle optimieren usw.). Das heißt, es sei denn, sie wurden speziell mit mit ROW_FORMAT=oldrowformat.

  • In MySQL 8.0 die Option innodb_file_format ist entfernt.

MySQL 5.7 führt auch vor die Option innodb_default_row_format, was standardmäßig dynamisch ist. Dies befasst sich mit dem Punkt in Ihrem Update.

Andere Tipps

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)

Wenn Sie wirklich mit InnoDB mit dem Barracuda -Format spielen möchten, sollten Sie alles zu so etwas wie /root/mysqldata.sql spielen. Das macht das Datendateiformat 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 mit ibdata1 leer. Dann loade /root/mysqldata.sql und spielen Sie mit den Daten.

Ich habe leichte Horrorgeschichten darüber gehört, dass Postgresql Einstellungen für eine Tweek -Datenbank für eine 8.2.4 -Datenbank mit 9.0.1 Binärdateien erhalten muss. Die gleiche Geschichte könnte sich anwenden, wenn wir versuchen, beide Dateiformate in derselben System -Tablespace (ibdata1) und/oder zu befinden .ibd Datei, wenn wir solche Einstellungen kennen.

Soweit es koscher ist ...

  • Niemand sollte Fleisch und Milchprodukte im selben Kühlschrank aufbewahren
  • Niemand sollte einen Stier und einen Arsch unter das gleiche Joch legen (5. Mose 22:10)
  • Niemand sollte aufbewahren Antelope und Barracuda In derselben Ibdata1

Update 2013-07-05 14:26 EDT

Ich habe diese Frage gerade in Serverfault beantwortet: Festlegen von MySQL InnoDB -Komprimierungskomprimierung key_block_size. Dies ließ mich auf alle Fragen zurückblicken, die ich in der DBA -Stackexchange beantwortete, hatte das besprochen Barracuda Format und ich fanden diesen alten Beitrag von mir. Ich werde hier die gleichen Informationen platzieren ...

Laut dem MySQL -Dokumentation auf InnoDB -Komprimierung für Barracuda

Komprimierung und InnoDB -Pufferpool

In einer komprimierten InnoDB -Tabelle entspricht jede komprimierte Seite (ob 1K, 2K, 4K oder 8K) einer unkomprimierten Seite von 16K -Bytes. Um auf die Daten in einer Seite zuzugreifen, liest InnoDB die komprimierte Seite von der Festplatte, wenn sie noch nicht im Pufferpool ist, und enthält dann die Seite mit ihrem ursprünglichen 16 -km -Byteformular. 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 unkomprimieren, 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 unkomprimierte Seite aus dem Pufferpool „räumen“, während die komprimierte Seite im Speicher bleibt. Oder, wenn seit einiger Zeit nicht auf eine Seite zugegriffen wurde, kann die komprimierte Form der Seite auf den freien Speicherplatz für andere Daten geschrieben werden. Daher kann der Pufferpool zu einem bestimmten Zeitpunkt sowohl die komprimierten als auch die unkomprimierten Formen der Seite oder nur die komprimierte Form der Seite oder keine enthalten.

InnoDB verfolgt, welche Seiten im Speicher bleiben und welche mit einer Liste mit am wenigsten reduziertem (LRU) REVICT REVICT sind, sodass „heiß“ oder häufig auf Daten zugegriffen wird. Bei Drucktabellen verwendet InnoDB einen adaptiven LRU -Algorithmus, um ein angemessenes Gleichgewicht der komprimierten und unkomprimierten Seiten im Speicher zu erreichen. Dieser adaptive Algorithmus reagiert empfindlich dafür, ob das System auf I/O-gebundene oder CPU-gebundene Weise ausgeführt wird. Ziel ist es, nicht zu viel Verarbeitungszeit zu verbringen, um Seiten zu unkontrollieren, wenn die CPU besetzt ist, und um überschüssige E/A zu vermeiden, wenn die CPU Ersatzzyklen hat, die zum unkomprimierten Druckseiten verwendet werden können (die sich möglicherweise bereits im Speicher befinden). Wenn das System I/O-gebunden ist, bevorzugt der Algorithmus die nicht komprimierte Kopie einer Seite und nicht bei beiden Kopien, um mehr Platz für andere Festplattenseiten zu schaffen, um ein Gedächtnis zu werden. Wenn das System CPU-gebunden ist, bevorzugt InnoDB es vor, sowohl die komprimierte als auch die unkomprimierte Seite zu räumen, so dass mehr Speicher für „Hot“ -Seiten verwendet werden kann und die Notwendigkeit reduziert, Daten in Speicher nur in komprimierter Form zu entfalten.

Beachten Sie, dass der InnoDB -Pufferpool Datenseiten und Indexseiten laden muss, um Abfragen zu erfüllen. Beim ersten Mal eine Tabelle und ihre Indizes lesen, muss die komprimierte Seite auf 16K nicht übereinstimmen. Das heißt, Sie haben doppelt so viele Dateninhalte im Pufferpool, die komprimierte und unkomprimierte Datenseite.

Wenn diese Duplikation von Dateninhalten im Pufferpool stattfindet, müssen Sie erhöhen innodb_buffer_pool_size durch einen kleinen linearen Faktor der neuen Kompressionsrate. Hier ist, wie:

SZENARIO

  • Sie haben einen DB -Server mit einem 8G -Pufferpool
  • Sie haben Komprimierung mit ausgeführt key_block_size=8
    • 8 ist 50.00% von 16
    • 50.00% von 8G ist 4G
    • heben innodb_buffer_pool_size zu 12G (8G + 4G)
  • Sie haben Komprimierung mit ausgeführt key_block_size=4
    • 4 ist 25.00% von 16
    • 25.00% von 8G ist 2G
    • heben innodb_buffer_pool_size zu 10G (8G + 2G)
  • Sie haben Komprimierung mit ausgeführt key_block_size=2
    • 2 ist 12.50% von 16
    • 12.50% von 8G ist 1G
    • heben innodb_buffer_pool_size zu 9G (8G + 1G)
  • Sie haben Komprimierung mit ausgeführt key_block_size=1
    • 1 ist 06.25% von 16
    • 06.25% von 8G ist 0.5G (512M)
    • heben innodb_buffer_pool_size zu 8704M (8G (8192M) + 512M)

MORAL DER GESCHICHTE : Der InnoDB -Pufferpool benötigt beim Umgang mit Druckdaten und Indexseiten nur zusätzliche Atemraum.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top