Файлы mysql-bin огромного размера. Как почистить и настроить бинарные логи mysql в VMBitrix 7.5.X и Percona?

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

Для справки:
Двоичный журнал БД (mysql-bin-log) содержит «события», которые описывают изменения базы данных, такие как операции создания таблицы или изменения данных таблицы. Он также содержит события для операторов, которые потенциально могли внести изменения (например, DELETE, который не соответствует ни одной строке). Двоичный журнал также содержит информацию о том, сколько времени потребовалось каждому оператору для обновления данных.

1/
Размер binlog журнала можно оценить так.

Сперва размер файлов базы данных:

# du -sh /var/lib/mysql

кол-во файлов binlog журнала:

-rw-r—— 1 mysql mysql 101M Feb  6 01:11 /var/lib/mysql/mysql-bin.013987

как видно свыше тысячи файлов размером по 100 мб, имеем
1146 * 101M = ~113 гб журналов mysql-bin

3/
Как очистить эти файлы?

Самый простой способ — это зайти в командный клиент mysql (percona) под root и выполнить запрос PURGE BINARY LOGS BEFORE ‘YYYY-MM-DD hh:mm:ss’, где ‘YYYY-MM-DD hh:mm:ss’ — ваша текущая дата в указанном формате:

проверяем, что файлы почистились, смотрим их список:

15гб вместо 138гб с файлами журналов, неплохо, правда?

см. также:
PURGE BINARY LOGS Statement

4/
как сделать чтобы размер этих файлов не рос?

настроить сервис percona, а именно отредактировать файл /etc/mysql/conf.d/z_bx_custom.cnf
добавить или отредактировать в нем конфигурацию:

затем перезапуск сервера:
# systemctl restart mysqld

Если у вас остались вопросы — свяжитесь с нами любым удобным вам сопособом.

Назад в раздел

партнер компании 1с-битрикс

сайт фрилансера Сергея Эстрина

Как устанавливать параметры MysqlСмотрим файл /etc/init.d/mysql и находим параметр CONF — в нем находится путь к файлу конфигурации mysql (обычно это /etc/mysql/my.cnf).

Чтобы параметры вступили в силу, нужно перезапустить сервер mysql. Сделать это можно при помощи команды /etc/init.d/mysql restart (Debian, Ubuntu) или /etc/init.d/mysqld restart (Fedora, Cent OS).

Наиболее важные параметры

Перечислю наиболее важные параметры, значения которых желательно установить

Параметры для типа таблиц InnoDB

Параметры для типа таблиц MyISAM

#1 12. 2016 14

Зарегистрирован: 12.06.2016Сообщений: 8

Настройка my. cnf в высоконагруженном сайте

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

Тесты битрикса говорят что запись у меня страдает (первое значение мой тест, второй рекомендуемый):База данных MySQL (запись) — 1 945 — 5 600 — количество запросов на запись в секундуБаза данных MySQL (чтение) — 22 621 — 7 800 — количество запросов на чтение в секундуБаза данных MySQL (изменение) — 6 924 — 5 800 — количество запросов на изменение в секунду

#2 12. 2016 17

АрхатОткуда: ОрелЗарегистрирован: 07.03.2007Сообщений: 5811

только по my.cnf сложно что-то сказать

кто грузит процессор (php, mysql, ..) ? если база, то какие запросы создают нагрузку?можно, например, смотреть через show full processlist; в момент нагрузки

#3 12. 2016 18

Отредактированно DragoN (12.06.2016 18:03:44)

#4 12. 2016 18

Как только я выключаю мускуль, все становиться хорошо.

это не аргумент. Что показывает top?

Почему у вас висит event_scheduler? Какое там событие?

По запросам, сделайте  long_query_time = 0так в лог будут попадать все запросы и обработайте его с помощью утилиты pt-query-digest

по my.cnf — а как, например, определить достаточно ли вы выделили памяти под буфера, имея только my.cnf?

#5 12. 2016 18

насчет планировщика был не прав: состояние означает, что его очередь пуста и он спитсобственно show full processlist показывает, что выполняется только SHOW FULL PROCESSLIST, остальные потоки спят.

аналогично по htop все показанные процессы mysql спятотсортируйте его по cpu и посмотрите кто находится в состояние r (выполнения)

#8 13. 2016 03

Все время все скачет, что является логичным. Поймал когда в нагрузка на мускуль в топе

#9 13. 2016 06

Кое-что оптимизировал (спасибо за утилиту pt-query-digest vasya), вот теперь в отчете практически все битрикс таблицы

#10 13. 2016 12

АдминистраторОткуда: МоскваЗарегистрирован: 21.01.2007Сообщений: 3876

С конфигом скорее всего ничего страшного нет, но он все же немного странный. Например,

можно увеличить в 10 раз.

innodb_thread_concurrency = 8
innodb_file_io_threads = 8
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_buffer_pool_instances = 8

я бы убрал. Вы ведь не знаете оптимальны они или нет

#11 13. 2016 15

АдминистраторЗарегистрирован: 22.01.2007Сообщений: 6748

Ух, сколько людей собрал тредик

Давайте я тоже внесу свою лепту.

Смотрю на те картинки, которые Вы приложили, и не вижу, чтобы сервер был загружен хоть сколько-то — во всех них он ничего не делает, и приходится вылавливать моменты, когда он ест процессор, например. Соответственно, вопрос — вы уверены, что сервер вообще нагружен, а дело не в чем-то другом? Если да — можете сделать соответствующую картинку, где это видно?

#12 13. 2016 16

Да, конечно уверен. Сейчас выходные дни + лето (сезон отпусков) и пиковой нагрузки нет, поэтому скрины предоставлены с натяжкой. У нас новостные сайты и в любой момент посещения могут быть высокие. Приезд кого-нибудь, убийства, похищения и прочая нечисть из-за которой народ начинает усиленно заходить на сайты. Кстати, я писал выше, что с той утилитой я смог устранить серьезные недостатки и поэтому нагрузка упала. НО, я боюсь того что при пиковой нагрузке сайты снова лягут, поэтому хочу чтобы мне помогли понять что я сделал не правильно, научили до того.

P.S. У нас на сервере есть несколько сайтов, некоторые из них самописные, кое-что на битриксе и часть на вордпрессе. Сам я программист и стараюсь улучшать что имею, так же приходится настраивать сервер и кое-что из настроек мне не совсем ясны — постоянно читаю, изучаю (иногда даже кажется, что предоставляемой информации недостаточно чтобы понять всю суть необходимой опции (к примеру) на оригинальном языке, а вот спросить не у кого правильно ли я понимаю или нет). Я живу очень далеко от столицы и не могу позволить себе посещать какие-то дополнительные курсы, конференции, так как в городе ни кто таким не занимается, максимально что могу это ютуб — где опять же не спросишь ничего.

Спасибо всем за то что обратили на меня внимание и стараетесь помочь

#13 13. 2016 17

Ну, по приведенным картинкам совсем непонятно, что оптимизировать — все работает хорошо. Угадывать узкие места можно пробовать, но, как правило, это неэффективно — лучше попрофилировать. Если можете воспроизвести нагрузку на стенде — воспроизведите, и тогда можно будет смотреть, во что упираетесь. Без нагрузки — почти наверняка не угадаем.

#14 13. 2016 17

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

Приветствую всех
Недавно начал развертывать ВМ, параметры (2 CPU/4 RAM/ 10 + 5G (db + os)). Накатил на нее Bitrix
По рекомендациям с офф сайта установил все рекомендованные параметры mysql/php
В ходе проверок bitrix_test.php все ОК, в ходе проверок отдельно db и php — все ОК. В ходе проверки настроек производительности выходит приблизительно:
Конфигурация 11.38 30

Среднее время отклика 0.0879 0.0330 секунд

Процессор (CPU) 2.0 9.0 миллионов операций в секунду

Файловая система 4776.8 10000 файловых операций в секунду

Почтовая система 0.0204 0.0100 время отправки одного письма (в секундах)

Время старта сессии 0.0002 0.0002 секунд

Конфигурация PHP оптимально оптимально

База данных MySQL (запись) 2503 5600 количество запросов на запись в секунду

База данных MySQL (чтение) 6250 7800 количество запросов на чтение в секунду

База данных MySQL (изменение) 2347 5800 количество запросов на изменение в секунду

Ось — Centos 7
параметры mysql 5.6 (основные):

Cache parameters

query_cache_size = 64M
table_open_cache = 1200
thread_cache_size = 4
key_buffer_size = 256M
thread_stack = 128K
join_buffer_size = 18M
sort_buffer_size = 18M
query_cache_limit = 8M
query_cache_type = 1
read_buffer_size = 16M

InnoDB parameters

innodb_file_per_table
innodb_buffer_pool_size=32M
innodb_lock_wait_timeout=50
innodb_buffer_pool_size = 512M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_flush_method = O_DIRECT
innodb_strict_mode = OFF

realpath_cache_size 4096k
opcache.max_accelerated_files 100000
opcache.enable 1
opcache.validate_timestamps 1
opcache.memory_consumption 128
opcache.memory_usage.used_memory 72.88 МБ
opcache.memory_usage.free_memory 55.01 МБ
Регулярные выражения PHP: Да
Регулярные выражения Perl: Да
Zlib extension: Да
GD lib extension: Да
Free Type extension: Да
Модули шифрования: mcrypt
Модуль Hash: Да
XML: Да
JSON: Да
Поддержка mbstring: Да
Включен режим UTF для mbstring: Да

Сервер прям свежий, только установил, накатил свежий bitrix и обновил только недавно систему.
Пробовал менять тип дисков, добавлять ОЗУ/CPU — производительность не менялась. Может в настройках какая то проблема?

Буду очень признателен за любую подсказку, спасибо!

Введение

Когда-то давно мною была написана статья по настройке репликации в MySQL. Но данный способ имеет один нюанс: данный метод блокирует публичную часть сайта и начинает дропать все таблицы и переносить их заново. Так происходит, потому что репликация в MySQL заранее не настроена, и первичная настройка выполняется через интерфейс битрикса. В общем, есть некоторые неудобства данного способа.

Также я писал про другой метод репликации Master-Slave в MySQL с использованием GTID. И вот теперь можно применить его при настройке репликации MySQL в битрикс, чтобы избежать проблем из первоначальной статьи и всё сделать правильно.

В данной статье будет рассказано о настройке репликации MySQL для Битрикс24 с использованием GTID. Описанные шаги также применимы и к настройке репликации с GTID уже на работающем сервере MySQL.

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

Для работы репликации на уровне приложения Битрикс необходимо наличие модуля “Веб-кластер” и необходимой лицензии.

• Конфиг по пути /etc/percona-server.conf.d/mysqld.cnf
• Директория для MySQL – /mnt/u01/mysql/data

Подготовка Master-сервера

# Cache parameters
query_cache_size = 32M
table_open_cache = 4096
thread_cache_size = 32
key_buffer_size = 16M
thread_stack = 128K
join_buffer_size = 2M
sort_buffer_size = 2M

# Parameters for temporary tables
tmpdir = /tmp
max_heap_table_size = 32M
tmp_table_size = 32M

# InnoDB parameters
innodb_file_per_table
innodb_buffer_pool_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT

# Database charset parameters
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = “SET NAMES utf8 COLLATE utf8_unicode_ci”
#skip-character-set-client-handshake
skip-name-resolve

# Replication
gtid_mode = ON
log_bin = mysql-bin
log-slave-updates
enforce-gtid-consistency
server_id = 1
replicate-do-db = db_name
sync_binlog = 0
innodb_strict_mode=0

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

• datadir – путь, где физически располагаются файлы MySQL. В данной инструкции предполагается, что это директория /mnt/u01/mysql/data
• socket – путь до сокета для консольного клиента, в той же директории /mnt/u01/mysql/data
• innodb_buffer_pool_size – требует тонкой настройки, для начала можно выставить в 50% от свободной оперативной памяти (значение в 4096М или 4G – мегабайты или гигабайты соответственно).
• server-id – в зависимости от роли Master или Slave
• innodb_strict_mode=0 – данный параметр нужно указать явно в конфиге

Прочие параметры можно оставить по умолчанию, они подлежат корректировке в случае необходимости.

Вышеописанный конфиг был взят из виртуальной машины bitrix для конфигурации: HDD, 1vCPU, 2 RAM. Он не является универсальным и должен настраиваться индивидуально.

Подготовка Slave-сервера

Настройки слейва почти не отличаются от настроек мастера, за исключение конфигурационного файла MySQL.

# Replication
server-id=2
gtid_mode=ON
enforce-gtid-consistency
replicate-do-db = db_name
innodb_strict_mode=0

Дальнейшие действия выполняются из статьи по настройке репликации в MySQL, после чего можно переходить к настройке репликации для Битрикс24.

Для продолжения должна быть настроенная репликация на уровне MySQL, чтобы битрикс подхватил настроенный слейв на уровне приложения.

Создание учётных записей

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

Всего необходимо три учётки:

• Основная УЗ из dbconn.php и .settings.php – для подключения и работы приложения с БД;
• УЗ для управления слейв-серверами из веб-интерфейса битрикс;
• УЗ для подключения сервера реплики к мастеру и работы непосредственно самой репликации.

Для каждой из вышеописанных УЗ необходимы отдельные права:

И REPLICATION CLIENT для получения статистики с мастера, но на все базы:

Без права REPLICATION CLIENT на все БД для основной УЗ приложения настроить реплику из админки битрикса не получится! В документации битрикс про это не написано.

А также REPLICATION CLIENT и SUPER для управления слейвами, но уже на уровне всех БД:

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

На боевом мастер-сервере с БД стоит внимательно выдавать права. При допущении ошибок, работа приложения может быть нарушена!

Настройка репликации на уровне Битрикс24

На данном этапе осталось лишь подхватить созданный слейв в админке битрикса.

• Нажать “Добавить Slave базу данных“, пройти проверку при создании слейва
• Несмотря на красные пункты, можно продолжать далее – это всего лишь рекомендации и дальнейшей настройке они не помешают:

Особое внимание нужно обратить на файлы bitrix/php_interface/after_connect.php и bitrix/php_interface/after_connect_d7.php. Для настройки репликации их необходимо удалить, чтобы мастер битрикса прошёл проверку. Но в данном файле указываются некоторые настройки для БД, в частности, директива innodb_strict_mode=0, которую нужно указать в конфигурационном файле mysqld.cnf, о чём было сказано в самом начале статьи в абзаце с примерами конфигов.

Заключение

В статье был рассмотрен способ настройки репликации Master-Slave в MySQL для Битрикс24 с учётом его особенностей. Особых сложностей возникнуть не должно, если репликация заранее уже настроена в самом MySQL – это самое главное.

Способ выдачи прав для репликации – всё для одной учетки или для трёх отдельных – дело сугубо индивидуальное. Рекомендуется отталкиваться исходя из потребностей, но не забывать про безопасность.

Настройка базы данных MySQL

Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.

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

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

Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.

Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:

• Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это — исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный.
  Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).
• Скорость. На невысокой посещаемости MyISAM ведет себя быстрее, как на модификацию, так и на чтение. Однако, при росте посещаемости достаточно быстро сказывается отсутствие транзакций и блокировка на уровне таблиц. При некоторой величине посещаемости проект просто реально умирает. В InnoDB запись будет медленнее (транзакции же), зато при высокой посещаемости блокировки наступят намного, намного позже, чем для MyISAM.

Поменять тип таблиц на InnoDB можно следующим образом:

Переход на тип таблиц InnoDB позволяет избежать возникновения узкого участка в производительности при работе с базой данных и в полном объеме использовать системные ресурсы.

Внимание! Обязательно конфигурируйте InnoDB. Для лучшей производительности базы данных при работе с InnoDB рекомендуется настроить my.cnf для MySQL в разделе параметров для InnoDB innodb_*.

Наибольшее внимание следует обратить на следующие параметры и примеры:

set-variable = innodb_buffer_pool_size=250M
set-variable = innodb_additional_mem_pool_size=50M
set-variable = innodb_file_io_threads=8
set-variable = innodb_lock_wait_timeout=50
set-variable = innodb_log_buffer_size=8M
set-variable = innodb_flush_log_at_trx_commit=0

Если MyISAM уже не используется активно, можно высвободить память в пользу InnoDB параметров.

Желательно, чтобы кэш данных вмещал в себя основной объем данных, используемых продуктом в работе. Обычно для работы базы данных выделяется порядка 60-80% свободной памяти в системе.

Рекомендуется: Производить многопотоковую (multithreading) сборку MySQL для улучшения производительности системы и возможностей по параллельной обработке запросов.

Пример рекомендуемых настроек для сервера с 2 Гб оперативной памяти, работающего с операционной системой FreeBSD/Linux:

В составе продукта около 250 таблиц, поэтому рекомендуется увеличивать кэш для заголовков таблиц.

set-variable = key_buffer_size=16M
set-variable = sort_buffer=8M
set-variable = read_buffer_size=16M

Эти параметры используются только для MyISAM. Если в базе нет таблиц MyISAM, то лучше установить минимальные значения.

set-variable = query_cache_size=64M
set-variable = query_cache_type=1

Кэширование результатов запросов. Обычно бывает достаточно 32 Мб (смотреть на статус Qcache_lowmem_prunes). Максимальный размер результата по умолчанию — 1 Мб, его можно регулировать.

set-variable = innodb_buffer_pool_size=780M

Основной буфер — чем больше, тем лучше.

set-variable = innodb_additional_mem_pool_size=20M

Вспомогательный буфер на внутренние структуры, большой делать не имеет смысла.

set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M

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

Отложенная фиксация транзакций, раз в секунду

set-variable = tmp_table_size=32m

Размер временных таблиц рекомендуется увеличивать до 32 Мб.

Рекомендуется так же увеличивать join_buffer_size до 2 Мб, это существенно влияет на скорость выполнения ряда запросов.

set-variable = join_buffer_size = 2M

Совет администратору Переход на InnoDB может привести к значительному замедлению некоторых масштабных операций записи и обновления данных. Это связано с тем, что все операции по изменению данных начинают выполняться с использованием транзакций. Кроме того, в отличие от MyISAM для кэширования таблиц InnoDB не используется кэш операционной системы, а все кэшированные данные хранятся в кэше БД, определяемом параметром innodb_buffer_pool_size. Вы должны сами определить оптимальность перехода вашего проекта на формат данных InnoDB.

Внимание! Если по каким-то причинам вы решили продолжить работу с типом данных MyISAM, обязательно проведите конфигурирование MySQL для увеличения объемов кэшируемой информации, областей сортировки и минимизации числа дисковых операций. Использование для базы данных 60-80% оперативной памяти может ускорить работу стандартного проекта в несколько раз.

Временная папка

При наличии достаточного количества ОЗУ рекомендуется выносить временную папку MySQL на ramdisk в памяти.

• Убедитесь, что в ядре реализована поддержка tmpfs.
• Создайте новую точку монтирования и дайте все права на использование:
  # mkdir /mnt/tmpfs/
  # chmod 777 /mnt/tmpfs/
• Дайте команду (от рута или через sudo):

  # mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
  или
  $ sudo mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/

  где 1024M есть размер RAMdisk в Мегабайтах.

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

Список ссылок по теме:

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

MySQL, InnoDB, Монитор производительности

Приветствую. Хочу поделится радостью: удалось оптимизировать работу MySQL.

В БУС монитор производительности на мощном сервере показывал следуюшее:

База данных MySQL (запись)      72      5 600      количество запросов на запись в секунду
База данных MySQL (чтение)      5 869   7 800      количество запросов на чтение в секунду
База данных MySQL (изменение)   4 251   5 800      количество запросов на изменение в секунду

Чего я только с настройками мускуля не крутил, ничего сильно ощутимого результата не давало.

Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2После того как я ее прописал, получил следующие циферки:

База данных MySQL (запись)     4 395     5 600     количество запросов на запись в секунду
База данных MySQL (чтение)    6 220    7 800    количество запросов на чтение в секунду
База данных MySQL (изменение)    4 643    5 800    количество запросов на изменение в секунду

Увелечение скорости записи в 60 раз меня ну очень обрадовало.

innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы.

Ссылки по теме

• Огромное спасибо Петру Невенчанному за помощь в ковыряниях настроек.
• Монитору производительности (P.S.: Сергей Рыжиков, да он помогает диагностировать проблемы (это я к Вашему выступлению на highload).

Немного передохнем и продолжим оптимизировать. Надеюсь тема не баян, и будет полезна.Обновление

Руководство по настройке и установке