Могу ли я разместить бины 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/ обратной записи на стороне диска: если такой кэш существует, то синхронизированные записи немедленно поглощаются им.

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