BAZY DANYCH Import i eksport danych Tworzenie kopii bezpieczeństwa oraz odzyskiwanie danych

Transkrypt

1 BAZY DANYCH Import i eksport danych Tworzenie kopii bezpieczeństwa oraz odzyskiwanie danych dr Lidia Stępień Akademia im. Jana Długosza w Częstochowie L. Stępień (AJD) BD 1 / 28

2 Cel Poznanie podstawowych zagadnień związanych z: eksportowaniem danych zgromadzonych w bazie MySQL do plików zewnętrznych (eksport), pobieraniem danych z takich plików (import), tworzeniem kopii bezpieczenstwa (na wypadek, np. awarii), wykorzystywaniem tych kopii do odzyskiwania utraconych danych. L. Stępień (AJD) BD 2 / 28

3 Wprowadzenie Serwer MySQL, jak każde oprogramowanie, nie jest całkowicie bezbłędne i odporne na awarie. Gdy przechowywane dane są ważne (a które ważne nie są?), należy zadbać o odpowiednią ich ochronę. Chodzi o stworzenie takich warunków, aby nawet w przypadku wystąpienia bardzo poważnej awarii serwera MySQL, zgromadzone dane były bezpieczne lub łatwe do odzyskania. Często zachodzi również potrzeba wyeksportowania zgromadzonych w bazie MySQL danych na zewnątrz, np. w celu wykorzystania ich w innej aplikacji. Mówimy wówczas o eksporcie danych. Z kolei odwrotna sytuacja ma miejsce wówczas, gdy chcemy do bazy MySQL załadować dane gromadzone w innych aplikacjach. Mamy wówczas do czynienia z importem danych. L. Stępień (AJD) BD 3 / 28

4 Wprowadzenie MySQL bardzo dobrze radzi sobie w zarówno w przypadku eksportu, jak i importu danych. Pliki z wyeksportowanymi danymi mogą być uważane za naturalne zródło kopii bezpieczenstwa. W razie wystąpienia awarii serwera MySQL można łatwo z nich skorzystać, aby odzyskać utracone dane. Nawet jeżeli nie uda nam się odzyskać wszystkich utraconych danych, to niemal zawsze, posiadając kopię bezpieczeństwa, jesteśmy w stanie odtworzyć ich znakomitą większość. Korzystając z interfejsu ODBC (ze strony producenta MySQL-a można pobrać program o nazwie MySQL Connector/ODBC (MyODBC)) można z łatwością przesłać dane zapisane w plikach eksportu do wielu róznych aplikacji np. do arkusza kalkulacyjnego Excel. L. Stępień (AJD) BD 4 / 28

5 Eksport - Poleceniem SELECT SELECT numer, nazwisko INTO OUTFILE C:/Temp/plik_kopia.txt FIELDS TERMINATED BY \t ESCAPED BY OPTIONALLY ENCLOSED BY " LINES TERMINATED BY \r\n FROM pracownik WHERE numer > 1100; Wynik: 1110 "RAJSKI" 1120 "ORKA" 1130 "KOLSKI" 1190 "KOLSKI" L. Stępień (AJD) BD 5 / 28

6 UWAGI Aby móc eksportować zawartość tabel w pokazany na poprzednim slajdzie sposób wymagane jest posiadanie przywileju FILE. Każdy użytkownik, który posiada ten przywilej, może zapisywać pliki w dowolnym miejscu na dysku, do którego ma dostep demon mysqld. Z powodów bezpieczeństwa nie należy przyznawać przywileju FILE użytkownikom innym niż administratorzy! Aby nieco zwiększyć bezpieczeństwo, pliki generowane za pomocą instrukcji SELECT... INTO OUTFILE nigdy nie nadpisują istniejących plików. Wpisując scieżkę dostępu do pliku stosujemy ukośniki w stylu systemów UNIX-owych (slash a nie backslash). Plik, który wymieniamy w klauzuli INTO OUTFILE nie może już istnieć na dysku. Gdy plik o podanej nazwie już istnieje, MySQL nie nadpisze jego zawartości, tylko wypisze komunikat ostrzegawczy: ERROR 1086 (HY000): File c:/temp/plik1.txt already exists. Jest to spowodowane względami bezpieczeństwa, aby nawet omyłkowo nie nadpisać jakiegoś ważnego pliku. L. Stępień (AJD) BD 6 / 28

7 ZADANIE Opcje występujące w klauzulach FIELDS oraz LINES pozwalają wpływać na postać pliku wynikowego. Korzystając z dokumentacji MySQL 5.7 postaraj się samodzielnie rozszyfrować poszczególne komendy. L. Stępień (AJD) BD 7 / 28

8 Eksport - Program mysqldump mysqldump to program narzędziowy służący do tworzenia zrzutu bazy danych lub kolekcji baz danych jako kopii bezpieczeństwa lub też w celu przeniesienia danych na inny serwer (niekoniecznie MySQL. Oczywiście ten inny serwer musi umieć odczytać pliki przygotowane przez mysqldump). Zrzut zawiera instrukcje SQL tworzące tabele i wypełniające je danymi. Istnieją trzy podstawowe sposoby uruchomienia programu (szczegóły sprawdź samodzielnie w dokumentacji): shell> mysqldump [options] db_name [tables] shell> mysqldump [options] --databases DB1 [DB2 DB3...] shell> mysqldump [options] --all-databases L. Stępień (AJD) BD 8 / 28

9 Przykład 1 Załóżmy, że naszym celem jest wykonanie kopii tabeli pracownicy znajdującej się w bazie danych o nazwie blab (chodzi o demonstracyjną strukturę relacyjną). Chcemy, aby w pliku wynikowym pojawiły się zarówno polecenia tworzące struktury tabel, jak i dane zapisane w tych tabelach. Poniżej pokazano w jaki sposób to wykonać. W wywołaniu programu użyto jawnie wiele opcji. Część z nich występuje nadmiarowo, gdyż są one przyjmowane domyślnie (sprawdź w dokumentacji które!). Samodzielnie wykonaj różne eksperymenty, dodając lub usuwając różne opcje, i obserwuj plik wynikowy. shell> mysqldump --databases blab --tables pracownicy --skip-quote-names --comments=1 --complete-insert --create-options --add-drop-table --skip-opt --user=root -p --result-file=c:\temp\pracownicy.sql Wykorzystując odpowiednie opcje (jakie?) możemy za pomocą programu mysqldump skopiować do pliku tekstowego tylko strukturę bazy danych bez zawartości tabel. Opcja ta przydaje się wówczas, gdy chcemy np. przenieść bazę na inny komputer. L. Stępień (AJD) BD 9 / 28

10 Przykład 2 Gdy zamiast opcji - -databases podamy - -all-databases, spowoduje to utworzenie kopii zapasowych wszystkich przechowywanych baz. Musimy oczywiście podać nazwę i hasło użytkownika, który ma wystarczające uprawnienia do wyeksportowania wszystkich baz danych. shell> mysqldump --all-databases --opt --no-data --user=root -p --result-file=c:\temp\blab.sql L. Stępień (AJD) BD 10 / 28

11 Przykład 3 Korzystając z opcji - -tab można wygenerować plik z danymi rozdzielonymi znakami tabulacji. Dla każdej zrzuconej tabeli, program mysqldump tworzy plik nazwa tabeli.sql, który zawiera instrukcje CREATE TABLE tworzącą tabele oraz plik nazwa tabeli.txt, zawierający dane. Domyślnie pliki danych (.txt) są formatowane ze znakami tabulacji między wartościami kolumn oraz znakiem nowej linii na zakonczenie rekordu. Można to jednak zmienić używając opcji - -field-xxx oraz lines-xxx. Działanie opcji - -tab jest zbliżone do funkcjonalności oferowanej przez polecenie SELECT... INTO OUTFILE omówione wcześniej. Uwaga: opcja - -tab powinna być używana tylko wtedy, gdy mysqldump jest uruchamiany na tej samej maszynie co serwer mysqld. Aby można było używać tej opcji musimy posiadać przywilej FILE, a serwer MySQL musi mieć prawa do zapisu plików w podanym katalogu. shell> mysqldump blab --tab=c:\temp --tables pracownicy --user=root -p --skip-quote-names --fields-terminated-by=\t --fields-escaped-by= --lines-terminated-by=\r\n UWAGA: Tym razem musieliśmy zalogować się na konto administratora. L. Stępień (AJD) BD 11 / 28

12 Import - Program mysqlimport mysqlimport to program narzędziowy, który pozwala załadować do bazy MySQL zawartość plików. Funkcjonalność tego programu odpowiada w zasadzie instrukcji SQL LOAD DATA INFILE. Dla każdego pliku tekstowego wymienionego w wierszu poleceń mysqlimport obcina rozszerzenie z nazwy pliku i wykorzystuje rezultat w celu określenia nazwy tabeli, do której mamy zaimportować zawartość pliku. L. Stępień (AJD) BD 12 / 28

13 Przykład 4 Niech w bazie danych blab dana będzie tabela pracownicy: CREATE TABLE pracownicy ( prac_id INT PRIMARY KEY, imie VARCHAR(20) NOT NULL, nazwisko VARCHAR(30) NOT NULL, zarobki NUMERIC(11,2) NULL, data_ur DATE NULL ); a w pliku pracownicy.txtnastępujące dane: 1, Artur, Nowakowski,NULL, , Jan, Kowalski, ,NULL 3, Ewa, Konieczna,NULL,NULL 4, Anna, Wojtasik,NULL,NULL L. Stępień (AJD) BD 13 / 28

14 Przykład 4 cd. Po wykonaniu polecenia: shell> mysqlimport -u root -p --fields-terminated-by=, --fields-enclosed-by= --lines-terminated-by=\r\n blab c:/temp/pracownicy.txt blab.pracownicy: Records: 4 Deleted: 0 Skipped: 0 Warnings: 0 dane zostają prawidłowo załadowane do tabeli pracownicy, co potwierdzamy wykonując polecenie SELECT: mysql> SELECT * FROM pracownicy; prac_id imie nazwisko zarobki data_ur Artur Nowakowski NULL Jan Kowalski NULL 3 Ewa Konieczna NULL NULL 4 Anna Wojtasik NULL NULL rows in set (0.00 sec) L. Stępień (AJD) BD 14 / 28

15 Import - Wykorzystanie plików programu mysqldump Mając plik eksportu możemy w bardzo łatwy sposób zapisane tam dane załadować do MySQL-a. Plik możemy wczytać albo w tzw. trybie wsadowym albo będąc już zalogowanym do MySQL-a wykonać polecenie source. shell> mysql -u root -p blab < c:\temp\blab.sql lub mysql> source c:\temp\blab.sql L. Stępień (AJD) BD 15 / 28

16 UWAGA Niezależnie od tego, którą z metod tworzenia kopii bezpieczeństwa wybierzemy, bardzo ważne jest, aby sprawdzić poprawność utworzonej kopii. Zawsze bowiem istnieje prawdopodobieństwo, że popełniliśmy jakiś błąd i możemy być bardzo niemile zaskoczeni, gdy odtworzenie bazy (np. po nagłej awarii) po prostu się nie uda. Wówczas będzie oczywiście za późno na wszelkie działania naprawcze. Inna sprawa to właściwe przechowywanie plików z kopiami bazy. Oczywiście przechowywanie ich na tym samym dysku, co pliki serwera MySQL nie ma absolutnie sensu. L. Stępień (AJD) BD 16 / 28

17 Statyczna kopia bazy danych Opisane na poprzednich slajdach metody tworzenia kopii bezpieczeństwa mają charakter statyczny. Obraz bazy danych tworzony jest bowiem w określonym punkcie czasowym i plik eksportu zarejestruje stan, w jakim była baza w tym właśnie momencie. Wszystkie zmiany, które później zajdą w bazie nie zostaną już zapisane. Oczywiście, gdy wystąpi nagła awaria bazy, możemy odtworzyć jej stan tylko na chwilę, gdy była wykonywana kopia bezpieczeństwa. Na przykład: wykonując kopię bazy co 24 godziny musimy liczyć się z tym, że w wariancie najbardziej pesymistycznym - gdy awaria pojawi się na kilka chwil przed wykonaniem kolejnej kopii, utracimy wszystkie dane z ostatnich 24 godzin. Teoretycznie kopie bezpieczeństwa można wykonywać częściej niż raz na dobę, ale zwykle jest to bardzo niewygodne. Często zdarza sie, że ilość danych jest tak duża, że czas sporządzania kopii bezpieczeństwa liczony bywa w godzinach. L. Stępień (AJD) BD 17 / 28

18 Dziennik binarny W MySQL-u serwer można uruchomić w trybie z rejestracją tzw. dziennika binarnego. W dzienniku tym zapisywane są wszystkie polecenia, które zmodyfikowały dane lub też próbowały je zmodyfikować (np. polecenie DELETE, w którym żaden rekord nie spełniał warunku WHERE). Polecenia, które nie modyfikują danych (np. SELECT) nie są rejestrowane w dzienniku binarnym. Podstawowym zadaniem dziennika binarnego jest zapewnienie możliwosci jak najpełniejszego uaktualnienia danych podczas operacji odtwarzania bazy (np. po awarii). L. Stępień (AJD) BD 18 / 28

19 Dziennik binarny Zapisane są tam bowiem wszystkie działania wykonywane na bazie od momentu wykonania ostatniej kopii bezpieczenstwa. Aby więc odtworzyć stan bazy w jakim była na chwilę przed awarią potrzebujemy zarówno ostatnią pełną kopię bazy, jak również plik (lub pliki) dziennika binarnego. Pliki te możemy więc traktować jako tzw. kopie przyrostowe i są one zwykle wielokrotnie mniejsze niż wielkość pliku z pełną kopią bazy. Aby serwer MySQL utworzył dziennik binarny, należy uruchomić go z opcją - -log-bin lub też wpisać parametr log-bin do pliku z opcjami (domyślnie, w systemie Windows, jest to plik o nazwie my.ini, który znajduje się w katalogu, gdzie zainstalowano serwer MySQL). L. Stępień (AJD) BD 19 / 28

20 Przykład 5-1 Upewniamy się, że serwer MySQL pracuje w trybie z rejestracją dziennika binarnego. mysql> SHOW VARIABLES LIKE log_bin ; Variable_name Value log_bin ON L. Stępień (AJD) BD 20 / 28

21 mysql> SELECT * FROM test; id 1 L. Stępień (AJD) BD 21 / 28 Przykład 5-2 Na początku w bazie blab istnieje tylko jedna testowa tabela z danymi (w zasadzie obojętnie jaka i obojętnie z jakimi danymi). DROP TABLE IF EXISTS test; CREATE TABLE test (id INT) type=innodb; INSERT INTO test VALUES (1); mysql> SHOW TABLES; Tables_in_blab test

22 Przykład 5-3 Wykonujemy kopię bezpieczeństwa bazy za pomocą programu mysqldump. shell> mysqldump blab --opt -u root -p --single-transaction --flush-logs --result-file=c:\temp\blab-dump.sql L. Stępień (AJD) BD 22 / 28

23 Przykład 5-3 UWAGI single transaction gwarantuje, że dane odczytane w trakcie działania programu będą spójne (tzn., że jeżeli w trakcie wykonywania kopii ktoś inny będzie próbował zmieniać kopiowane dane, nie bdzie mógł tego zrobić zanim program mysqldump nie ukończy swojej pracy). flush logs powoduje, że w momencie tworzenia kopii następuje wymuszenie zamknięcia oraz ponownego otwarcia plików dziennika binarnego. Bieżący plik dziennika binarnego zostaje zamknięty (staje się on plikiem archiwalnym. MySQL nigdy już do niego nic więcej nie zapisze), natomiast serwer MySQL inicjuje nowy plik dziennika binarnego. Nowy plik otrzymuje tą samą nazwę co poprzedni, z tym że zmienia sie jego rozszerzenie (generowany jest kolejny numer, np. było: xxx , to teraz będzie: xxx , itd.). Dzięki użyciu opcji flush log mamy gwarancję, że w bieżącym pliku dziennika binarnego zapisywane są wszystkie zmiany od chwili utworzenia kopii bezpieczeństwa za pomocą programu mysqldump. Plik ten możemy więc traktować jako tzw. kopię przyrostową. Aby móc użyć opcji flush log musimy posiadać uprawnienia RELOAD, a te posiadać powinien tylko administrator. Logujemy sie więc na konto root. L. Stępień (AJD) BD 23 / 28

24 Przykład 5-4 Po wykonaniu kopii, modyfikujemy w dowolny sposób dane w tabeli. mysql> UPDATE test SET id = 2; mysql> SELECT * FROM test; id 2 mysql> UPDATE test SET id = 3; mysql> SELECT * FROM test; id 3 L. Stępień (AJD) BD 24 / 28

25 Przykład 5-5 Załóżmy, że w tym momencie nastąpiła awaria serwera MySQL. Gdy uporaliśmy się z awarią i serwer MySQL podniósł się, stwierdziliśmy, że dane z tabeli test zniknęły. Pozostaje nam więc tylko próba odzyskania tych utraconych danych wykorzystując posiadane kopie bezpieczeństwa. Wymuszamy przeładowanie dziennika binarnego. Skutkuje to tym, że bieżący plik dziennika binarnego zostaje zamknięty (zarchiwizowany) i system otwiera nowy plik. Zatem możemy mieć pewność, że w zarchiwizowanym właśnie pliku na pewno znajduje się informacja o wykonanych przed chwilą poleceniach UPDATE. Aby móc wykonać poniższe polecenie musimy posiadać uprawnienia RELOAD, a takie powinien posiadać tylko administrator. FLUSH LOGS; L. Stępień (AJD) BD 25 / 28

26 Przykład 5-6 Odtwarzamy stan bazy korzystając z kopii utworzonej programem mysqldump. Stwierdzamy, że zmiany dokonane w poprzednich punktach (polecenia UPDATE) nie zostały odtworzone (bo oczywiście dane zostały zmienione już po wykonaniu kopii bezpieczeństwa). mysql> SOURCE c:\temp\blab-dump.sql mysql> SELECT * FROM test; id 1 L. Stępień (AJD) BD 26 / 28

27 Przykład 5-7 Odtwarzamy brakujące dane korzystając z informacji zapisanych w dzienniku binarnym. (Uwaga: jako parametr dla programu mysqlbinlog musimy podać właściwy plik dziennika binarnego.) Gdy serwer MySQL pracuje dłuższy czas z włączoną opcją rejestrowania dziennika binarnego, na dysku powstaje sporo takich plików. Każdy z nich przechowuje zmiany z pewnego przedziału czasu w przeszłości. Bieżącym plikiem jest zwykle ten z najwyższym numerem w rozszerzeniu. Uwaga: zanim wykonasz poniższe polecenie upewnij się, który plik (lub pliki) dziennika należy podać jako parametr. shell> mysqlbinlog hydra-bin mysql -u root -p blab mysql> SELECT * FROM test; id 3 L. Stępień (AJD) BD 27 / 28

28 Przykład 5-8 shell> mysqlbinlog hydra-bin short-form /*!40019 SET /*!50003 SET use blab; SET TIMESTAMP= ; SET SET SET UPDATE test SET id = 2; COMMIT; SET TIMESTAMP= ; UPDATE test SET id = 3; COMMIT; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; L. Stępień (AJD) BD 28 / 28