it-swarm-eu.dev

innodb_file_format Barracuda

Mám pár otázek pro ty známé. Většina mých příkladů byla spuštěna antilopa, přestože jsem měl podporu pro Barracudu.

Chtěl jsem si pohrávat s některými komprimovanými tabulkami. Chápu, že je to dostupné pouze ve formátu Barracuda.

  1. Vidím, že innodb_file_format je dynamický, takže se mohu přepnout bez odrazu. Měl bych si být vědom toho, že to dělám. Všechno, co můžu říct, je to, že v tomto formátu budou vytvořeny nové tabulky nebo následně změněné. Je to všechno správné?
  2. Doufal jsem, že nebudu muset projít a převést všechny mé tabulky. Je košer mít anttelope a barracude tabulky koexistující ve stejném tabulkovém prostoru? I když je to funguje, musíš si dát nějaké pozor?

Z toho, co jsem četl a shromáždil z mých testů, jsou odpovědi: Ano. Ano. Nejsem si jistý.

Aktualizace

Od tohoto příspěvku jsem běžel bez dynamických a komprimovaných tabulek v různých případech. Dále jsem opomněl číst http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html v té době.

Po povolení daného innodb_file_format se tato změna týká pouze nově vytvořených tabulek, nikoli existujících. Pokud vytvoříte novou tabulku, je tabulkový prostor obsahující tabulku označen formátem „nejdříve“ nebo „nejjednodušší“, který je vyžadován pro funkce tabulky. Pokud například povolíte formát souboru Barracuda a vytvoříte novou tabulku, která není komprimována a nepoužívá ROW_FORMAT = DYNAMIC, bude nový tabulkový prostor, který tabulku obsahuje, označen jako formát souboru Antelope.

Takže tabulky budou vytvořeny jako antilopa, i když povolíte Barracuda. Míchání je nevyhnutelné, pokud neurčíte každou tabulku jako dynamickou řádku nebo komprimovanou tabulku.

Neexistuje žádný náznak, že byste měli provést kompletní výpis a znovu načíst při představování vaší první tabulky Barracuda (jako je doporučeno, když pgrade hlavních verzí mysql )

28
atxdba

Takže odpovídám na tuto otázku téměř 4 roky pozdě:

  • Formáty souborů InnoDB byly vytvořeny v době, kdy byl InnoDB nezávislý na serveru MySQL (například: MySQL 5.1 může spouštět dvě různé verze InnoDB).

  • Důvodem, proč byste nechtěli spustit Barracuda (v roce 2012), je to, že by to mohlo snížit flexibilitu při downgradování MySQL (tj. Po neúspěšné aktualizaci se chcete vrátit zpět do verze, která neumí číst novější formát). tj. neměly by existovat žádné technické důvody, proč je antilopa lepší.

  • V MySQL 5.7 byla volba innodb_file_format Zamítnuta. Protože MySQL a InnoDB již nejsou nezávislé, a proto InnoDB může používat pravidla MySQL upgradů a to, co se vyžaduje zpětná kompatibilita. Není třeba matoucí nastavení!

  • V MySQL 5.7 byl výchozí přepnut na Barracuda/DYNAMIC. Protože všechna aktuálně podporovaná vydání MySQL mohou tento formát číst, je bezpečné se vzdálit od antilopy a stále nabízet downgrade.

  • Na serveru MySQL 5.7 budou tabulky Antelope upgradovány na Barracuda/DYNAMIC Při příští rekonstrukci tabulky (OPTIMIZE TABLE atd.). To je, pokud nebyly vytvořeny konkrétně pomocí ROW_FORMAT=oldrowformat.

  • V MySQL 8.0 je odebrána možnost innodb_file_format.


MySQL 5.7 také zavádí možnost innodb_default_row_format , která je standardně nastavena na DYNAMIC. Tím se řeší bod v aktualizaci.

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

Pokud opravdu chcete hrát s InnoDB ve formátu Barracuda, měli byste mysqldump všechno na něco jako /root/MySQLData.sql. Díky tomu je formát datového souboru nezávislý.

Použijte jinou instanci MySQL s čerstvým ibdata1 a innodb_file_per_table (volitelné, moje osobní preference). Změňte formát souboru s prázdným ibdata1. Poté znovu načtěte /root/MySQLData.sql a hrajte si s daty.

Slyšel jsem mírné hororové příběhy o PostgreSQL, které musím udělat, abych získal databázi 8.2.4 pro práci s binárními soubory 9.0.1. Stejný příběh by mohl platit, pokud bychom se pokusili, aby oba formáty souborů byly umístěny ve stejném systémovém tabulkovém prostoru (ibdata1) a/nebo .ibd soubor, pokud víme o takovém nastavení.

Pokud jde o košer ...

  • Nikdo by neměl skladovat maso a mléčné výrobky ve stejné lednici
  • Nikdo by neměl dávat býka a osla do stejného jho (Deuteronomy 22:10)
  • Nikdo by neměl ukládat Antelope a Barracuda uvnitř stejného ibdata1

AKTUALIZACE 2013-07-05 14:26 EDT

Právě jsem na tuto otázku odpověděl v ServerFault: Nastavení komprese MySQL INNODB KEY_BLOCK_SIZE . To mě přimělo ohlédnout se na jakékoli otázky, na které jsem odpověděl ve formátu DBA StackExchange, o diskuzi formátu Barracuda a našel jsem tento starý příspěvek. Zde umístím stejné informace ...

Podle dokumentace MySQL o InnoDB kompresi pro Barracuda

Komprese a fond vyrovnávacích pamětí InnoDB

V komprimované tabulce InnoDB odpovídá každá komprimovaná stránka (ať už 1 kB, 2 kB, 4 kB nebo 8 kB) nekomprimované stránce o velikosti 16 kB. Chcete-li získat přístup k datům na stránce, přečte InnoDB komprimovanou stránku z disku, pokud již není ve fondu vyrovnávacích pamětí, a poté stránku dekomprimuje do svého původního 16 kB bytového formuláře. Tato část popisuje, jak InnoDB spravuje fond vyrovnávacích pamětí s ohledem na stránky komprimovaných tabulek.

Aby se minimalizoval vstup/výstup a snížila potřeba dekomprimovat stránku, občas fond vyrovnávacích pamětí obsahuje komprimovanou i nekomprimovanou formu databázové stránky. Aby InnoDB uvolnil místo pro další požadované databázové stránky, může „vypudit“ z oblasti vyrovnávacích pamětí nekomprimovanou stránku, zatímco komprimovanou stránku ponechá v paměti. Nebo, pokud stránka nebyla přístupná po určitou dobu, komprimovaná forma stránky může být zapsána na disk, aby se uvolnilo místo pro jiná data. V každém daném okamžiku tedy může oblast vyrovnávacích pamětí obsahovat jak komprimované, tak nekomprimované formy stránky, nebo pouze komprimovanou formu stránky, nebo žádnou.

InnoDB sleduje, které stránky mají být uloženy v paměti a které se mají vyhnout pomocí seznamu naposledy použitých (LRU), takže „horká“ nebo často přístupná data mají tendenci zůstat v paměti. Při přístupu ke komprimovaným tabulkám používá InnoDB adaptivní algoritmus LRU k dosažení odpovídajícího vyvážení komprimovaných a nekomprimovaných stránek v paměti. Tento adaptivní algoritmus je citlivý na to, zda systém běží způsobem vázaným na V/V nebo CPU. Cílem je vyhnout se zbytečnému zpracování času nekomprimováním stránek, když je CPU zaneprázdněno, a zabránit zbytečnému I/O, když má CPU náhradní cykly, které lze použít pro nekomprimování komprimovaných stránek (které již mohou být v paměti). Když je systém vázán na V/V, algoritmus upřednostňuje vypudit nekomprimovanou kopii stránky, a ne obě kopie, aby vytvořil více prostoru pro další stránky na disku, aby se staly rezidentními. Když je systém vázán na CPU, InnoDB upřednostňuje vypudit komprimovanou i nekomprimovanou stránku, takže pro „horké“ stránky lze použít více paměti a snížit potřebu nekomprimovat data v paměti pouze v komprimované formě.

Všimněte si, že fond vyrovnávacích pamětí InnoDB musí načítat datové stránky a indexové stránky načtené, aby splnily dotazy. Při prvním čtení tabulky a jejích indexů musí být komprimovaná stránka nekomprimována na 16 kB. To znamená, že budete mít dvakrát tolik datového obsahu ve fondu vyrovnávacích pamětí, komprimované a nekomprimované datové stránce.

Pokud tato duplikace datového obsahu probíhá ve fondu vyrovnávacích pamětí, musíte zvýšit innodb_buffer_pool_size malým lineárním faktorem nová míra komprese. Zde je návod:

SCÉNÁŘ

  • Máte DB server s 8G vyrovnávací pamětí
  • Spustili jste kompresi s key_block_size=8
    • 8 je 50.00% z 16
    • 50.00% z 8G je 4G
    • vyzdvihnout innodb_buffer_pool_size to 12G (8G + 4G)
  • Spustili jste kompresi s key_block_size=4
    • 4 je 25.00% z 16
    • 25.00% z 8G je 2G
    • vyzdvihnout innodb_buffer_pool_size to 10G (8G + 2G)
  • Spustili jste kompresi s key_block_size=2
    • 2 je 12.50% z 16
    • 12.50% z 8G je 1G
    • vyzdvihnout innodb_buffer_pool_size to 9G (8G + 1G)
  • Spustili jste kompresi s key_block_size=1
    • 1 je 06.25% z 16
    • 06.25% z 8G je 0.5G (512M)
    • vyzdvihnout innodb_buffer_pool_size to 8704M (8G (8192M) + 512M)

MORÁL PŘÍBĚRU : InnoDB Buffer Pool potřebuje jen další dýchací místnost, když pracuje se komprimovanými daty a indexovými stránkami.

9
RolandoMySQLDBA