--single-transactionOpcja mysqldump nie zrobić FLUSH TABLES WITH READ LOCKprzed rozpoczęciem zadania kopii zapasowej , ale tylko pod pewnymi warunkami. Jednym z tych warunków jest podanie --master-dataopcji.
W kodzie źródłowym z mysql-5.6.19/client/mysqldump.cwiersza 5797:
if ((opt_lock_all_tables || opt_master_data ||
(opt_single_transaction && flush_logs)) &&
do_flush_tables_read_lock(mysql))
goto err;
Aby uzyskać solidną blokadę dokładnych współrzędnych binlog przed rozpoczęciem transakcji z powtarzalnym odczytem, --master-dataopcja wyzwala tę blokadę, a następnie zostaje zwolniona po uzyskaniu współrzędnych binlog.
W rzeczywistości mysqldumprobi FLUSH TABLESnastępnie przez FLUSH TABLES WITH READ LOCKbo robi obie rzeczy umożliwia odczyt blokady należy uzyskać szybciej w przypadku, gdy początkowa równo zajmuje trochę czasu.
...jednak...
Jak tylko uzyska współrzędne binlog, mysqldumpwydaje UNLOCK TABLESpolecenie, więc nic nie powinno blokować w wyniku rozpoczętego koloru. Żaden wątek nie powinien być Waiting for table flushrównież wynikiem wstrzymanej transakcji mysqldump.
Gdy zobaczysz wątek w Waiting for table flushstanie, powinno to oznaczać, że FLUSH TABLES [WITH READ LOCK]instrukcja została wydana i nadal działała w momencie rozpoczęcia zapytania - więc zapytanie musi poczekać na opróżnienie tabeli, zanim będzie mogło zostać wykonane. W przypadku opublikowanej listy procesów mysqldumpczyta się z tej samej tabeli, a zapytanie działa od jakiegoś czasu, ale zapytania blokujące nie blokowały się tak długo.
To wszystko sugeruje, że wydarzyło się coś innego.
Istnieje wewnętrzny problem wyjaśniony w błędzie nr 44884 dotyczący sposobu FLUSH TABLESdziałania wewnętrznego. Nie zdziwiłbym się, gdyby problem nadal występował, byłbym zaskoczony, gdyby problem ten został kiedykolwiek „rozwiązany”, ponieważ jest to bardzo złożony problem do rozwiązania - praktycznie niemożliwy do naprawienia w środowisku o wysokiej współbieżności - i każda próba naprawienie go niesie ze sobą znaczne ryzyko złamania czegoś innego lub stworzenia nowego, innego i wciąż niepożądanego zachowania.
Wydaje się prawdopodobne, że będzie to wyjaśnienie tego, co widzisz.
Konkretnie:
jeśli masz długo działające zapytanie działające na tabeli i problem FLUSH TABLES, FLUSH TABLESblokuje się, dopóki długo nie zakończy się zapytanie.
dodatkowo wszelkie zapytania rozpoczynające się po FLUSH TABLESwydaniu będą blokowane do momentu FLUSH TABLESzakończenia.
dodatkowo, jeśli zabijesz FLUSH TABLESzapytanie, blokowane zapytania będą nadal blokować oryginalne długo działające zapytanie, które blokowało FLUSH TABLESzapytanie, ponieważ mimo że zabite FLUSH TABLESzapytanie nie zakończyło się, ta tabela (ta lub więcej, zaangażowany w długo działające zapytanie) jest wciąż w trakcie opróżniania, a to oczekujące opróżnienie nastąpi zaraz po zakończeniu długo działającego zapytania - ale nie wcześniej.
Prawdopodobnym wnioskiem tutaj jest to, że inny proces - być może inny mysqldump, niewłaściwe zapytanie lub źle napisany proces monitorowania próbował opróżnić tabelę.
To zapytanie zostało następnie zabite lub przekroczone przez nieznany mechanizm, ale jego następstwa utrzymywały się aż do mysqldumpzakończenia odczytu z tabeli, o której mowa.
Możesz zreplikować ten warunek, próbując wykonać FLUSH TABLESpodczas długotrwałego zapytania. Następnie uruchom kolejne zapytanie, które zostanie zablokowane. Następnie zabij FLUSH TABLESzapytanie, które nie odblokuje ostatniego zapytania. Następnie zabij pierwsze zapytanie lub pozwól mu zakończyć, a ostatnie zapytanie zostanie pomyślnie uruchomione.
W związku z tym nie ma to związku:
Trx read view will not see trx with id >= 1252538405, sees < 1252538391
Jest to normalne, ponieważ mysqldump --single-transactionproblemy a START TRANSACTION WITH CONSISTENT SNAPSHOT, które uniemożliwiają zrzut danych, które zostały zmienione podczas zrzutu. Bez tego współrzędne binlog uzyskane na początku byłyby bez znaczenia, ponieważ --single-transactionnie byłyby tym, za co się podaje. Nie powinno to być w żaden sposób związane z Waiting for table flushproblemem, ponieważ transakcja ta oczywiście nie zawiera żadnych blokad.