Назад | Перейти на главную страницу

Сервер mysql в основном перестает работать, когда binlog отключен

Производительность была немного ниже, чем хотелось бы на сервере mysql, и мы не используем репликацию и не нуждаемся в восстановлении на определенный момент времени. Таким образом, один из рекомендуемых способов повышения производительности - отключить ведение журнала. В моем my.cnf есть следующее:

    ## Replication / Transaction Logging #
    binlog_format           = row
    log-bin                 = /var/lib/mysql/mysql-bin.log
    expire_logs_days        = 3
    sync-binlog             = 1

Я закомментировал все четыре строки и перезапустил mysql. Служба запустилась нормально, нет ничего, что указывало бы на какие-либо проблемы в каких-либо журналах ошибок или журналах медленных запросов. Все выглядит нормально, за исключением того, что скорость записи снижается до непригодного для использования уровня. Тем не менее, он продолжает работать. Отказ от комментариев в четырех вышеуказанных строках и перезапуск службы немедленно восстановили предыдущие уровни производительности.

Предыдущий уровень производительности - это не то, что я хочу, я хочу улучшения производительности, которое, надеюсь, должно произойти с отключением bin-logging.

Почему это случилось? Как я могу успешно отключить ведение журнала корзины для повышения производительности?

Технические характеристики:

sync-binlog

Когда вы закомментировали sync-binlog = 1, что произошло ?

Ты сделал sync_binlog по умолчанию 0. Что происходит потом? В документации MySQL говорится:

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

Это означает, что mysqld находится во власти ОС, чтобы сбрасывать изменения на диске в двоичные журналы. Это означает, что должно быть открыто много файлов (бегать lsof), что ОС должна быть сброшена на диск. Текущий двоичный журнал MySQL должен находиться в середине этого журнала открытых файлов, которые необходимо периодически сбрасывать на диск, особенно если многие из этих открытых файлов записываются регулярно.

В документации MySQL далее говорится:

Значение 1 - самый безопасный выбор, потому что в случае сбоя вы потеряете не более одной группы фиксации из двоичного журнала. Однако это также самый медленный вариант (если на диске нет кеш-памяти с резервным питанием от батареи, что делает синхронизацию очень быстрой).

Это просто означает, что сброс на диск выполняется sync-binlog=1 дал серверу некоторую стабильность, так как изменения с диска сбрасывались на диск, и освободил ОС для работы немного лучше. Без него mysqld имел такой же приоритет, как и любой другой процесс (приложение или ОС), у которого были открытые файлы.

InnoDB

Вот графическое изображение InnoDB (от технического директора Percona Вадима Ткаченко)

Вы можете заставить InnoDB более агрессивно сбрасывать данные на диск и при этом работать хорошо.

  • Устанавливать innodb_flush_method к O_DIRECT заставляет InnoDB обрабатывать собственную очистку изменений на диске. Учитывая изображение, InnoDB будет явно сбрасываться в буфер двойной записи в системном табличном пространстве (ibdata1), а также в .ibd файлы таблиц из буферного пула. В системе с аппаратным RAID-контроллером и кешем записи с резервным питанием от батареи O_DIRECT может помочь избежать двойной буферизации между пулом буферов InnoDB и кешем файловой системы операционной системы.
  • Устанавливать innodb_write_io_threads до 8 (или 16)
  • Устанавливать innodb_log_buffer_size до 128 МБ для уменьшения дискового ввода-вывода
  • Устанавливать innodb_log_file_size до 1G

Поэтому добавьте эти настройки в my.cnf (требуется перезагрузка)

[mysqld]
innodb_flush_method = O_DIRECT
innodb_write_io_threads = 8
innodb_log_buffer_size = 128M
innodb_log_file_size = 1G

Эпилог

Если вы хотите отключить двоичный журнал, настройте InnoDB для лучшей очистки с помощью компенсации