Replikacja MySql-slave w tyle za master

Jakiego formatu dziennika binarnego używasz ? Używasz ROW czy STATEMENT ?

SHOW GLOBAL VARIABLES LIKE 'binlog_format';

Jeśli używasz ROW jako formatu binloga, upewnij się, że wszystkie tabele mają klucz podstawowy lub unikalny:

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;

Jeśli wykonasz np. jedną instrukcję delete na master, aby usunąć 1 milion rekordów z tabeli bez klucza PK lub unique, to tylko jedno pełne skanowanie tabeli będzie miało miejsce po stronie master, co nie ma miejsca w przypadku slave.

Gdy używany jest wiersz binlog_format, MySQL zapisuje zmiany wierszy do dzienników binarnych (nie jako instrukcja jak instrukcja binlog_format) i ta zmiana zostanie zastosowana na stronie slave wiersz po wierszu, co oznacza, że pełne skanowanie tabeli 1 mln odbędzie się na slave, aby odzwierciedlić tylko jedną instrukcję delete na master i to powoduje problem opóźniania slave.

"seconds behind"nie jest zbyt dobrym narzędziem, aby dowiedzieć się, jak bardzo jesteś za mistrzem. To, co mówi, to "zapytanie, które właśnie wykonałem, zostało wykonane X sekund temu NA master". To nie znaczy, że dogonisz mistrza i będziesz tuż za nim w następnej sekundzie.

Jeśli twój niewolnik zwykle nie pozostaje w tyle, a obciążenie pracą na master jest z grubsza stałe, nadrobisz zaległości, ale może to zająć trochę czasu, może nawet zająć "wieczność", jeśli niewolnik jest normalnie ledwo nadążam za mistrzem. Niewolniki działają na jednym wątku, więc jest on z założenia znacznie wolniejszy niż master, również jeśli istnieją pewne zapytania, które zajmują trochę czasu na master, blokują replikację podczas pracy na slave.

Po prostu sprawdź, czy masz ten sam czas i strefy czasowe na obu serwerach, tj. Master jak i Slave.

Jeśli używasz tabel INNODB, sprawdź, czy masz innodb_flush_log_at_trx_commit do wartości innej niż 0 W SLAVE.

Http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

Mieliśmy dokładnie ten sam problem po skonfigurowaniu naszego slave Z ostatniej kopii zapasowej.

Zmieniliśmy konfigurację naszego slave, aby była bardziej bezpieczna dla awarii:

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

Myślę, że szczególnie sync_binlog = 1 powoduje problem, ponieważ specyfikacja tego slave nie jest tak szybka jak w master. Ta opcja konfiguracyjna zmusza slave Do Przechowywania każdej transakcji w binarnym lo przed ich wykonaniem (zamiast domyślnej co 10K transakcji).

Po wyłączeniu tych opcje config ponownie do ich wartości domyślnych widzę, że slave znowu nadrabia zaległości.

Dodam tylko wyniki w moim podobnym przypadku.

Było kilka masowych tymczasowych Wstaw/update/delete tabeli w master, które zajmowały większość miejsca z Relay log in slave. A w Mysql 5.5, ponieważ był jednowątkowy, procesor był zawsze w 100% i zajęło dużo czasu, aby przetworzyć te rekordy.

Jedyne co zrobiłem to dodanie tych linii w pliku mysql cnf

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

In order to figure out which tables are taking więcej miejsca w dzienniku przekaźników, spróbuj wykonać następujące polecenie, a następnie otwórz w edytorze tekstu. Możesz uzyskać kilka wskazówek

cd /var/lib/mysql
mysqlbinlog relay-bin.000010 > /root/RelayQueries.txt
less /root/RelayQueries.txt

JEŚLI U Masz wiele schematów rozważ użycie wielowątkowej replikacji slave.Jest to stosunkowo nowa funkcja.

Można to zrobić dynamicznie bez zatrzymywania serwera.Wystarczy zatrzymać wątek SQL slave.

STOP SLAVE SQL_THREAD;
SET GLOBAL slave_parallel_threads = 4;
START SLAVE SQL_THREAD;