innodb_file_format Barracuda


25

У мене є кілька запитань для тих, хто більше знайомий. Більшість моїх примірників працювали над антилопою, незважаючи на те, що вони мали підтримку Barracuda.

Я дивився, щоб пограти з деякими компресами в таблицях. Я розумію, що це доступно лише у форматі Barracuda.

  1. Я бачу, що innodb_file_format є динамічним, тому я можу просто переключитися з відмов. Чи мають бути якісь наслідки цього, я повинен знати. Все, що я можу сказати, - це означає, що нові таблиці або згодом змінені будуть створені з цим форматом. Це все правильно?
  2. Я сподівався, що мені доведеться не переглядати та конвертувати всі мої таблиці. Чи кошерно існувати таблиці антилоп і барракуд в одному і тому ж просторі таблиць? Навіть якщо це працює, чи є на що слід звертати увагу?

З того, що я прочитав і зібрав з моїх тестів, відповіді такі: Так. Так. Я не впевнений.

Оновлення

Я працював з / з динамічними та деякими стислими таблицями в різних випадках, починаючи з цієї публікації з випуском. Далі я знехтував читати http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html у той час.

Після ввімкнення заданого innodb_file_format ця зміна стосується лише новостворених таблиць, а не існуючих. Якщо ви створюєте нову таблицю, простір таблиць, що містять таблицю, позначається "найдавнішим" або "найпростішим" форматом файлів, необхідним для функцій таблиці. Наприклад, якщо увімкнути формат файлу Barracuda та створити нову таблицю, яка не стискається і не використовує ROW_FORMAT = DYNAMIC, новий простір таблиць, який містить таблицю, позначається як використання файлового формату "Антилопа".

Тож таблиці будуть створені як антилопа, навіть якщо ви дозволите Barracuda. Змішування неминуче, якщо ви не вказали кожну таблицю як динамічний рядок_формату або стиснуту таблицю.

Немає вказівки, що ви повинні робити повний дамп і перезавантажуватись, представляючи свою першу таблицю Barracuda (наприклад, рекомендується під час оновлення основних версій mysql )

Відповіді:


18

Тож я відповідаю на це запитання майже на 4 роки:

  • Формати файлів InnoDB були задумані в той час, коли InnoDB був незалежним від MySQL Server (наприклад: MySQL 5.1 міг запускати дві різні версії InnoDB).

  • Причина, чому ви не хочете запускати Barracuda (у 2012 році), полягає в тому, що це може зменшити гнучкість при зниженні рівня MySQL (тобто після невдалого оновлення, ви хочете перейти до версії, яка не може прочитати новіший формат). тобто не повинно бути технічних причин, чому антилопа краща.

  • У MySQL 5.7 innodb_file_formatпараметр був застарілий. Оскільки MySQL та InnoDB більше не залежать, і тому InnoDB може використовувати правила оновлення MySQL та необхідну сумісність назад. Не потрібно заплутати налаштування!

  • У MySQL 5.7 за замовчуванням переключено на Barracuda/DYNAMIC. Оскільки всі підтримувані в даний час версії MySQL можуть читати цей формат, це безпечно відійти від антилопи і все ще пропонувати пониження рівня.

  • На сервері MySQL 5.7 таблиці антилоп буде оновлено до Barracuda/DYNAMICвідновлення наступної таблиці (OPTIMIZE TABLE тощо). Тобто, якщо вони спеціально не створені ROW_FORMAT=oldrowformat.

  • У MySQL 8.0 параметр innodb_file_formatвидалено.


MySQL 5.7 також вводить опціюinnodb_default_row_format , яка за замовчуванням DYNAMIC. Це стосується точки вашого оновлення.


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

Якщо ви дійсно хочете грати з InnoDB у форматі Barracuda, вам слід mysqldпередати все на щось на кшталт /root/MySQLData.sql. Це робить формат файлу даних незалежним.

Використовуйте інший екземпляр MySQL зі свіжими ibdata1 та innodb_file_per_table (необов’язково, мої особисті переваги). Змініть формат файлу з ibdata1 порожнім. Потім перезавантажте /root/MySQLData.sql і пограйте з даними.

Я чув невеликі історії жахів про PostgreSQL, який повинен змінити налаштування, щоб отримати базу даних 8.2.4 для роботи з 9.0.1 бінарними файлами. Ця ж історія може бути застосована, якщо ми намагалися зробити так, щоб обидва формати файлів перебували в одному і тому ж системному просторі таблиць (ibdata1) та / або.ibd файлі, якщо нам відомо про такі налаштування.

Що стосується кошерності ...

  • Ніхто не повинен зберігати м’ясо та молочні продукти в одному холодильнику
  • Ніхто не повинен класти бика і осла під одне ярмо (Второзаконня 22:10)
  • Ніхто не повинен зберігати Antelopeі Barracudaвсередині того самого ibdata1

ОНОВЛЕННЯ 2013-07-05 14:26 EDT

Я щойно відповів на це питання в ServerFault: Встановлення MySQL INNODB Compression KEY_BLOCK_SIZE . Це змусило мене озирнутися на будь-які запитання, на які я відповів у обговоренні StackExchange DBABarracuda формат, і я знайшов цю стару посаду. Я розміщу ту саму інформацію тут ...

Відповідно до Документації MySQL щодо стиснення InnoDB для Barracuda

Стиснення та буферний пул InnoDB

У стислій таблиці InnoDB кожна стисла сторінка (будь то 1 К, 2 К, 4 К або 8 К) відповідає нестисненій сторінці 16 К байт. Щоб отримати доступ до даних на сторінці, InnoDB зчитує стиснуту сторінку з диска, якщо вона вже не знаходиться в буферному пулі, а потім розтискає сторінку до її початкової 16-байтної форми байтів. У цьому розділі описано, як InnoDB управляє пулом буфера щодо сторінок стислих таблиць.

Щоб мінімізувати введення-виведення та зменшити необхідність розпакування сторінки, буферний пул іноді містить як стиснуту, так і нестиснуту форму сторінки бази даних. Щоб звільнити місця для інших необхідних сторінок бази даних, InnoDB може "виселити" з буферного пулу нестиснену сторінку, залишаючи стиснуту сторінку в пам'яті. Або якщо сторінка не була доступна протягом певного часу, стиснута форма сторінки може бути записана на диск, щоб звільнити місце для інших даних. Таким чином, в будь-який момент часу буферний пул може містити як стиснуті, так і нестиснуті форми сторінки, або лише стиснуту форму сторінки, або жодну.

InnoDB відслідковує, які сторінки зберігати в пам’яті, а які вилучати, використовуючи найменш використовуваний останній (LRU) список, так що «гарячі» або часто доступні дані мають тенденцію залишатися в пам'яті. Під час доступу до стислих таблиць InnoDB використовує адаптивний алгоритм LRU для досягнення відповідного балансу стислих та нестиснених сторінок у пам'яті. Цей адаптивний алгоритм чутливий до того, чи працює система в режимі, пов'язаному з входом / виводом або процесором. Мета полягає в тому, щоб не витрачати занадто багато часу на обробку розтиснення сторінок, коли процесор зайнятий, і уникнути зайвого вводу / виводу, коли у процесора є запасні цикли, які можна використовувати для розтиснення стислих сторінок (які вже можуть бути в пам'яті). Коли система пов'язана з входом / виводом, алгоритм вважає за краще вилучати нестиснену копію сторінки, а не обидві копії, щоб більше місця для інших сторінок диска стали резидентом пам'яті. Коли система пов'язана з процесором, InnoDB вважає за краще вилучати як стиснуту, так і нестиснуту сторінку, щоб більше пам'яті можна було використовувати для «гарячих» сторінок і зменшувало потребу в розпакуванні даних у пам'яті лише у стисненому вигляді.

Зауважте, що буферний пул InnoDB повинен завантажувати сторінки даних та сторінки покажчиків, прочитані для виконання запитів. При першому читанні таблиці та її індексів стиснута сторінка повинна бути нестиснутою до 16K. Це означає, що ви будете мати вдвічі більше вмісту даних у буферному пулі, на стисненій та нестисненій сторінці даних.

Якщо це дублювання вмісту даних відбувається в буферному пулі, вам потрібно збільшити розмір innodb_buffer_pool_size невеликим лінійним коефіцієнтом нової швидкості стиснення. Ось як:

СЦЕНАРІО

  • У вас є сервер DB з буфером 8G
  • Ви виконали компресію за допомогою key_block_size=8
    • 8є 50.00%з16
    • 50.00%з 8Gє4G
    • підвищити innodb_buffer_pool_sizeдо 12G( 8G+ 4G)
  • Ви виконали компресію за допомогою key_block_size=4
    • 4є 25.00%з16
    • 25.00%з 8Gє2G
    • підвищити innodb_buffer_pool_sizeдо 10G( 8G+ 2G)
  • Ви виконали компресію за допомогою key_block_size=2
    • 2є 12.50%з16
    • 12.50%з 8Gє1G
    • підвищити innodb_buffer_pool_sizeдо 9G( 8G+ 1G)
  • Ви виконали компресію за допомогою key_block_size=1
    • 1є 06.25%з16
    • 06.25%з 8Gє 0.5G( 512M)
    • підвищити innodb_buffer_pool_sizeдо 8704M( 8G( 8192M) + 512M)

МОРАЛ ІСТОРІЇ : Буфер InnoDB просто потребує додаткового приміщення для дихання для обробки стислих даних та індексних сторінок.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.