innodb_file_format Barracuda

25

J'ai quelques questions pour les plus familiers. La plupart de mes instances exécutent Antelope malgré le soutien de Barracuda.

Je cherchais à jouer avec des tables innodb de compresses. Ma compréhension est que cela n'est disponible que sous le format Barracuda.

  1. Je vois que innodb_file_format est dynamique, donc je peux simplement basculer sans rebond. Y a-t-il des implications de faire cela que je devrais être au courant. Tout ce que je peux dire, c'est que cela signifie que de nouvelles tables ou ultérieurement modifiées seront créées avec ce format. Est-ce que tout est correct?
  2. J'espérais ne pas avoir à passer par et convertir toutes mes tables. Les tables d'antilopes et de barracudes coexistent-elles dans le même espace de table? Même si cela fonctionne, y a-t-il des problèmes à rechercher?

D'après ce que j'ai lu et recueilli de mes tests, les réponses sont: Oui. Oui. Je ne suis pas sûr.

Mise à jour

J'ai couru avec des tables dynamiques et des tables compressées dans diverses instances depuis ce post sans problème. De plus, j'ai négligé de lire http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html à l'époque.

Après avoir activé une innodb_file_format donnée, cette modification s'applique uniquement aux tables nouvellement créées plutôt qu'aux tables existantes. Si vous créez une nouvelle table, l'espace de table contenant la table est balisé avec le format de fichier "le plus ancien" ou "le plus simple" requis pour les fonctionnalités de la table. Par exemple, si vous activez le format de fichier Barracuda et créez une nouvelle table qui n'est pas compressée et n'utilise pas ROW_FORMAT = DYNAMIC, le nouvel espace de table qui contient la table est marqué comme utilisant le format de fichier Antelope.

Ainsi, les tables seront créées en tant qu'antilope même si vous autorisez Barracuda. Le mélange est inévitable, sauf si vous spécifiez chaque table comme dynamique row_format ou une table compressée.

Il n'y a aucune indication que vous devriez faire un vidage complet et recharger lors de l'introduction de votre première table Barracuda (comme cela est recommandé lors de la mise à niveau des principales versions de mysql )

atxdba
la source

Réponses:

18

Je réponds donc à cette question avec près de 4 ans de retard:

  • Les formats de fichiers InnoDB ont été conçus à une époque où InnoDB était indépendant du serveur MySQL (par exemple: MySQL 5.1 pouvait exécuter deux versions différentes d'InnoDB).

  • La raison pour laquelle vous ne voudriez pas exécuter Barracuda (en 2012) est que cela pourrait réduire la flexibilité dans la rétrogradation de MySQL (c'est-à-dire qu'après une mise à niveau échouée, vous souhaitez revenir à une version qui ne peut pas lire un format plus récent). c'est-à-dire qu'il ne devrait pas y avoir de raisons techniques pour lesquelles Antelope est meilleure.

  • Dans MySQL 5.7, l' innodb_file_formatoption était obsolète. Étant donné que MySQL et InnoDB ne sont plus indépendants, InnoDB peut donc utiliser les règles de mise à niveau MySQL et la compatibilité descendante requise. Aucun réglage déroutant requis!

  • Dans MySQL 5.7, la valeur par défaut est passée à Barracuda/DYNAMIC. Étant donné que toutes les versions actuellement prises en charge de MySQL peuvent lire ce format, il est sûr de s'éloigner d'Antelope et de continuer à proposer une mise à niveau inférieure.

  • Sur un serveur MySQL 5.7, les tables Antelope seront mises à niveau vers Barracuda/DYNAMICla prochaine reconstruction de table (OPTIMIZE TABLE, etc.). C'est à moins qu'ils n'aient été spécifiquement créés avec ROW_FORMAT=oldrowformat.

  • Dans MySQL 8.0, l'option innodb_file_formatest supprimée.


MySQL 5.7 introduit également l'optioninnodb_default_row_format , qui est par défaut DYNAMIC. Cela répond au point de votre mise à jour.

Morgan Tocker
la source
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)
Gopinath
la source
9

Si vous voulez vraiment jouer avec InnoDB en utilisant le format Barracuda, vous devez tout mysqldumper quelque chose comme /root/MySQLData.sql. Cela rend le format de fichier de données indépendant.

Utilisez une autre instance MySQL avec un nouveau ibdata1 et innodb_file_per_table (facultatif, ma préférence personnelle). Modifiez le format de fichier avec ibdata1 vide. Ensuite, rechargez /root/MySQLData.sql et jouez avec les données.

J'ai entendu de légères histoires d'horreur à propos de PostgreSQL devant modifier les paramètres pour faire fonctionner une base de données 8.2.4 avec des binaires 9.0.1. La même histoire pourrait s'appliquer si nous essayions de faire en sorte que les deux formats de fichier résident dans le même espace de table système (ibdata1) et / ou .ibdfichier si nous connaissons de tels paramètres.

Pour être casher ...

  • Personne ne devrait conserver la viande et les produits laitiers dans le même réfrigérateur
  • Personne ne devrait mettre un taureau et un âne sous le même joug (Deutéronome 22:10)
  • Personne ne devrait stocker Antelopeet Barracudaà l'intérieur du même ibdata1

MISE À JOUR 2013-07-05 14:26 EDT

Je viens de répondre à cette question dans ServerFault: Définition de la compression MySQL INNODB KEY_BLOCK_SIZE . Cela m'a fait revenir en arrière pour toutes les questions auxquelles j'ai répondu dans le DBA StackExchange avait discuté du Barracudaformat et j'ai trouvé mon ancien poste. Je vais placer les mêmes informations ici ...

Selon la documentation MySQL sur la compression InnoDB pour Barracuda

Compression et pool de tampons InnoDB

Dans une table InnoDB compressée, chaque page compressée (qu'elle soit 1K, 2K, 4K ou 8K) correspond à une page non compressée de 16K octets. Pour accéder aux données d'une page, InnoDB lit la page compressée à partir du disque si elle n'est pas déjà dans le pool de mémoire tampon, puis décompresse la page dans sa forme d'origine de 16 Ko. Cette section décrit comment InnoDB gère le pool de tampons par rapport aux pages des tables compressées.

Pour minimiser les E / S et réduire la nécessité de décompresser une page, le pool de tampons contient parfois à la fois la forme compressée et non compressée d'une page de base de données. Pour faire de la place aux autres pages de base de données requises, InnoDB peut «expulser» du pool de tampons une page non compressée, tout en laissant la page compressée en mémoire. Ou, si une page n'a pas été consultée depuis un certain temps, la forme compressée de la page peut être écrite sur le disque, pour libérer de l'espace pour d'autres données. Ainsi, à tout moment, le pool de mémoire tampon peut contenir à la fois les formes compressées et non compressées de la page, ou uniquement la forme compressée de la page, ou ni l'un ni l'autre.

InnoDB garde une trace des pages à conserver en mémoire et de celles à supprimer en utilisant une liste LRU (moins récemment utilisée), de sorte que les données «chaudes» ou fréquemment consultées ont tendance à rester en mémoire. Lors de l'accès aux tables compressées, InnoDB utilise un algorithme LRU adaptatif pour obtenir un équilibre approprié des pages compressées et non compressées en mémoire. Cet algorithme adaptatif est sensible au fait que le système fonctionne de manière liée aux E / S ou au processeur. Le but est d'éviter de passer trop de temps de traitement à décompresser les pages lorsque le CPU est occupé, et d'éviter de faire des E / S excessives lorsque le CPU a des cycles de rechange qui peuvent être utilisés pour décompresser des pages compressées (qui peuvent déjà être en mémoire). Lorsque le système est lié aux E / S, l'algorithme préfère expulser la copie non compressée d'une page plutôt que les deux copies, pour faire plus de place pour que les autres pages du disque deviennent résidentes en mémoire. Lorsque le système est lié au processeur, InnoDB préfère expulser à la fois la page compressée et la page non compressée, afin que davantage de mémoire puisse être utilisée pour les pages «chaudes» et réduisant le besoin de décompresser les données en mémoire uniquement sous forme compressée.

Notez que le pool de tampons InnoDB doit charger les pages de données et les pages d'index lues pour répondre aux requêtes. Lors de la première lecture d'une table et de ses index, la page compressée doit être décompressée à 16 Ko. Cela signifie que vous aurez deux fois plus de contenu de données dans le pool de mémoire tampon, la page de données compressée et non compressée.

Si cette duplication du contenu des données se produit dans le pool de tampons, vous devez augmenter innodb_buffer_pool_size d'un petit facteur linéaire du nouveau taux de compression. Voici comment:

SCÉNARIO

  • Vous avez un serveur DB avec un pool de tampons 8G
  • Vous avez exécuté la compression avec key_block_size=8
    • 8est 50.00%de16
    • 50.00%de 8Gest -4G
    • augmenter innodb_buffer_pool_sizeà 12G( 8G+ 4G)
  • Vous avez exécuté la compression avec key_block_size=4
    • 4est 25.00%de16
    • 25.00%de 8Gest -2G
    • augmenter innodb_buffer_pool_sizeà 10G( 8G+ 2G)
  • Vous avez exécuté la compression avec key_block_size=2
    • 2est 12.50%de16
    • 12.50%de 8Gest -1G
    • augmenter innodb_buffer_pool_sizeà 9G( 8G+ 1G)
  • Vous avez exécuté la compression avec key_block_size=1
    • 1est 06.25%de16
    • 06.25%de 8Gis 0.5G( 512M)
    • augmenter innodb_buffer_pool_sizeà 8704M( 8G( 8192M) + 512M)

MORAL DE L'HISTOIRE : Le pool de tampons InnoDB a juste besoin de plus d'espace pour respirer lors de la manipulation des données compressées et des pages d'index.

RolandoMySQLDBA
la source