8.12.2 Optimizing Disk I/O — MySQL 5.7

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

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

Поиск на диске является серьезной проблемой производительности. Эта проблема становится более очевидной, когда объем данных начинает расти настолько, что эффективное кэширование становится невозможным. Для больших баз данных, где вы обращаетесь к данным более или менее случайным образом, вы можете быть уверены, что вам потребуется как минимум один поиск на диске для чтения и несколько поисков на диске для записи. Чтобы свести эту проблему к минимуму, используйте диски с низким временем поиска.
Увеличьте количество доступных дисков (и тем самым уменьшите накладные расходы на поиск) путем создания символических ссылок на файлы на разные диски или полосы диска:
- Использование символических ссылок
  
  Это означает, что для MyISAM таблиц вы создаете символические ссылки на файл индекса и файлы данных из их обычного расположения в каталоге данных на другой диск (который также может быть полосчатым). Это улучшает как время поиска, так и время чтения, при условии, что диск не используется для других целей. См. раздел 8.12.3 «Использование символических ссылок».
  
  Символические ссылки не поддерживаются для использования с InnoDB таблицами. Однако можно разместить данные и файлы журналов InnoDB на разных физических дисках. Более подробную информацию см. в разделе 8.5.8 «Оптимизация ввода-вывода диска InnoDB».
- Полосы
  
  Полосы означают, что у вас есть много дисков, и вы помещаете первый блок на первый диск, второй блок на второй диск, а N-й блок на (N MOD number_of_disks) диск и так далее. Это означает, что если ваш обычный размер данных меньше размера полосы (или идеально выровнен), вы получите значительно лучшую производительность. Полосы сильно зависят от операционной системы и размера полосы, поэтому протестируйте свое приложение с различными размерами полос. См. раздел 8.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 с параметрами монтирования hard и intr.
Ограничения максимального размера файла. Клиенты NFS версии 2 могут получить доступ только к самым нижним 2 ГБ файла (со знаком 32-битный смещение). Клиенты NFS версии 3 поддерживают файлы большего размера (до 64-битного смещения). Максимальный поддерживаемый размер файла также зависит от локальной файловой системы сервера NFS.

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

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