SZYBKIE zrzucanie wyciszonej bazy danych:
Użycie opcji "-T" z mysqldump powoduje powstanie wielu plików .sql i .txt w określonym katalogu. Jest to ~50% szybsze w przypadku zrzucania dużych tabel niż pojedynczy plik .sql z instrukcjami INSERT (zajmuje 1/3 mniej czasu na zegarze ściennym).
Ponadto istnieje ogromna korzyść podczas przywracania, jeśli można załadować wiele tabel równolegle i nasycić wiele rdzeni. Na 8-rdzeniowej obudowie może to być nawet 8-krotna różnica w czasie zegara ściennego, aby przywrócić zrzut, oprócz poprawy wydajności zapewnianej przez „-T”. Ponieważ "-T" powoduje, że każda tabela jest przechowywana w osobnym pliku, ładowanie ich równolegle jest łatwiejsze niż dzielenie ogromnego pliku .sql.
Biorąc powyższe strategie do ich logicznego ekstremum, można by stworzyć skrypt do równoległego zrzucania bazy danych. Cóż, to jest dokładnie to, co Maakit mk-parallel-dump (patrz http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) i narzędzia mk-parallel-restore są; skrypty perla, które wykonują wiele wywołań do bazowego programu mysqldump. Jednak gdy próbowałem ich użyć, miałem problem z ukończeniem przywracania bez zduplikowanych błędów kluczowych, które nie występowały w przypadku zrzutów waniliowych, więc pamiętaj, że Twój przebieg może się różnić.
Zrzucanie danych z bazy danych LIVE (bez przerwy w świadczeniu usług):
Przełącznik --single-transaction jest bardzo przydatny do robienia zrzutu działającej bazy danych bez konieczności jej wyciszania lub robienia zrzutu podrzędnej bazy danych bez konieczności zatrzymywania podrzędnej bazy danych.
Niestety -T nie jest kompatybilne z --single-transaction, więc dostajesz tylko jedną.
Zwykle wykonanie zrzutu jest znacznie szybsze niż jego przywracanie. Nadal jest miejsce na narzędzie, które pobiera przychodzący monolityczny plik zrzutu i dzieli go na wiele części, aby można je było ładować równolegle. Według mojej wiedzy takie narzędzie jeszcze nie istnieje.
Przesyłanie zrzutu przez sieć jest zwykle wygraną
Aby nasłuchiwać przychodzącego zrzutu na jednym uruchomieniu hosta:
nc -l 7878 > mysql-dump.sql
Następnie na hoście DB uruchom
mysqldump $OPTS | nc myhost.mydomain.com 7878
Zmniejsza to rywalizację o wrzeciona dysków w systemie głównym z zapisywaniem zrzutu na dysk, nieznacznie przyspieszając zrzut (przy założeniu, że sieć jest wystarczająco szybka, aby nadążyć, co jest dość bezpiecznym założeniem dla dwóch hostów w tym samym centrum danych). Dodatkowo, jeśli budujesz nowe urządzenie podrzędne, oszczędza to kroku związanego z koniecznością przesłania pliku zrzutu po jego zakończeniu.
Ostrzeżenia - oczywiście musisz mieć wystarczającą przepustowość sieci, aby nie spowalniać rzeczy nieznośnie, a jeśli sesja TCP zostanie przerwana, musisz zacząć od początku, ale w przypadku większości zrzutów nie jest to poważny problem.
Na koniec pragnę wyjaśnić jeden wspólny punkt niejasności.
Pomimo tego, jak często widzisz te flagi w przykładach mysqldump i samouczkach, są one zbędne, ponieważ są domyślnie WŁĄCZONE:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Od http://dev.mysql.com/doc/refman/ 5.1/pl/mysqldump.html :
Spośród tych zachowań, "--quick" jest jednym z najważniejszych (pomija buforowanie całego zestawu wyników w mysqld przed przesłaniem pierwszego wiersza) i może być z "mysql" (które NIE włącza --quick domyślnie) radykalnie przyspieszyć zapytania, które zwracają duży zestaw wyników (np. zrzucanie wszystkich wierszy dużej tabeli).
