слейве? Использую multi channel репликацию, один канал быстро засинкался, а по второму очень медленно, висит на этапе Waiting for dependent transaction to commit, при том что сейчас ночь, и запросов на мастер почти что нет, блокирующих тоже.
а на реплике нет запросов которые могут блокировать ? попробуйте разорвать все, даже неактивные, коннекты, которые установлены дольше чем seconds behind master секунд
Юзеры с привелегиями только select могут также создавать блокирующие запросы?
Очень давно задавал этот и похожие вопросы, суть проблемы: слейв очень медленно догонял мастер (master percona 5.7 -> slave percona 8.0). Решилось банально, но не ясно, почему: добавили PRIMARY KEY для таблиц. Отставание теперь нулевое, мускул на слейве перестал держать постоянно одно ядро в нагрузке.
>One another reason for the delay on slave SQL_THREAD if you use row-based binlog format is that if your any database table missing is primary key or unique key then it will scan all rows of the table for DML on slave and causes replication delays so make sure all your tables should have primary key or unique key.
Обсуждают сегодня