Почему мы должны хранить лог-файлы и bin-log-файлы по другому пути или на дисках в mysql

Question

У меня есть настройки репликации базы данных mysql .... расположение файла журнала файл bin-журнала все находятся по одному пути, который по умолчанию является моим каталогом данных mysql.

Я читал, что для лучшей производительности их следует хранить отдельно.

Может кто-нибудь предоставить мне, как это улучшает производительность. Есть ли документация для того же. Причина, по которой это нужно делать?

Answer 1

Главным образом потому, что тогда чтение и запись могут выполняться почти параллельно.Хранится отдельно, то есть на разных дисках.

Оптимизация Linux и H / W для MySQL - хорошее представление о способах повышения производительности MySQL - в нем представлены критерии и выводы о том, когда использовать диски SSD, а когда - диски SCSI, чтоДля каких задач лучше использовать процессоры.

Очень хорошая презентация, которую нужно прочитать для любого администратора базы данных !!

Answer 2

Одно из соображений заключается в том, что использование отдельного диска для ведения блогов вводит еще один SPOF, поскольку, если MySQL не может записать этот журнал, он будет работать так же, как если бы он не мог записывать в файлы данных.В противном случае, добавление еще одного диска лучше разделить две задачи, чтобы записи бинлога и записи в файл данных не приходилось бороться за ресурсы.С твердотельными накопителями это гораздо меньше проблем, если только вы не испытываете чрезмерную нагрузку при записи и уже не связаны с производительностью SSD.

Answer 3

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

Answer 4

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

Но маловероятно, что отделение файлов данных от binlogs даст лучшую производительность для запросов, потому что MySQL записывает в binlog во время фиксации, а не во время запроса. Если ваши диски будут слишком медленными, чтобы не отставать от трафика, вы увидите, что COMMIT станет узким местом.

Система, которую я сейчас поддерживаю, хранит журналы в том же каталоге, что и каталог данных. Каталог данных находится на томе RAID10 с 12 физическими дисками. Это обеспечивает достаточную пропускную способность для поддержки нашей рабочей нагрузки. Но если бы у нас было примерно вдвое больше трафика записи, этот массив RAID не справился бы с работой.

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

Не существует волшебной конфигурации, которая бы обеспечивала высокую производительность всего.