Mysqldump to narzędzie klienta, które służy do wykonywania logicznych kopii zapasowych bazy danych MySQL. To popularne narzędzie do migracji jest przydatne w różnych przypadkach użycia MySQL, takich jak:
- Tworzenie kopii zapasowych i przywracanie baz danych.
- Migracja danych z jednego serwera na drugi.
- Migracja danych między różnymi zarządzanymi dostawcami usług MySQL.
- Migracja danych między różnymi wersjami MySQL.
Mysqldump działa poprzez odczytywanie obiektów źródłowej bazy danych i generowanie zestawu instrukcji SQL, które są przechowywane w pliku zrzutu. Odtwarzając te instrukcje na docelowym serwerze bazy danych, odtwarzane są oryginalne dane. Ponieważ ten model używa odczytu całej bazy danych, a następnie zasadniczo odbudowy, zarówno zrzut, jak i przywracanie są operacjami czasochłonnymi w przypadku dużej bazy danych. Proces może nawet stać się uciążliwy, jeśli wystąpią błędy podczas zrzutu lub przywracania, ponieważ może to doprowadzić do rozwiązania problemów i ponownego uruchomienia operacji. Dlatego ważne jest, aby dobrze zaplanować przed podjęciem zrzutu i przywróceniem aktywności.
W tej dwuczęściowej serii blogów omawiamy niektóre z typowych aspektów, którymi należy się zająć z góry, aby zapewnić pomyślne działanie zrzutu i przywracania. W pierwszej części skupimy się na wymaganiach wstępnych, o które należy zadbać podczas importowania danych z tabeli MySQL, a w drugiej omówimy sposób obsługi importu obiektów i widoków zapisanych w programie.
1. Wymagania dotyczące miejsca
Po pierwsze, ważne jest, aby upewnić się, że docelowa baza danych ma wystarczająco dużo miejsca na zaimportowane dane. W szczególności należy zachować ostrożność, jeśli w docelowej bazie danych MySQL włączone są dzienniki binarne, ponieważ dzienniki binarne generowane podczas importowania danych mogą mieć prawie taki sam rozmiar, jak same dane. Dzienniki binarne są potrzebne, jeśli chcesz przywrócić dane na jednym serwerze i chcesz je zreplikować. W takich przypadkach dobrym pomysłem jest zaplanowanie rozmiaru docelowego większego niż dwukrotność rozmiaru źródłowej bazy danych.
Ważne jest również zapewnienie wystarczającej ilości miejsca na woluminie, na którym generujesz plik wyjściowy mysqldump. Bez tych środków ostrożności może się zdarzyć, że zrzut lub przywrócenie zakończy się niepowodzeniem z powodu niewystarczającej ilości miejsca po długim czasie działania, co oznacza stratę czasu i wysiłku.
2. Sql_mode
Ustawienia sql_mode dla serwera MySQL określają składnię instrukcji SQL i sprawdza walidację danych, które serwer wykonuje dla operacji. Ważne jest, aby upewnić się, że sql_mode źródłowych i docelowych serwerów MySQL jest ze sobą kompatybilnych lub możesz napotkać błędy podczas przywracania wykonanego zrzutu. Zademonstrujmy to na przykładzie.
Załóżmy, że masz w źródle tabelę, w której kolumna daty zawiera wpisy jako daty zerowe:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Załóżmy, że ścisły sql_mode (i NO_ZERO_DATE ) jest wyłączone w źródle, ale włączone w miejscu docelowym – przywrócenie takich wierszy spowoduje niepowodzenie, takie jak:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Zwykle zobaczysz takie problemy, jeśli robisz zrzut kompaktowy, włączając opcję kompakt jako część mysqldump.
Jeśli kompaktowanie jest wyłączone (co jest domyślnie), nie napotkasz tego problemu, ponieważ mysqldump generuje następującą instrukcję warunkową jako część zrzutu:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Oznacza to, że podczas przywracania sql_mode jest ustawiona na 'NO_AUTO_VALUE_ON_ZERO' przed przywróceniem danych tabeli, więc przywracanie przebiegnie dobrze.
3. Unique_checks i Foreign_key_checks
Domyślnie (jeśli nie korzystasz z opcji –compact), mysqldump ustawia również:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Jak wyjaśniono tutaj, możesz przyspieszyć operację przywracania, tymczasowo wyłączając sprawdzanie unikalności podczas sesji. W przypadku dużych tabel pozwala to zaoszczędzić wiele dyskowych operacji wejścia/wyjścia, ponieważ InnoDB może używać swojego bufora zmian do zapisywania wsadowych rekordów indeksów wtórnych.
Jeśli masz FOREIGN KEY ograniczeń w twoich tabelach, możesz przyspieszyć operację przywracania tabeli, wyłączając sprawdzanie kluczy obcych na czas trwania sesji przywracania:W przypadku dużych tabel może to zaoszczędzić dużo dysku I/O.
Wyłączanie FOREIGN_KEY_CHECKS pomoże również uniknąć błędów wynikających z kontroli ograniczeń klucza obcego podczas operacji przywracania. Za każdym razem, gdy tworzona jest tabela z ograniczeniem klucza obcego, MySQL oczekuje, że tabela nadrzędna, do której odwołuje się klucz obcy, już istnieje. Jest to problem, ponieważ narzędzie mysqldump zrzuca tabele w kolejności alfabetycznej. Weźmy przykład, aby to zademonstrować.
W źródłowej bazie danych mamy dwie tabele:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
Tabela ref_table ma ograniczenie klucza obcego, które odwołuje się do solution_table . Na podstawie kolejności alfabetycznej mysqldump najpierw zrzuca zawartość ref_table . Gdy zostanie to odtworzone w momencie przywracania, zakończy się niepowodzeniem z błędem:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Co się dzieje podczas wykonywania instrukcji create table dla ‘ref_table’ .
Podsumowując, pamiętaj o problemach, które możesz napotkać, jeśli określisz --compact opcja podczas uruchamiania mysqldump.
4. Uprawnienia wymagane do uruchomienia mysqldump
Minimalne uprawnienie wymagane przez mysqldump do zrzucania bazy danych to SELECT w tej bazie danych.
Jeśli jednak Twoja baza danych posiada widoki, będziesz potrzebować również uprawnień SHOW VIEW, ponieważ mysqldump zawsze zrzuca widoki wraz z tabelami bazy danych. Załóżmy, że nie masz opcji SHOW VIEW uprawnienia, mysqldump zakończy się niepowodzeniem z:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Kolejną ciekawostką jest to, że użytkownik zrzutu ma SELECT uprawnienia tylko do określonej tabeli bazy danych, mysqldump zrzuci dane tylko dla tej konkretnej tabeli i automatycznie zignoruje wszelkie inne tabele lub widoki.
Więc upewnij się, że użytkownik wykonujący mysqldump ma z góry wszystkie odpowiednie uprawnienia, aby uniknąć niespodzianek lub niepowodzeń w późniejszym czasie.
|
5. Max_allowed_packet
Największy pakiet komunikacyjny obsługiwany przez mysql jest określany przez ustawienie max_allowed_packet . W kontekście importu pakiet komunikacyjny to pojedyncza instrukcja SQL wysłana do serwera MySQL podczas przywracania LUB pojedynczy wiersz wysyłany do klienta podczas zrzutu.
Domyślna wartość max_allowed_packet mysqldump to 24MB. jeśli mysqldump otrzyma pakiet większy niż ten, możesz napotkać błąd:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Więc upewnij się, że mysqldump używa tej samej lub większej wartości max_allowed_packet który jest skonfigurowany w źródłowej instancji MySQL.
Opcję można określić za pomocą flagi --max-allowed-packet=value podczas wywoływania mysqldump.
Podczas przywracania zrzutu upewnij się, że max_allowed_packet rozmiar serwera docelowego jest wystarczająco duży, aby odbierać pakiety z pliku zrzutu.
W przeciwnym razie podczas przywracania zrzutu zobaczysz komunikat o błędzie:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Ten błąd może być trochę mylący, ponieważ możesz pomyśleć, że serwer MySQL został zamknięty lub uległ awarii. Ale oznacza to tylko, że serwer otrzymał pakiet o większym rozmiarze niż jego skonfigurowany rozmiar max_allowed_packet . Ponownie, najlepszą praktyką jest upewnienie się, że max_allowed_packet wartość dla serwera docelowego jest taka sama jak wartość na serwerze źródłowym. Jest to również ważne ustawienie, które można sprawdzić i odpowiednio ustawić z góry, zamiast stawiać czoła błędom w późniejszym czasie.
W tej pierwszej części serii mysqldump omówiliśmy warunki wstępne udanej operacji zrzutu i przywrócenia dla dużych baz danych MySQL, aby pomóc Ci uniknąć wielokrotnych prób i bezproduktywnego spędzania czasu.
W następnej części omówimy najlepsze praktyki importowania zapisanych programów i widoków z bazy danych MySQL.
