innodb_file_format Barracuda


25

У меня есть пара вопросов для более знакомых. Большинство моих инстансов работали с «Антилопой», несмотря на то, что они поддерживали Барракуда.

Я искал, чтобы поиграть с некоторыми компрессами innodb таблиц. Насколько я понимаю, это доступно только в формате 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, новое табличное пространство, содержащее таблицу, будет помечено как использующее формат файла Antelope.

Таким образом, таблицы будут созданы как антилопы, даже если вы разрешите Barracuda. Смешивание неизбежно, если вы не укажете каждую таблицу как row_format dynamic или сжатую таблицу.

Нет никаких указаний на то, что вы должны выполнить полный сброс и перезагрузку при представлении своей первой таблицы 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 таблицы Antelope будут обновлены до 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, вы должны mysqldump все в нечто вроде /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 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Я только что ответил на этот вопрос в ServerFault: настройка сжатия MySQL INNODB KEY_BLOCK_SIZE . Это заставило меня оглянуться на любые вопросы, на которые я ответил в DBA, где StackExchange обсуждал Barracudaформат, и я нашел этот старый пост. Я размещу ту же информацию здесь ...

Согласно документации MySQL по сжатию InnoDB для Barracuda

Сжатие и буферный пул InnoDB

В сжатой таблице InnoDB каждая сжатая страница (1 КБ, 2 КБ, 4 КБ или 8 КБ) соответствует несжатой странице размером 16 КБ. Чтобы получить доступ к данным на странице, InnoDB считывает сжатую страницу с диска, если она еще не находится в пуле буферов, а затем распаковывает страницу в исходную 16-байтовую форму. В этом разделе описывается, как InnoDB управляет буферным пулом по отношению к страницам сжатых таблиц.

Чтобы минимизировать ввод-вывод и уменьшить необходимость распаковки страницы, иногда буферный пул содержит как сжатую, так и несжатую форму страницы базы данных. Чтобы освободить место для других необходимых страниц базы данных, InnoDB может «удалить» из пула буферов несжатую страницу, оставив сжатую страницу в памяти. Или, если страница не была доступна в течение некоторого времени, сжатая форма страницы может быть записана на диск, чтобы освободить место для других данных. Таким образом, в любой момент времени буферный пул может содержать как сжатую, так и несжатую формы страницы, или только сжатую форму страницы, или ни одну из них.

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

Обратите внимание, что InnoDB Buffer Pool должен загружать страницы данных и страницы индекса, считанные для выполнения запросов. При первом чтении таблицы и ее индексов сжатая страница должна быть распакована до 16 КБ. Это означает, что у вас будет в два раза больше контента в пуле буферов, на странице сжатых и несжатых данных.

Если это дублирование содержимого данных происходит в буферном пуле, вам нужно увеличить innodb_buffer_pool_size на небольшой линейный коэффициент новой степени сжатия. Вот как:

СЦЕНАРИЙ

  • У вас есть сервер БД с 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.