Могу ли я поместить двоичные журналы MySQL на медленный диск?

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

Я бы сохранил ваши двоичные журналы в вашем самом быстром хранилище, но уменьшил бы количество журналов на флэш-накопителе, сохранив только те, которые все еще требуются для репликации.

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

1. На каждом подчиненном сервере используйте SHOW SLAVE STATUS чтобы проверить, какой файл журнала он читает.

2. Получите список двоичных файлов журнала на главном сервере с помощью SHOW BINARY LOGS.

3. Определите самый ранний файл журнала среди всех ведомых устройств. Это целевой файл. Если все ведомые устройства обновлены, это последний файл журнала в списке.

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

5. Очистите все файлы журналов до целевого файла, но не включая его.

Если вы хотите сохранить больше журналов, например, для целей аудита, на шаге 4 скопируйте эти журналы на более медленный (вращающийся) диск, прежде чем удалять их с флэш-накопителя с помощью PURGE BINARY LOGS TO или PURGE BINARY LOGS BEFORE Заявление MySQL.

Из Руководство по MySQL:

По умолчанию, двоичный журнал синхронизируется с диском при каждой записи (sync_binlog=1). Если sync_binlog не был включен и операционная система или компьютер (не только сервер MySQL) вышли из строя, есть вероятность, что последние операторы двоичного журнала могут быть потеряны. Чтобы предотвратить это, включите системную переменную sync_binlog для синхронизации двоичного журнала с диском после каждых N групп фиксации. См. Раздел 5.1.8, «Системные переменные сервера». Самым безопасным значением для sync_binlog является 1 (по умолчанию), но это также и самое медленное.

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

Использование одного диска 7200 об / мин в качестве примера выделенного устройства binlog: при средней задержке вращения ~ 4,1 мс вы можете ожидать ~ 250 операций ввода-вывода записи в секунду. Это, очевидно, предполагает отсутствие кеша NVRAM / обратной записи на стороне диска: если такой кеш существует, то синхронизированные записи немедленно поглощаются им.

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