Niekompletny mysqldump

Próbuję uruchomić mysqldump, aby utworzyć migawkę bazy danych, i okazuje się, że losowo zatrzyma się w połowie, bez zgłaszania żadnego błędu. Moja baza danych jest stosunkowo niewielka (około 100 MB) i używa InnoDB.

Używam go w następujący sposób:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Sprawdzanie raportów kodów wyjścia 0.

Moja wersja to: mysqldump Ver 10.13 Distrib 5.1.52, dla redhat-linux-gnu (i386)

Widziałem kilka podobnych postów, a nawet oficjalny raport o błędach , ale żadne z rozwiązań nie wydaje się mieć zastosowania.

Jak zdobyć mysqldump, aby zrobił pełną migawkę bazy danych?

EDYCJA: Moja baza danych obecnie znajduje się na RDS Amazon.

Być może problem polegał na max_allowed_packettym, że nie został ustawiony wystarczająco wysoko zarówno na kliencie (tj. Mysqldump), jak i na serwerze (np. Amazon RDS). Ustawiłem to na 500 M na obu i wydaje się, że to rozwiązało problem.

Ponieważ tabele schematów informacyjnych InnoDB podają tylko szacunkowe liczby wierszy, trudno powiedzieć, czy moja migawka naprawdę zawiera wszystko z RDS. Wszystkie tabele są dostępne, ale liczba wierszy jest różna. Zaktualizuję z bardziej jednoznaczną odpowiedzią, gdy będę miał trochę czasu na napisanie dokładniejszej analizy.

Czy próbowałeś?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

Jest to prosty sposób, w jaki zawsze to robię bez żadnych problemów. Zasadniczo zrobienie zrzutu w ten sposób pozwala uzyskać wszystko, co masz (dane, obiekty i czasami cenne komentarze) w pewnym momencie, ignorując niezamówione transakcje.

O ile rozumiem mysql docs - pojedyncza transakcja zakończy się niepowodzeniem, jeśli odczyt zostanie wykonany na stole podczas zrzutu. Jaki jest wynik działania bez „--force --single-transaction -quick”?

Całkiem możliwe, że tabela jest uszkodzona. Nie mam na myśli, że dane i / lub strony indeksu są uszkodzone. Może być coś bardzo prostego, co jest zepsute.

Niedawno wystąpił problem ze skryptem kopii zapasowej na serwerze Slave, gdy równolegle mysqldumped wiele baz danych. Uruchomienie mysqldump na jednej z baz danych spowodowało bardzo mały mysqldump. DB miał ponad 80 tabel. Jednak mysqldump zatrzymał się przy piątej tabeli w bazie danych. Kiedy pobiegłem SHOW CREATE TABLE tblname\Gpo stole w Slave, dostałem błąd „Nie znaleziono stołu”. Kiedy pobiegłemSHOW CREATE TABLE tblname\G Master, opis tabeli wyświetlany jest zgodnie z oczekiwaniami.

To, co się stało, było trochę szalone: ​​klient poprosił o przywrócenie tabeli, a inżynier przywrócił plik .ibd tabeli InnoDB z kopii zapasowej dysku. Identyfikator obszaru tabel pliku .ibd (który wynosił 25) nie zgadzał się z identyfikatorem obszaru tabel zarejestrowanego w ibdata1 (który wynosił 28).

Rozwiązałem problem, węsząc niewolnika, mysqldumping mistrza i konfigurując replikację od zera. Na szczęście zakres danych i indeksów wyniósł 7 GB. Tak więc proces rstore nie był wielkim problemem.

MORAŁ HISTORII

Podstawowym problemem jest to, że mysqldump nie zgłasza błędu w InnoDB, gdy identyfikator obszaru tabel jest niepoprawny. Gdy mysqldump kończy i nie zrzuca każdej tabeli w kolejności alfabetycznej, oznacza to, że zakończyła się błędem i zrobiła to bez drukowania komunikatu o błędzie.

Sprawdź, aby się upewnić

• możesz wyświetlić strukturę tabeli za pomocą SHOW CREATE TABLE
• możesz zapytać o wszystko o tabeli z INFORMACJE_SCHEMA.TABLES

Oto burza mózgów na mysqldump i InnoDB:

Proszę pomyśleć o zachowaniu mysqldump względem tabeli InnoDB. Jeśli w puli buforów InnoDB są jakieś brudne strony należące do tabeli, którą zrzucasz, brudne strony tej tabeli muszą zostać wypłukane na dysk, zanim będzie SELECT /* SQL_NO_CACHE */można wykonać przeciwko niej.

Ponieważ używasz Amazon RDS, mam przeczucie, że twoja baza danych jest w infrastrukturze wielodostępnej (możesz to poprawić, jeśli upraszczam to). Inne bazy danych mogą korzystać ze współużytkowanej puli buforów InnoDB, udostępnionego pliku metadanych (ibdata1) i udostępnionego obszaru tabel (ibdata1, jeśli opcja innodb_file_per_table jest wyłączona).

Może również wystąpić pewna nadmiarowość bazy danych, co może mieć wpływ na MVCC względem bazy danych, nawet jeśli jest to niewielki zestaw danych.

Możesz zwiększyć innodb_lock_wait_timeout (domyślnie 50 sekund) w sesji mysqldump, aby sprawdzić, czy ma to jakikolwiek wpływ na Amazon RDS (lub Amazon może zwiększyć ten limit). Spróbuj także eksperymentować z zrzucaniem pojedynczych tabel.

AKTUALIZACJA 14.11.2011 17:58 EDT

Spróbuj wykonać to w ramach sesji DB (ustawia się na dwie minuty):

SET innodb_lock_wait_timeout = 120;