MySQL slave. Отставание. Как сократить?

Question

[Сергей Ливитин]

Два сервера, оба виртуальные:
1. Master. HP Proliant DL560 G8 650GB RAM, 32vCPU. CentOS 7.2.1511 (Core). MySQL community 5.6.29-2.el7. База, примерно 2.3TB. Сетевое подключение - 10Gb/s.
2. Slave. HP Proliant DL560 G8 524Gb RAM, 32vCPU. CentOS 6.6 (Final). MySQL community 5.6.29-2.el6. Сетевое подключение - 10Gb/s
Все диски расположены на SAN-полках (FC 8Gb/s)
Как работает:
1. Клиенты пишут в мастер, а если есть запросы на чтение (преимущественно) - из слейва.
2. В пике, слейв отстаёт почти на 2000 секунд, а то и немногим более.
Какие есть варианты сокращения отставания?

Comments

[Alexandr]

А отстает почему, выяснили? производительности чего не хватает?

[Сергей Ливитин]

Сегодня получу данные по производительности на пике. Но по ощущениям слейв работает быстрее мастера. Так как одна и та же операция с очень большими таблицами на слейве отрабатывает процентов на 35 быстрее. Процессорный пул загружен не сильно даже в пике (на слейве). Основной показатель по дискам (чтение) быстрее чем на мастере. Думаю, что вот причина может быть в чём:
на мастере запросы выполняются параллельно, а на слейв передаются в виде бин-логов последовательно. Может быть из-за этого? Получается, что для уменьшения отставания слейв должен быть раза в 2 быстрее мастера по всем показателям? :)

Answer 1

[Владимир]

на слейве какое у вас значение innodb_flush_log_at_trx_commit ? 0 ставили или опасаетесь ?
slave_parallel_workers используете ?

Answer 2

[Сергей Ливитин]

Вопрос решили.
1. По совету перлового скрипта по MySQL тюнингу произвели изменения на SLAVE.
2. Отключили двойную проверку записи.
Теперь отставание минимально... Вернее его вообще нет. :)

Comments

[AlikDex]

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

[entermix]

AlikDex: +1

Answer 3

[Артемий]

Как увеличить производительность репликации MySQL

Comments

[Сергей Ливитин]

Эта ссылка рассказывает как уберечься от нагрузки на сетевой интерфейс мастера при репликации на множество слейвов. У нас не те проблемы. Подключение 10Gb/s.

[Артемий]

А Вы лог и данные по разным носителям разнесли на мастере? Какой движок базы данных стоит на слейве и не замедляет ли его нагрузка по чтению? В принципе у Вас слэв мощный может на не нем два слейва вместо одного поднять и по дискам разнести данные и логи.
Там внизу список из 4-х пунктов по Вашей теме.

[Сергей Ливитин]

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

[Артемий]

Ну да, они конкурируют между собой за устройство. Я думаю Вам в целом надо для террабайтной базы на хайлоад решение сдвигаться надо. Либо как мимнимум с comunity на entrpise версии переходить.

[Сергей Ливитин]

Переходить на Enterprise скорее всего не будем. Переделываем систему. А Enterprise стоит денег.

[Артемий]

Желаю удачи в этом не легком деле!

[AlikDex]

Сергей Ливитин: запилите пост на хабре, если не сложно, с решением вопроса =)

Answer 4

[Сергей Рогожкин]

Если сократить подробности, репликация идет в один поток, что и является узким местом. Даже если слейв в 10 раз быстрее, это все равно упрется в 1 поток на мастере.

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