Репликация MySql - ведомый, отстающий от хозяина - PullRequest
10 голосов
/ 18 декабря 2011

У меня есть репликация master / slave в моей базе данных MySql.

моя подчиненная база данных не работала в течение нескольких часов и снова работает (мастер все время работал) при выдаче show slave status Iможно видеть, что ведомое устройство отстает от мастера на X секунд.

проблема в том, что ведомое устройство, кажется, не догоняет мастера, кажется, что X секунд позади ведущего устройства не падают ...

какие-нибудь идеи о том, как я могу помочь рабу догнать?

Ответы [ 8 ]

16 голосов
/ 18 декабря 2011

Вот идея

Чтобы вы знали, что MySQL полностью обрабатывает SQL из журналов ретрансляции. Попробуйте следующее:

STOP SLAVE IO_THREAD;

Это остановит репликацию от загрузки новых записей от мастера в его журналы ретрансляции.

Другой поток, известный как поток SQL, продолжит обрабатывать операторы SQL, загруженные из мастера.

Когда вы запускаете SHOW SLAVE STATUS\G, следите за Exec_Master_Log_Pos. Запустите SHOW SLAVE STATUS\G снова. Если Exec_Master_Log_Pos не движется через минуту, вы можете продолжить START SLAVE IO_THREAD;. Это может уменьшить количество Seconds_Behind_Master.

Кроме этого, вы ничего не можете сделать, кроме как:

  • Доверительная репликация
  • Монитор Seconds_Behind_Master
  • Монитор Exec_Master_Log_Pos
  • Запустите SHOW PROCESSLIST;, обратите внимание на поток SQL, чтобы увидеть, обрабатывает ли он долго выполняющиеся запросы.

Кстати, имейте в виду, что при запуске SHOW PROCESSLIST; с запущенной репликацией должно быть два соединения с БД с именем пользователя system user. У одного из этих соединений с БД будет текущий оператор SQL, обрабатываемый репликацией. Если при каждом запуске SHOW PROCESSLIST; отображается различный оператор SQL, вы можете быть уверены, что mysql по-прежнему правильно реплицируется.

7 голосов
/ 04 июля 2014

Какой двоичный формат журнала вы используете? Вы используете ROW или STATEMENT?

SHOW GLOBAL VARIABLES LIKE 'binlog_format';

Если вы используете ROW в качестве формата binlog, убедитесь, что все ваши таблицы имеют первичный или уникальный ключ:

SELECT t.table_schema,t.table_name,engine
FROM information_schema.tables t
INNER JOIN information_schema .columns c
on t.table_schema=c.table_schema
and t.table_name=c.table_name
and t.table_schema not in ('performance_schema','information_schema','mysql')
GROUP BY t.table_schema,t.table_name
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Если вы выполните, например, один оператор удаления на главном сервере, чтобы удалить 1 миллион записей в таблице без PK или уникального ключа, тогда только одна полная проверка таблицы будет выполнена на стороне главного устройства, что не имеет места на ведомом устройстве.

Когда используется ROW binlog_format, MySQL записывает изменения строк в двоичные журналы (не как оператор, такой как STATEMENT binlog_format), и это изменение будет применяться на стороне ведомого строка за строкой, что означает полное сканирование таблицы на 1 миллион будет происходить на подчиненном устройстве, чтобы отразить только один оператор удаления на главном устройстве, и это вызывает проблему отставания подчиненного устройства.

3 голосов
/ 18 декабря 2011

«секунды позади» - не очень хороший инструмент, чтобы узнать, насколько отстает мастер на самом деле. То, что он говорит, - «запрос, который я только что выполнил, был выполнен X секунд назад на главном». Это не значит, что в следующую секунду вы будете догонять и быть прямо позади мастера.

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

1 голос
/ 22 августа 2014

Если вы используете таблицы INNODB, убедитесь, что для innodb_flush_log_at_trx_commit установлено значение, отличное от 0 в SLAVE.

1 голос
/ 02 августа 2013

Просто проверьте, есть ли у вас одинаковые временные и часовые пояса на обоих серверах, т. Е. Как на главном, так и на ведомом.

0 голосов
/ 21 ноября 2017

Если у вас несколько схем, рассмотрите возможность использования многопоточной подчиненной репликации. Это относительно новая функция.

Это можно сделать динамически, не останавливая сервер. Просто остановите поток подчиненного sql.

STOP SLAVE SQL_THREAD;
SET GLOBAL slave_parallel_threads = 4;
START SLAVE SQL_THREAD;
0 голосов
/ 21 июня 2016

Просто чтобы добавить выводы в моем аналогичном случае.

Было несколько массовых вставок / обновлений / удалений временных таблиц в master, которые занимали большую часть пространства из журнала ретрансляции в slave.А в Mysql 5.5, поскольку он был однопоточным, процессор всегда был на 100% и занимал много времени для обработки этих записей.

Все, что я сделал, это добавил строку в mysql cnf file

replicate-ignore-table=<dbname>.<temptablename1>
replicate-ignore-table=<dbname>.<temptablename2>

и все снова стало гладким.

Чтобы определить, какие таблицы занимают больше места в релейном журнале, попробуйте следующую команду, а затем откройте в текстовом редакторе.Вы можете получить некоторые подсказки

cd /var/lib/mysql
mysqlbinlog relay-bin.000010 > /root/RelayQueries.txt
less /root/RelayQueries.txt
0 голосов
/ 24 января 2016

У нас возникла точно такая же проблема после настройки нашего ведомого из последней резервной копии.

Мы изменили конфигурацию нашего ведомого устройства, чтобы сделать его более защищенным от сбоев:

sync_binlog = 1
sync_master_info = 1
relay_log_info_repository = TABLE
relay_log_recovery = 1

Я думаю, что именно sync_binlog = 1 вызывает проблему, поскольку спецификации этого ведомоготак быстро, как в мастере.Эта опция конфигурации заставляет подчиненное устройство хранить каждую транзакцию в двоичном lo до того, как они будут выполнены (вместо значения по умолчанию каждые 10 000 транзакций).

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

...