Я ищу указатели на то, как улучшить скорость репликации подчиненного сервера mysql. Он достаточно быстр для нормального производства, но ему нужно много времени, чтобы наверстать упущенное, если по какой-то причине он отстает. (Если сервер был выключен или репликация остановлена на несколько часов и т. Д.)
Некоторые данные:
Что можно сделать, чтобы повысить эту скорость?
(Да, улучшение оборудования - это вариант, но мы хотим убедиться, что проверили другие варианты, прежде чем тратить много денег)
Редактировать:
Некоторые данные в ответ на вопрос @ 3molo:
Если узким местом являются диски (установка 6-дискового рейда 10), есть ли какие-либо варианты, кроме увеличения рейда, или мы должны пойти с этим?
Было бы интересно записать, пока нагоняете:
какая пропускная способность используется
насколько загружен процессор (особенно ожидание ввода-вывода)
использование тарана
В ответ на новую информацию о высоком уровне ожидания ввода / вывода; для innodb можно многое сделать, посмотрите. Я многому научился из mysqlperformanceblog. Вот несколько советов:
innodb_flush_method = O_DIRECT
«Избегайте двойной буферизации и уменьшайте нагрузку на своп, в большинстве случаев этот параметр улучшает производительность. Хотя будьте осторожны, если у вас нет резервной копии кэша RAID, поскольку при записи может пострадать ввод-вывод».
innodb_flush_log_at_trx_commit = 2
«Если вас не беспокоит ACID и вы можете потерять транзакции в течение последних двух или двух секунд в случае полного сбоя ОС, установите это значение. Это может сильно повлиять, особенно на большое количество коротких транзакций записи».
Это ЧУДО для нас, но недостатком является то, что вы можете потерять секунду записанных данных. Это потому, что вместо записи (сброса на диск) каждой записи вы сбрасываете каждую секунду.
Вы можете прочитать больше: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
Репликация MySQL быстрая, очень быстрая. Его основное ограничение - это уровень связи, а затем остальное оборудование.
В вашем случае возобновление репликации, вероятно, покажет, что двоичные журналы или подчиненный ввод-вывод довольно быстро догоняют. Если нет, сначала улучшите свою ссылку. В противном случае, если это SQL, у вас будут физические ограничения сервера, которые будут варьироваться между дисковым вводом-выводом, ОЗУ и ЦП в зависимости от типа нагрузки.
I. Добавьте небольшие, но простые оптимизации ввода-вывода для информационных файлов.
sync_relay_log_info = 5000000
sync_master_info = 5000000
II. Используйте многопоточность (могут быть худшие результаты)
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
III. Если у вас проблемы с пропускной способностью, попробуйте использовать сжатие
slave_compressed_protocol = 1
IV. Для некоторых сред главное - в файлах журнала реле есть большие операции ввода-вывода.
Это создает проблемы даже для некоторых SSD-накопителей и, конечно, убийственно для HDD.
Итак, мы просто перемещаем все в оперативную память и получаем прирост производительности в несколько раз.
Например в каталоге / tmp
Отредактируйте / etc / fstab, чтобы получилось что-то вроде:
tmpfs / tmp tmpfs по умолчанию, noatime, nodiratime, nosuid, nodev, mode = 1777, size = 1500M 0 0
И запустите это
монтировать -o remount / tmp
relay_log_space_limit = 500M # ограничение размера для всех файлов журнала для сохранения вашего небольшого диска tmpfs
max_relay_log_size = 100 МБ; # должно быть как минимум вдвое меньше предела пробела
relay-log = / tmp / YOUR_HOSTNAME-relay-bin
главный-информационный-файл = /tmp/master.info
реле-журнал-информация-файл = /tmp/relay-log.info
Очистите \ измените размер текущего журнала реле, если он слишком велик, перед добавлением операторов нового пути
Завершение работы ведомого
Переместите YOUR_HOSTNAME-relay-bin, master.info, relay-log.info из текущего местоположения (по умолчанию / var / lib / mysql) в / tmp
Вы можете, но, возможно, не захотите использовать этот способ в течение длительного времени из-за последствий дальнейших перезагрузок и грубых методов, чтобы избежать ошибок после них (например, slave-skip-errors = 1062,1032,1396)
Но
это способ быстро наверстать упущенное
иногда это единственный выход из-за нехватки ресурсов