innodb_file_format Barracuda


25

Mam kilka pytań do tych bardziej znanych. Większość moich instancji prowadzi Antylopę pomimo wsparcia dla Barracudy.

Chciałem się pobawić przy kilku kompresujących tabelach innodb. Rozumiem, że jest to dostępne tylko w formacie Barracuda.

  1. Widzę, że innodb_file_format jest dynamiczny, więc mogę po prostu przełączyć się bez odbicia. Czy są jakieś konsekwencje takiego postępowania, o których powinienem wiedzieć. Wszystko, co mogę powiedzieć, to znaczy, że nowe tabele lub później zmienione zostaną utworzone w tym formacie. Czy to wszystko jest poprawne?
  2. Miałem nadzieję, że nie będę musiał przechodzić i konwertować wszystkich moich tabel. Czy koszerne jest współistnienie tabel antylopy i barracudy w tym samym obszarze tabel? Nawet jeśli to działa, czy jest coś, na co trzeba uważać?

Z tego, co przeczytałem i zebrałem z moich testów, odpowiedzi są następujące: Tak. Tak. Nie jestem pewny.

Aktualizacja

Od czasu opublikowania tego postu działam z kilkoma tabelami Dynamic i Compressed w różnych przypadkach. Ponadto zaniedbałem wówczas czytanie http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html .

Po włączeniu danego formatu pliku_wnodb ta zmiana dotyczy tylko nowo utworzonych tabel, a nie istniejących. Jeśli utworzysz nową tabelę, obszar tabel zawierający tabelę zostanie oznaczony „najwcześniejszym” lub „najprostszym” formatem pliku, który jest wymagany dla funkcji tabeli. Na przykład, jeśli włączysz format pliku Barracuda i utworzysz nową tabelę, która nie jest skompresowana i nie używa ROW_FORMAT = DYNAMIC, nowy obszar tabel zawierający tabelę zostanie oznaczony jako wykorzystujący format pliku Antelope.

Tabele zostaną utworzone jako Antylopa, nawet jeśli zezwolisz na Barracuda. Mieszanie jest nieuniknione, chyba że określisz każdą tabelę jako dynamiczną format wiersza lub tabelę skompresowaną.

Nic nie wskazuje na to, że powinieneś zrobić pełny zrzut i przeładować, wprowadzając swoją pierwszą tabelę Barracuda (takie jak jest zalecane podczas aktualizacji głównych wersji mysql )

Odpowiedzi:


18

Odpowiadam więc na to pytanie prawie 4 lata później:

  • Formaty plików InnoDB powstały w czasie, gdy InnoDB był niezależny od serwera MySQL (na przykład: MySQL 5.1 mógł uruchamiać dwie różne wersje InnoDB).

  • Powodem, dla którego nie chcesz uruchamiać Barracudy (w 2012 r.), Jest to, że może to zmniejszyć elastyczność obniżania wersji MySQL (tzn. Po nieudanej aktualizacji chcesz wrócić do wersji, która nie może odczytać nowszego formatu). tzn. nie powinno być technicznych powodów, dla których Antelope jest lepsza.

  • W MySQL 5.7 innodb_file_formatopcja była przestarzała. Ponieważ MySQL i InnoDB nie są już niezależne, dlatego InnoDB może korzystać z zasad aktualizacji MySQL i wymaganej kompatybilności wstecznej. Nie jest wymagane mylące ustawienie!

  • W MySQL 5.7 domyślnie zmieniono na Barracuda/DYNAMIC. Ponieważ wszystkie obecnie obsługiwane wersje MySQL mogą czytać ten format, można bezpiecznie odejść od Antelope i nadal oferować obniżenie wersji.

  • Na serwerze MySQL 5.7 tabele Antelope zostaną zaktualizowane do Barracuda/DYNAMICnastępnej odbudowy tabeli (OPTYMALIZACJA TABELI itp.). To znaczy, chyba że zostały specjalnie stworzone ROW_FORMAT=oldrowformat.

  • W MySQL 8.0 opcja innodb_file_formatjest usunięta.


MySQL 5.7 wprowadza również opcjęinnodb_default_row_format domyślnie DYNAMIC. Dotyczy to punktu Twojej aktualizacji.


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)

9

Jeśli naprawdę chcesz grać z InnoDB w formacie Barracuda, powinieneś wszystko mysqldump zrobić do czegoś takiego jak /root/MySQLData.sql. To sprawia, że ​​format pliku danych jest niezależny.

Użyj innej instancji MySQL ze świeżym ibdata1 i innodb_file_per_table (opcjonalnie, moje osobiste preferencje). Zmień format pliku z pustym ibdata1. Następnie ponownie załaduj /root/MySQLData.sql i baw się danymi.

Słyszałem lekkie horrory o tym, że PostgreSQL musi dostosować ustawienia, aby baza danych 8.2.4 działała z plikami binarnymi 9.0.1. Ta sama historia mogłaby mieć zastosowanie, gdybyśmy próbowali umieścić oba formaty plików w tym samym systemowym obszarze tabel (ibdata1) i / lub .ibdpliku, jeśli znamy takie ustawienia.

Jeśli chodzi o koszerność ...

  • Nikt nie powinien przechowywać mięsa i nabiału w tej samej lodówce
  • Nikt nie powinien umieszczać byka i osła pod tym samym jarzmem (Powtórzonego Prawa 22:10)
  • Nikt nie powinien przechowywać Antelopei Barracudawewnątrz samego ibdata1

AKTUALIZACJA 2013-07-05 14:26 EDT

Właśnie odpowiedziałem na to pytanie w ServerFault: Ustawienie kompresji MySQL INNODB KEY_BLOCK_SIZE . To sprawiło, że spojrzałem wstecz na wszelkie pytania, na które odpowiedziałem w DBA StackExchange omawiał Barracudaformat i znalazłem ten mój stary post. Podam te same informacje tutaj ...

Według dokumentacji MySQL na temat kompresji InnoDB dla Barracudy

Kompresja i pula buforów InnoDB

W skompresowanej tabeli InnoDB każda skompresowana strona (1K, 2K, 4K lub 8K) odpowiada nieskompresowanej stronie o wielkości 16 KB. Aby uzyskać dostęp do danych na stronie, InnoDB odczytuje skompresowaną stronę z dysku, jeśli nie znajduje się ona jeszcze w puli buforów, a następnie rozpakowuje stronę do oryginalnej postaci bajtu 16 KB. W tej sekcji opisano, w jaki sposób InnoDB zarządza pulą buforów w odniesieniu do stron skompresowanych tabel.

Aby zminimalizować operacje we / wy i zmniejszyć potrzebę rozpakowywania strony, czasami pula buforów zawiera zarówno skompresowaną, jak i nieskompresowaną formę strony bazy danych. Aby zrobić miejsce dla innych wymaganych stron bazy danych, InnoDB może „eksmitować” z puli buforów stronę nieskompresowaną, pozostawiając skompresowaną stronę w pamięci. Lub, jeśli strona nie była dostępna przez jakiś czas, skompresowana forma strony może zostać zapisana na dysku, aby zwolnić miejsce na inne dane. Zatem w dowolnym momencie pula buforów może zawierać zarówno skompresowane, jak i nieskompresowane formy strony, lub tylko skompresowaną formę strony, lub żadną.

InnoDB śledzi, które strony zachować w pamięci, a które eksmitować, korzystając z listy ostatnio używanych (LRU), dzięki czemu „gorące” lub często używane dane mają tendencję do pozostawania w pamięci. Podczas uzyskiwania dostępu do skompresowanych tabel InnoDB używa algorytmu adaptacyjnego LRU, aby osiągnąć odpowiednią równowagę skompresowanych i nieskompresowanych stron w pamięci. Ten algorytm adaptacyjny jest wrażliwy na to, czy system działa w sposób związany z operacjami we / wy lub procesorem. Celem jest uniknięcie nadmiernego czasu przetwarzania stron na kompresję, gdy procesor jest zajęty, oraz unikanie nadmiernego wykonywania operacji we / wy, gdy procesor ma wolne cykle, które można wykorzystać do rozpakowywania skompresowanych stron (które mogą już znajdować się w pamięci). Gdy system jest powiązany z operacjami we / wy, algorytm woli eksmitować nieskompresowaną kopię strony, a nie obie kopie, aby zrobić więcej miejsca dla innych stron dysku, aby stały się rezydentami pamięci. Gdy system jest związany z procesorem, InnoDB woli eksmitować zarówno skompresowaną, jak i nieskompresowaną stronę, aby więcej pamięci można było wykorzystać na „gorące” strony i zmniejszyć potrzebę dekompresji danych w pamięci tylko w postaci skompresowanej.

Zauważ, że pula buforów InnoDB musi ładować strony danych i czytać strony indeksowe w celu wypełnienia zapytań. Podczas czytania tabeli i jej indeksów po raz pierwszy skompresowana strona musi być rozpakowana do 16 KB. Oznacza to, że będziesz mieć dwa razy więcej danych w puli buforów, na skompresowanej i nieskompresowanej stronie danych.

Jeśli duplikacja zawartości danych ma miejsce w puli buforów, musisz zwiększyć innodb_buffer_pool_size o mały współczynnik liniowy nowego współczynnika kompresji. Oto jak:

SCENARIUSZ

  • Masz serwer DB z pulą buforów 8G
  • Uruchomiłeś kompresję z key_block_size=8
    • 8jest 50.00%z16
    • 50.00%z 8Gjest4G
    • podnieść innodb_buffer_pool_sizedo 12G( 8G+ 4G)
  • Uruchomiłeś kompresję z key_block_size=4
    • 4jest 25.00%z16
    • 25.00%z 8Gjest2G
    • podnieść innodb_buffer_pool_sizedo 10G( 8G+ 2G)
  • Uruchomiłeś kompresję z key_block_size=2
    • 2jest 12.50%z16
    • 12.50%z 8Gjest1G
    • podnieść innodb_buffer_pool_sizedo 9G( 8G+ 1G)
  • Uruchomiłeś kompresję z key_block_size=1
    • 1jest 06.25%z16
    • 06.25%z 8Gjest 0.5G( 512M)
    • podnieś innodb_buffer_pool_sizedo 8704M( 8G( 8192M) + 512M)

MORAL OF THE STORY : Pula buforowa InnoDB potrzebuje tylko dodatkowego oddechu podczas obsługi skompresowanych danych i stron indeksowych.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.