Улучшение скорости репликации MySql
Отказ от ответственности: Я связываю свои ответы для подобных вопросов :-)
Этот поток может быть связан: Когда RAID стоит проблемы?
И другой: Аппаратные средства RAID с помощью Dell PERC 6 или программного обеспечения RAID?
Это было бы интересно записать при наверстывании:
сколько пропускной способности используется
сколько загрузки ЦП (особенно i/o ожидают),
использование оперативной памяти
В ответ на новую информацию о i/o ожидают, будучи высоким; для innodb много может быть сделано, смотреть на. Я узнал о многих вещах из mysqlperformanceblog. Вот некоторые подсказки:
innodb_flush_method=O_DIRECT
"Избегайте двойной буферизации и снизьте давление подкачки, в большинстве случаев эта установка улучшает производительность. Хотя быть осторожным, если Вы не имеете с аварийным батарейным питанием кэш RAID как тогда, когда запись IO может пострадать".
innodb_flush_log_at_trx_commit=2
"Если Вы не озабоченность по поводу ACID и можете освободить транзакции в течение прошлой секунды или два в случае полного катастрофического отказа ОС, чем установленный это значение. Это может поразительный эффект особенно на большое количество коротких транзакций записи".
Они сделали ЧУДЕСА для нас, но недостаток состоит в том, что Вы могли бы освободить секунду записанных данных. Это вызвано тем, что вместо записи (сбрасывают к диску) каждая запись, Вы сбрасываете каждую секунду.
Можно читать больше на: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
Репликация MySQL быстра, действительно быстро. Это - основное ограничение, канальный уровень и затем остальная часть аппаратных средств.
В Вашем случае, возобновляя репликацию, вероятно, покажет двоичные журналы или ведомый IO, нагоняющий справедливо быстро. В противном случае улучшите свою ссылку сначала. Иначе, если это - SQL, Вы собираетесь иметь физические ограничения сервера, который собирается варьироваться между диском IO, RAM и ЦП в зависимости от типа загрузки.
I. Добавить небольшие, но простые IO-оптимизации для info-файлов
sync_relay_log_info=5000000
sync_master_info=5000000
II. Use multi-threading (can be worse results)
slave_parallel_workers=10
log_slave_updates=1
slave_preserve_commit_order=1
slave_parallel_type=LOGICAL_CLOCK
slave_pending_jobs_size_max=1047527424 # должно быть не меньше, чем max_allowed_packet
- For activation - рестарт
III. При возникновении проблем с пропускной способностью попробуйте использовать сжатие
slave_compressed_protocol=1
- Для активации "STOP SLAVE; START SLAVE;"
IV. Для некоторых сред основным моментом является то, что в файлах relay-log присутствует большой объем ввода-вывода.
Это создает проблемы даже для некоторых SSD дисков и потому является убийцей для HDD.
Таким образом, мы просто перемещаем все в оперативную память и получаем прирост производительности в несколько раз.
- Сделаем диск с оперативной памятью
Например, в /tmp dir
Редактируем /etc/fstab, чтобы было что-то вроде:
tmpfs /tmp tmpfs по умолчанию,noatime,nodiratime,nosuid,nodev,mode=1777,size=1500M 0 0
И в нем
смонтируем -o remount /tmp
- Добавим в /etc/mysql/my. cnf
relay_log_space_limit=500M # ограничение на размер всех лог-файлов для сохранения небольшого диска tmpfs
max_relay_log_size=100M; # должно быть как минимум в два раза меньше, чем лимит пространства
relay-log = /tmp/YOUR_HOSTNAME-relay-bin
master-info-файл = /tmp/master. info
relay-log-info-file = /tmp/relay-log.info
Purge\resize текущий релейный журнал, если он слишком велик, прежде чем добавлять утверждения о новом пути
Shutdown slave
Move YOUR_HOSTNAME-relay-bin, master. информация, релейный журнал. info из текущего местоположения (по умолчанию /var/lib/mysql) в /tmp
- Не забудьте "chown mysql: mysql", которые файлы
Вы можете, но, возможно, не захотите использовать этот способ долгое время из-за последствий последующих перезагрузок и грубых методов, чтобы избежать ошибок после них (например, slave- skip-errors = 1062,1032,1396)
Но
это способ быстро наверстать натянутый случай
иногда это единственный способ из-за нехватки ресурсов