Czy możesz mi pomóc zrozumieć, dlaczego po pełnej ponownej synchronizacji otrzymuję „Zduplikowany wpis klucza podstawowego” na serwerze podrzędnym.

Zasadniczo „mysqldump” działał prawie całą noc, a następnie proces przywracania trwał kilka godzin, więc kiedy uruchomiłem slave, było około 63874 sekund za mistrzem.

Serwer podrzędny jest tylko do odczytu (tylko do odczytu) i podczas procesu ponownej synchronizacji nie było żadnych zapisów, więc nie rozumiem, dlaczego istnieją duplikaty kluczy.

Format dziennika binarnego jest ustawiony na MIXED na master.

Polecenie użyte do utworzenia kopii zapasowej bazy danych:

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

Slave replikuje tylko jedną bazę danych z master (db -> db_backup) z następującymi opcjami:

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

ASPEKT nr 1: Replikacja

Nie wydaje mi się

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

stanowić całość.

Inni też się nad tym zastanawiali

• Jun 14, 2012: Skonfigurowana replikacja MySQL, ale nie działa
• Jun 13, 2012: Jaka jest różnica między „replicate-rewrite-db” i „replicate-do-db” podczas replikacji mysql?
• May 31, 2012: Mysql replicate-rewrite-db nie działa

Problem wynika z przetwarzania reguł replikacji zamówień. Zgodnie z dokumentacją MySQL dotyczącą reguł replikacji :

Jeśli podano jakieś opcje --replicate-rewrite-db, są one stosowane przed przetestowaniem reguł filtrowania --replicate- *.

Nawet dokumentacja MySQL na replicate-rewrite-db mówi:

Tłumaczenie nazw bazy danych jest wykonywane przed przetestowaniem reguł --replicate- *.

replicate-wild-do-tableJest egzekwowane po przepisać. Nie byłoby zaskoczeniem, gdyby to uporządkowanie w jakiś sposób narzuciło WSTAW do tabeli, która już zawiera dane.

Prawdopodobnie pytasz, skąd się wzięły dane?

ASPEKT 2: mysqldump

Robi mysqldump --single-transactionwydaje się być największym sposobem point-in-time wysypisk danych. Niestety, mysqldump --single-transactionma piętą achillesową: ALTER TABLE. Jeśli tabela podlega jakimkolwiek ALTER TABLEpoleceniom, takim jak a, DROP TABLEi CREATE TABLEktóre mogą zepsuć integralność transakcji, mysqldump próbował wykonać zrzut. Obcinanie tabeli (która jest DDL we Wszechświecie MySQL) oraz upuszczanie i dodawanie indeksów może również być tak samo destrukcyjne.

Więcej informacji na ten temat można znaleźć w najlepiej strzeżonym MySQLDump Secret MySQL Performance Blog . Właściwie zająłem się tym punktem w poprzednim pytaniu opisującym 12 poleceń, które mogą złamać integralność transakcji mysqldump: kopia zapasowa MySQL InnoDB

CAVEAT

• Osobiście zmieniłbym format binarny na STATEMENT
• Jak powiedziałem w kopii zapasowej MySQL InnoDB , powinieneś mieć innego urządzenia podrzędnego (bez filtrów replikacji) przeznaczonego do robienia mysqldumps.
• Ponad 63000 sekund za nami? Powinieneś rozważyć zrzuty tabel równoległych: Jak mogę zoptymalizować mysqldump dużej bazy danych?

EPILOG

Jeden lub oba aspekty mogły przyczynić się do wypuszczenia wiersza podczas mysqldump, który nie powinien istnieć z powodu reguł przepisywania lub izolacji mysqldump.

PROPOZYCJE

Zrobiłbym zrzut mysqlbinlog wszystkich dzienników przekazywania od początku mysqldump, aby zobaczyć wszystkie WSTAWKI przetwarzane przez Slave i sprawdzić, czy te wiersze już istnieją w Slave. Jeśli tak, prawdopodobnie możesz zrobić dwie rzeczy:

1: Pomiń wszystkie błędy klucza duplikatu

Po prostu dodaj to do my.cnf w Slave

[mysqld]
slave-skip-errors=1062
skip-slave-start

i zrestartuj mysql. Następnie uruchomićSTART SLAVE;

wszystkie błędy klucza duplikatu zostaną pominięte. Gdy Seconds_Behind_Masterdojdzie do 0, usuń te linie i uruchom ponownie mysql.

2: Pobierz narzędzia Percona

Potrzebne są narzędzia

• suma kontrolna pt-table
• pt-table-sync

Użyj ich, aby znaleźć różnice w Slave, a następnie je popraw

Sprawdź zapytanie wstawiania w kodzie, które wstawia bezpośrednio do urządzenia podrzędnego. Możemy czytać tylko z niewolnika. Napisz zapytania powinny być kierowane do mistrza.