10.12.1 Optimizing Disk I/O — MySQL 9.2

10.12.1 Оптимизация ввода-вывода на диске

В этом разделе описываются способы настройки устройств хранения, когда вам доступны более быстрые и емкие устройства для сервера базы данных. Сведения об оптимизации конфигурации InnoDB для повышения производительности ввода-вывода см. в разделе 10.5.8 «Оптимизация ввода-вывода InnoDB на диске».

Поиски на диске — серьёзная проблема производительности. Эта проблема становится более заметной, когда объём данных начинает расти настолько, что эффективное кэширование становится невозможным. Для больших баз данных, где доступ к данным осуществляется более или менее случайным образом, можно быть уверенным, что для чтения потребуется хотя бы один поиск на диске, а для записи — несколько. Чтобы минимизировать эту проблему, используйте диски с низким временем поиска.
Увеличьте количество доступных дисков (и тем самым уменьшите накладные расходы на поиск) путём создания символических ссылок на файлы на различные диски или полосовой записи дисков:
- Использование символических ссылок
  
  Это означает, что для MyISAM таблиц вы создаёте символические ссылки на файл индекса и файлы данных из их обычного расположения в каталоге данных на другой диск (который также может быть полосными записями). Это улучшает время поиска и чтения, при условии, что диск не используется для других целей. См. раздел 10.12.2 «Использование символических ссылок».
  
  Символические ссылки не поддерживаются для использования с InnoDB таблицами. Однако можно разместить данные и журналы InnoDB в различных физических дисках. Дополнительные сведения см. в разделе 10.5.8 «Оптимизация ввода-вывода InnoDB на диске».
- Полосовая запись
  
  Полосовая запись означает, что у вас есть несколько дисков, и первый блок размещается на первом диске, второй — на втором диске, и N-й блок — на (N MOD number_of_disks)-м диске и так далее. Это означает, что если размер ваших обычных данных меньше размера полосы (или идеально выровнен), вы получите значительно лучшую производительность. Полосовая запись очень зависит от операционной системы и размера полосы, поэтому протестируйте ваше приложение с различными размерами полос. См. раздел 10.13.2 «Использование собственных бенчмарков».
  
  Разница в скорости при полосовой записи очень зависит от параметров. В зависимости от того, как вы настроите параметры полосовой записи и количество дисков, вы можете получить разницу в нескольких порядках величины. Вам необходимо выбрать оптимизацию для случайного или последовательного доступа.
Для надёжности можно использовать RAID 0+1 (полосовая запись плюс дублирование), но в этом случае вам потребуются 2 × N диска для хранения N дисков данных. Это, вероятно, лучший вариант, если у вас есть деньги на это. Однако, вам, возможно, также придётся инвестировать в программное обеспечение для управления томами для эффективного управления.
Хороший вариант — изменять уровень RAID в зависимости от важности данных. Например, храните полуважные данные, которые можно восстановить на диске RAID 0, но храните действительно важные данные, такие как информация о хосте и журналы, на диске RAID 0+1 или RAID N. RAID N может быть проблемой, если у вас много записей, из-за времени, необходимого для обновления контрольных битов.
Вы также можете настроить параметры файловой системы, используемой базой данных:

Если вам не нужно знать, когда файлы были в последний раз обработаны (что не очень полезно на сервере базы данных), вы можете смонтировать файловые системы с параметром -o noatime. Это пропускает обновления времени последнего доступа в узлах файловой системы, что позволяет избежать некоторых поисков на диске.

На многих операционных системах можно настроить файловую систему для асинхронного обновления, смонтировав её с параметром -o async. Если ваш компьютер достаточно стабилен, это должно улучшить производительность, не жертвуя надёжностью. (Этот флаг включен по умолчанию в Linux.)

Использование NFS с MySQL

Следует быть осторожным при использовании NFS с MySQL. Возможные проблемы, которые зависят от операционной системы и версии NFS, включают следующие:

Файлы данных и журналов MySQL, размещённые на томах NFS, могут заблокироваться и стать недоступными. Проблемы с блокировкой могут возникнуть в тех случаях, когда несколько экземпляров MySQL обращаются к одному и тому же каталогу данных или когда MySQL неправильно закрывается, например, из-за отключения питания. NFS версии 4 решает проблемы с блокировкой, введя консультативные и основанные на аренде блокировки. Однако совместное использование каталога данных между экземплярами MySQL не рекомендуется.
Несогласованность данных, возникающая из-за сообщений, полученных в неправильном порядке или потерянных данных сетевого трафика. Чтобы избежать этой проблемы, используйте TCP с параметрами mount hard и intr.
Предельные значения размера файлов. Клиенты NFS версии 2 могут получить доступ только к нижним 2 ГБ файла (подписанный 32-битный смещение). Клиенты NFS версии 3 поддерживают файлы большего размера (до 64-битных смещений). Максимальный поддерживаемый размер файла также зависит от локальной файловой системы сервера NFS.

Использование NFS в профессиональной среде SAN или другой системе хранения данных, как правило, обеспечивает большую надёжность, чем использование NFS вне такой среды. Однако NFS в среде SAN может быть медленнее, чем подключение напрямую или к шине невращающегося хранилища.

Если вы выбираете использование NFS, рекомендуется использовать NFS версии 4 или выше, а также тщательно протестировать вашу настройку NFS перед развертыванием в рабочей среде.