Почему мы должны хранить лог-файлы и bin-log-файлы по другому пути или на дисках в mysql?
У меня есть базы данных установки репликации mysql.... расположение файла журнала файл bin-журнала все находятся по одному пути, который является по умолчанию моим каталогом данных mysql.
Я читал, что для лучшей производительности их следует хранить отдельно.
Может ли кто-нибудь предоставить мне, как это улучшает производительность. Есть ли документация для того же. Причина, почему нужно это сделать?
4 ответа
Главным образом потому, что тогда чтение и запись могут выполняться почти параллельно. Хранится отдельно, то есть на разных дисках.
Оптимизация Linux и H/W для MySQL - это хорошее представление о способах повышения производительности MySQL - в нем представлены критерии и выводы о том, когда использовать диски SSD и когда использовать диски SCSI, какие процессоры лучше подходят для каких задач.
Очень хорошая презентация, которую нужно прочитать для любого администратора!
Это в основном для случаев, когда трафик записи в вашу базу данных настолько высок, что один том диска не справляется с записью как файлов данных, так и файлов журналов. Диски имеют ограниченную пропускную способность, и вы можете иметь очень загруженный сервер базы данных.
Но маловероятно, что отделение файлов данных от binlogs даст лучшую производительность для запросов, потому что MySQL записывает в binlog во время фиксации, а не во время запроса. Если бы ваши диски были слишком медленными, чтобы не отставать от трафика, вы бы увидели COMMIT стать узким местом.
Система, которую я сейчас поддерживаю, хранит журналы в том же каталоге, что и каталог данных. Каталог данных находится на томе RAID10 с 12 физическими дисками. Это обеспечивает достаточную пропускную способность для поддержки нашей рабочей нагрузки. Но если бы у нас было примерно вдвое больше трафика записи, этот RAID-массив не смог бы идти в ногу.
Вам не нужно делать каждый совет, который кто-то говорит, дает лучшую производительность, потому что любой данный совет может не иметь значения для рабочей нагрузки вашего приложения. Вам необходимо измерить множество показателей производительности и использования ресурсов, а также найти правильную настройку или конфигурацию, чтобы устранить узкие места в вашей рабочей нагрузке.
Там нет волшебной конфигурации, которая делает все иметь высокую производительность.
Одно из соображений заключается в том, что использование отдельного диска для ведения блогов приводит к появлению еще одного SPOF, поскольку, если MySQL не может записать этот журнал, он будет работать так же, как если бы он не мог записывать в файлы данных. В противном случае добавление еще одного диска будет лучше разделять две задачи, чтобы записи бинлога и записи файла данных не приходилось бороться за ресурсы. С твердотельными накопителями это гораздо менее проблемная проблема, если только вы не испытываете чрезмерную нагрузку при записи и уже не связаны с производительностью SSD.
Также может быть очень неловко, когда ваши файлы журнала заполняют файловую систему и приводят к остановке базы данных.