MySQL InnoDB Файл данных непосредственно на дисковом срезе (фиксированный размер)?

Question

Кажется, что IBDATA1 похож на ломтик диска. В файловых системах UFS Solaris (UNIX) (общий до ZFS) можно разделить свой диск C0T0D0 на срезы, скажем, диск 10 ГБ будет разрезан на три секции, 4 ГБ, 1 ГБ и 5 ГБ. Это будут файловые системы фиксированного размера. 4 ГБ для, скажем, OS. 1 ГБ для SWAP и 5 ГБ для программного обеспечения и данных.

SWAP можно хранить в файле в файловой системе, но для производительности он обычно хранится в своем собственном разделе диска.

Может ли IBDATA1 быть связанным с собственным кусочком для повышения производительности? Конечно, нужно будет тщательно подумать, прежде чем решить, какой фиксированный размер идеален, и им также придется знать, как проверить уровни использования.

Символическая ссылка может быть помещена из .../mysql/data/ibdata1 к /dev/rdsk/c0t0d0s3. Анкет MySQL тогда увидит это как файл, но может работать лучше, потому что он не должен проходить слой файловой системы, он будет писать непосредственно в назначенный раздел диска.

• Кто -нибудь пробовал это?
• Кто -нибудь думает, что это плохая идея? (Имейте в виду, эта идея предназначена для серверов только для базы данных только InnoDB. Не многоцелевые серверы.)
• Будет ли это сработать (необходимо ли Innodb проверить длину файла? Если нет, то это должно работать.)
• Можно ли проверить использование?

Answer 1

Прежде всего, какие типы записей находятся в IBDATA1? Четыре (4) типы вводов:

• Метаданные таблицы
• Таблицы страниц данных
• Индексные страницы данных
• MVCC Данные

Всякий раз, когда в таблице InnoDB испытывает DDL, DML или используется в транзакции, все четыре из этих типов записей либо читаются, либо написаны. Между тем, если innodb_file_per_table отключен, все эти типы записей живут в IBDATA1. Если он будет включен, только метаданные таблицы и данные MVCC будут находиться в IBDATA1, в то время как страницы данных таблицы и страницы данных индекса будут находиться в подпапде базы данных в качестве файла .ibd.

Это рассматривается, что произойдет, если IBDATA1 будет размещен в другом томе и сочувствует?

Для начала, как MySQL представляет таблицу независимо от двигателя хранения? Как файл .frm. Где живут файлы .frm? В датадире. Что случилось с этим ?

Вот пример:

Используя DataDir по умолчанию/var/lib/mysql, давайте использовать таблицу InnoDB под названием mydb.mytable.

С отключением innodb_file_per_table все будет сидеть в IBDATA1 (которую вы предлагаете Symlink и отправляете в другой том данных). Для таблицы mydb.mytable, это то, что у вас есть:

• /var/lib/mysql/mydb/mytable.frm
• Все остальное в столе живет на Ibdata1

Представьте себе это сейчас: вы получаете доступ к таблице, MySQL сначала нажимает на /var/lib/mysql/mydb/mytable.frm, а затем нажимает на страницы данных и индекса в ibdata1 для mydb.mytable. Это будет постоянно происходить с каждым доступом mydb.mytable. Этот каскадный обратно и вперед каким-то образом сделает вещи немного медленнее, и вы, возможно, не получите производительность, которую ожидали, перемещая IBDATA1 в какой-то другой объем данных. Фактически, каскадный эффект теперь будет фактором количества таблиц InnoDB, умноженных на два (2).

Представьте, что INNODB_FILE_PER_TABLE включена. Теперь у вас будет немного другая настройка:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• Данные MVCC и метаданные таблицы будут проживать в IBDATA1

Это каскад будет немного хуже, потому что каскад для доступа к таблице теперь будет происходить среди трех файлов вместо двух.

Вот еще один сценарий, о котором некоторые думали: вместо перемещения IBData1 в другой том, как насчет того, чтобы включить InnoDB_FILE_PER_TABLE и перемещение файлов .ibd в один или несколько разных томов данных? Каскадный эффект теперь будет фактором количества таблиц InnoDB, умноженных на три (3). Percona выразила очень веские причины, чтобы не сделать это, что вы найдете полезными.