Завжди буде компроміс між стійкістю та продуктивністю.
З MySQL на ext4 за замовчуванням бар'єри = 1 дійсно спричиняють уповільнення, однак першою дією не повинно бути відключення журналу чи включення даних = запису даних.
По-перше, якщо стійкість має велике значення, RAID, що підтримується батареєю, безумовно, того варто.
Я вибрав варіанти кріплення, особливо на RAID, що не підтримується батареєю:
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
Це навмисно не використовується data = writeback, тому що я не хочу ризикувати пошкодженням файлової системи, в результаті чого "старі дані з'являтимуться у файлах після збоїв та відновлення журналу" (цитата від man mount).
Ідеальна конфігурація в my.cnf для повної стійкості навколо налаштувань вводу / виводу:
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
Я вибрав таку послідовність компромісів для підвищення ефективності:
sync_binlog = 0: це перший конфігурація MySQL, яку я змінюю від повної стійкості. Причиною цього є те, що це дає значне поліпшення продуктивності, особливо там, де binlog_format=row(на жаль, потрібно Джирі). Я використовую достатньо реплік MySQL у кластері, що якби бінлог був зіпсований сценарієм втрати живлення, я би зробив бінарну копію з іншої репліки.innodb_flush_log_at_trx_commit = 2: Хоча для повного відповідності ACID потрібне значення 1, зі значенням 2 "буфер журналу виписується у файл при кожному фіксації, але операція змивання з диском на ньому не виконується. Однак промивання на Файл журналу відбувається раз на секунду, також коли значення дорівнює 2. Зверніть увагу, що промивання один раз в секунду не гарантується на 100%, що трапляється щосекунди, через проблеми з плануванням процесу ". (цитата з документів MySQL)- Оновіть параметри кріплення для використання
data=writeback. Зауважте, що якщо це ваша коренева файлова система, вам також потрібно буде пройти параметр командного рядка ядра. Я зібрав кілька кроків щодо цього в кодеруоллі .
- Перевірте різні значення
innodb_flush_method. Показано, що O_DIRECT покращує продуктивність на деяких робочих навантаженнях, але це не означає, що це буде працювати у вашому середовищі.
- Оновлення до SSD - накопичувачів, в цьому випадку ви також хочете збільшити
innodb_io_capacity, а також налаштовувати параметри , такі як innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threads, і інші можливі настройки.