innodb_file_format Barracuda

Question

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.

Je vois que innodb_file_format est dynamique, donc je peux simplement basculer sans rebond. Y a-t-il des implications de faire cela, 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?
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 exécuté avec des tables dynamiques et 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é un innodb_file_format donné, 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é lorsque mise à niveau des versions majeures de mysql )

Morgan Tocker · Accepted Answer

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'option innodb_file_format Était déconseillée. É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 de MySQL actuellement prises en charge peuvent lire ce format, il est prudent 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/DYNAMIC Lors de la 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_format Est supprimée.

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

Gopinath · Answer

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)

RolandoMySQLDBA · Answer

Si vous voulez vraiment jouer avec InnoDB en utilisant le format Barracuda, vous devez tout mysqldump dans 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 fichiers résident dans le même espace de table système (ibdata1) et/ou .ibd fichier si nous connaissons ces 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 doit stocker Antelope et Barracuda dans le 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 regarder en arrière pour toutes les questions auxquelles j'ai répondu dans le DBA StackExchange avait discuté du format Barracuda 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 en ce qui concerne les pages des tables compressées.

Pour minimiser les E/S et réduire le besoin de décompresser une page, le pool de tampons contient parfois 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 s'exécute d'une manière liée aux E/S ou liée 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 laisser plus d'espace aux autres pages de disque pour qu'elles résident 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 de le 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
- 8 est 50.00% de 16
- 50.00% de 8G est 4G
- élever innodb_buffer_pool_size à 12G (8G + 4G)
Vous avez exécuté la compression avec key_block_size=4
- 4 est 25.00% de 16
- 25.00% de 8G est 2G
- élever innodb_buffer_pool_size à 10G (8G + 2G)
Vous avez exécuté la compression avec key_block_size=2
- 2 est 12.50% de 16
- 12.50% de 8G est 1G
- élever innodb_buffer_pool_size à 9G (8G + 1G)
Vous avez exécuté la compression avec key_block_size=1
- 1 est 06.25% de 16
- 06.25% de 8G est 0.5G (512M)
- élever 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.