W drugiej i ostatniej części naszych najlepszych praktyk mysqldump omówimy, jak obsłużyć migrację i import przechowywanych obiektów programów i widoków z bazy danych MySQL. Aby dowiedzieć się więcej o warunkach wstępnych pomyślnej operacji zrzutu i przywracania dużych baz danych MySQL, zapoznaj się z pierwszą częścią tej dwuczęściowej serii blogów.
Importowanie procedur składowanych, funkcji i wyzwalaczy
Domyślnie mysqldump importuje widoki i wyzwalacze. Nie importuje jednak procedur, funkcji i zdarzeń. Aby zaimportować procedury i funkcje, --routines należy określić opcję, a aby zaimportować zdarzenia, --events należy określić opcję.
1. Importowanie wyzwalaczy
Mysqldump domyślnie spróbuje zrzucić wszystkie wyzwalacze w Twojej bazie danych. Aby móc zrzucić triggers tabeli? , musisz mieć TRIGGER przywilej dla stołu. Jeśli użytkownik zrzutu nie ma tego uprawnienia, wyzwalacze zostaną pominięte, a mysqldump nie zgłosi żadnego błędu. Więc nie zdziw się, jeśli nie zobaczysz żadnych wyzwalaczy zaimportowanych do docelowej bazy danych.
2. Importowanie wydarzeń
Aby zaimportować zdarzenia, musisz określić --events opcja podczas wywoływania narzędzia mysqldump. Ta opcja wymaga EVENT uprawnienia do tych baz danych. Ponownie, mysqldump po cichu pominie zdarzenia, jeśli użytkownik zrzutu nie ma tych uprawnień, nawet jeśli określiłeś opcję –event podczas wywoływania mysqldump.
3. Importowanie funkcji i procedury składowanej
Aby zaimportować procedury, musisz określić --routines opcja podczas wywoływania narzędzia mysqldump. Ta opcja wymaga global select przywileje. Nawet w tym przypadku mysqldump po cichu pominie funkcje i procedury, jeśli użytkownik zrzutu nie ma tych uprawnień, nawet jeśli określiłeś --routines opcja podczas wywoływania mysqldump.
3.1 Importowanie funkcji niedeterministycznych
Program przechowywany, który modyfikuje dane jest nazywany niedeterministycznym, jeśli nie daje powtarzalnych wyników. Przykładowa funkcja rand(). Szczególnie trudne jest używanie takich funkcji w konfiguracjach replikowanych, ponieważ mogą one skutkować różnymi danymi w źródle i replice. Aby kontrolować takie możliwości, MySQL nakłada pewne ograniczenia na tworzenie funkcji, jeśli włączone są logi binarne.
Domyślnie dla CREATE FUNCTION oświadczenie do zaakceptowania, przynajmniej jedno z DETERMINISTIC , NO SQL lub READS SQL DATA musi być wyraźnie określony. W przeciwnym razie wystąpi błąd:
ERROR 1418 (HY000) at line 181: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_funable)
Więc jeśli twoja funkcja nie jest zadeklarowana jako deterministyczna w źródle, a logowanie binarne jest włączone w miejscu docelowym, zobaczysz powyższy błąd podczas przywracania zrzutu. Dlatego ważne jest, aby z góry zrozumieć deterministyczny charakter twoich funkcji. Jeśli masz pewność, że Twoje funkcje są deterministyczne, musisz włączyć log_bin_trust_function_creators konfiguracja w miejscu docelowym przed operacją przywracania. Po włączeniu MySQL umożliwia tworzenie takich funkcji nawet wtedy, gdy włączone jest logowanie binarne.
4. Charakterystyka SQL SECURITY przechowywanych procedur i widoków.
MySQL umożliwia SQL SECURITY kontekst, który należy określić podczas tworzenia programów sklepowych lub widoków. SQL SECURITY charakterystykę można określić jako DEFINER lub INVOKER . Jeśli SQL_SECURITY kontekst to DEFINER , procedura jest wykonywana przy użyciu uprawnień konta wymienionego w procedurze DEFINER klauzula. Jeśli kontekst to INVOKER , procedura jest wykonywana z uprawnieniami użytkownika, który ją wywołuje. Wartość domyślna to DEFINER .
Jeśli przywracasz zapisane procedury lub widoki, musisz upewnić się, że konto użytkownika definiującego istnieje w docelowej bazie danych z odpowiednimi uprawnieniami. W przeciwnym razie wystąpią błędy podczas przywracania.
Zademonstrujmy to na przykładzie dotyczącym widoków.
Załóżmy, że masz widoki V1 i V2 zdefiniowane jak poniżej:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table; CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Pamiętaj, że widoki są domyślnie zrzucane przez mysqldump i jeśli nie masz użytkownika „admin” w miejscu docelowym, podczas operacji przywracania wystąpi poniższy błąd:
Command failed with error - ERROR 1449 (HY000) at line 206 in file: '/mysql_data/mysqldump/sqldump_1582457155758.sql': The user specified as a definer ('admin'@'%') does not exist. Zauważ, że nie wystarczy tylko upewnić się, że użytkownik istnieje, ale użytkownik musi mieć odpowiednie uprawnienia do wykonywania widoków. Na przykład, jeśli użytkownik admin@'%' istnieje w miejscu docelowym, ale nie ma SELECT uprawnienia do bazy danych mydb, zobaczysz komunikat o błędzie:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them.
|
Podsumowanie
W tej dwuczęściowej serii blogów omówiliśmy ważne wymagania wstępne, które należy spełnić, aby zapewnić pomyślną migrację danych i zapisanych programów. Hosting ScaleGrid MySQL obsługuje te wytyczne, aby zapewnić płynne działanie podczas importowania danych na platformę ScaleGrid. Podziel się z nami swoim doświadczeniem i najlepszymi praktykami, które stosujesz w przypadku migracji danych MySQL!
