LINUX.ORG.RU

MySQL replication

 , ,


0

3

Всем привет, нужен ваш совет: Есть Mysql репликация и на мастере очень интенсивно идут - INSERT and DELETE. Слейв не может с этим справиться и постоянно отстает, проблему с инсертами я решил, установил mysql fetcher, но он обрабатывает только UPDATE and INSERT, и я уже не знаю как можно ускорить репликацию.


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

TERRANZ ★★★★
()

Во что упирается, диск, сеть, cpu, конфиг? надо сначала понять, потом оптимизировать

mysql fetcher

Это еще что? не гуглится

disarmer ★★★
()
Ответ на: комментарий от TERRANZ

В норме при асинхронной репликации слэйв всегда отстаёт от мастера на время от нуля до некоторого значения (собственно задержка репликации).

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

На сколько я понимаю надо либо разгрузить слэйв (например добавить ещё один слэйв, или заапгрэйдить сервер, или подтюнить настройки), либо уменьшить интенсивность записи (например загрузить мастер, что-бы он писал не быстрее чем слэйв :)

MrClon ★★★★★
()

Слейв разгребает все изменения с мастера в 1 поток, это основная причина, почему он медленнее. Из вариантов - индексы на мастере и на слейве разные, поэтому какой-нибудь адский update может быстро делаться на мастере и медленно на слейве. Может так-же помочь смена фомата бинлогов(binlog_format), по-дефолту она вроде STATEMENT, что говорит реплике выполнять все те-же запросы что и мастер, но есть еще RAW или MIXED, которые содержат не сами запросы, а дифф данных. Но если это и поможет, то только после того, как реплика догонится до того момента, когда поменялся формат бинлогов. Слышал, в одной из последний версий mysql (вроде 5.7) сделана multithread-репликация, тоже может помочь.

anonymous
()

Если в mysql несколько несвязанных между собой баз данных (каталогов), можно включить параллельную репликацию в 5.6

Если MIXED или ROW формат бинлога, то проверить, что на все таблицы есть PRIMARY или UNIQUE NOT NULL индексы.

На слейве обычно нет нужды в 100% устойчивости к резету, поэтому innodb_flush_log_at_trx_commit = 2 (если на слейве уже рейд контроллер с работающей батарейкой BBU за $700-1000 то эта тема поможет не сильно).

Если на слейве включен бинлог, то скорее всего его нужно отключить, т.к. он не нужен а цепочки слейвов это головная боль.

Часто сервера не настроены на оптимальную вставку/удаление: innodb_log_file_size надо выбрать таким, чтобы LSN занимал оба файла за час-полтора минимум (на логах больше 8GB бывают нюансы, для начала можно попробовать 128 или 256 (2 дефолтных лога будут 256 или 512 суммарно))

Фетчеры бинлогов должны быть достаточно интелектуальными чтобы был эффект, например https://github.com/yoshinorim/replication-booster-for-mysql

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.