GoldenLine
Zaloguj się

konto usunięte

Temat: MySQL i SLES 10 backup

Witam

Chciałem dowiedzieć się jak najlepiej z bakapować bazę danych z MYSQL pod Linuxem?
Jak wy to robicie?
Ogólnie koncepcja jest taka że na SLESIE (SUSE Linux Enterprise Server) ma stać kilka baz MYSQL.
W nocy ma robić się backup baz a później mam wykonać automatyczną kopię backupu na serwer W2K3.
Jak byście to zrobili?
Pozdrawiam serdecznie,
Sebastian
Link do wypowiedziLink
Łukasz Myszor

Łukasz Myszor IBM AIX Certified
System Administrator

Temat: MySQL i SLES 10 backup

mysqldump :)
Link do wypowiedziLink
Paweł S.

Paweł S. Dyrektor Techniczny,
Techweb Software

Temat: MySQL i SLES 10 backup

Jak NAJLEPIEJ to zrobić?

Jeśli można na czas wykonywania backupu odciąć wszystkich klientów modyfikujących zawartość bazy, to mysqldump albo mk-parallel-dump (http://www.maatkit.org/doc/mk-parallel-dump.html)

Jeśli baza ma być online, to moim zdaniem poprzez wykonanie migawki LVM (http://lmgtfy.com/?q=lvm+snapshot).

Wykonywanie dumpa podczas działania aplikacji podpiętej do bazy (która to aplikacja może zmodyfikować zawartość bazy) jest proszeniem się o kłopoty i brak spójności pomiędzy tabelami i/lub straszne locki.

Po wykonaniu backupu rób sobie z nim co chcesz, np. możesz pliki skompresować i wgrać poprzez FTP na inną maszynę - napisanie skryptu łącznie z przetestowaniem to max parę godzin.

W przypadku migawki i tak trzeba co jakiś czas robić pełnego dumpa, ale można to zrobić bez wyłączania głównej bazy - wystarczy postawić drugą instancję MySQL opartą na plikach z backupu migawkowego i na niej wykonać dumpa. Przydaje się to czasami więc nie opieraj się jedynie na migawkach :-)Paweł Skarżyński edytował(a) ten post dnia 06.04.10 o godzinie 11:41
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Kiedyś napisałem sobie taki prościutki skrypt do backupowania MySQL:
http://blog.y3ti.pl/2008/12/backup-mysql-na-szybko/

Możesz zmodyfikować, tak aby wrzucało Ci na FTP.
Link do wypowiedziLink
Paweł S.

Paweł S. Dyrektor Techniczny,
Techweb Software

Temat: MySQL i SLES 10 backup

@Kamil Grabowski:
Twój skrypt bardzo ładnie robi backup, mam jednak kilka zastrzeżeń:
1. Co ze spójnością danych? Jeśli są jakieś relacje (albo jeszcze lepiej: "relacje" w MyISAM) to możesz stracić tę spójność gdy tylko poleci jakaś modyfikacja podczas robienia dumpa.

2. Nie blokujesz tabel - przy dumpach to jest niestety jedyna możliwość zapewnienia jako takiej spójności.
Choć przy InnoDB to też może nie pomóc - bufory wstawiania, dziennika zdarzeń i operacji zapisu i tak będą pracować.

3. Skoro już robisz dumpy każdej bazy osobno to proponuję pójść dwa kroki dalej i dla każdej bazy zapisywać dump każdej tabeli osobno (pierwszy krok), ale tak, żeby struktura i dane były w osobnych plikach(drugi krok) - nie raz potrzebowałem np. tylko strukturę jakiejś tabeli albo dane jednej małej tabelki z wielogigabajtowego dumpa.
W pracy tak właśnie zrzucamy dane gdy robimy dumpy, ale z oczywistych powodów nie mogę tu wkleić gotowego skryptu.Paweł Skarżyński edytował(a) ten post dnia 07.04.10 o godzinie 13:31
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Dzięki za uwagi. Będę musiał dopisać funkcjonalności, o których piszesz :)
Link do wypowiedziLink
Paweł S.

Paweł S. Dyrektor Techniczny,
Techweb Software

Temat: MySQL i SLES 10 backup

Nie ma za co, ale żeby się załapać na plusika, to jeszcze chciałbym zdecydowanie podkreślić jedną rzecz:

dump działającej bazy (generalnie) nie jest backupem.

Oczywiście lepiej go mieć niż nie mieć, ale jeśli w tabelach mamy jakieś dane wrażliwe (np. info o płatnościach albo innych mających skutki finansowe operacjach, np. rezerwacjach turystycznych) to taki dump może nam dać bardzo mylące poczucie bezpieczeństwa, a w razie wtopki mamy zamiast backupu wspomniany na Twoim blogu fuckup :-)
Pamiętaj o prawie Murphy'ego :-)

Wykonanie dumpa, co do którego będzie można zapewnić na 100%, że jest spójny jest nietrywialne, jeśli bazy nie można zrzucać 'na sucho'.
Pisałem o tym w pierwszym moim poście w tym wątku - migawka LVM + wciągnięcie plików do innej instancji MySQL i robienie dumpa wtedy -> to jest jeden z niewielu sposobów wykonania spójnej logicznej kopii zapasowej (czyli jeden z niewielu sposobów uratowania naszej d4). Ale jest to na tyle obciążające i upierdliwe, że zwykle nie warto robić jej częściej niż raz na tydzień, a codzienne backupy można ograniczyć do kopiowania i archiwizacji samych plików migawkowych. W ten sposób masz kopię logiczną w razie katastrofy oraz przyrostowy backup plików w razie drobniejszych awarii (z InnoDB inaczej niż przez migawkę to plików w bezpieczny sposób nie skopiujesz).
Są też inne sposoby backupu, np. DRBD albo jakieś SANowskie zabawki ale to raczej rozwiązania z górnej półki cenowej, a migawka to nie jest jakiś problem przy współczesnych dyskach twardych.

A pomyśleć, że kiedyś myślałem, że mysqldump działającej bazy wykonuje mi backup (a niektórzy hostingodawcy tylko w ten sposób to robią :D).
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

O widzisz, a ja dopiero teraz zauważyłem, że jest taka opcja jak "wartościowa odpowiedź" na goldenline :)
Powiedz mi więc, czy sprawdzi się takie rozwiązanie:

1. Mamy mastera mysql, który replikuje się ze swoim slavem.
2. Gdy chcemy zrobić backup stopujemy proces replikacji na slave. Wykonujemy swój backup.
3. Po udanym procesie backupowania włączamy replikacje - slave staje się "up to date".
4. Gdy nam coś wyleci pomiędzy backupami to mamy jeszcze logi binarne jako dodatkowe zabezpieczenie.
Link do wypowiedziLink
Paweł S.

Paweł S. Dyrektor Techniczny,
Techweb Software

Temat: MySQL i SLES 10 backup

Generalnie się sprawdzi, z treści pytania inicjującego dyskusję wnioskowałem, że do dyspozycji jest jedna maszyna więc niuansów replikacji nie poruszałem :-)
Oczywiście nie byłbym sobą, jakbym nie znalazł wielu różnych 'ale'.
Jeśli masz replikację to zapewne dlatego, że master nie wytrzymywał obciążenia. Wyłączając slave'a dorzucasz masterowi 'do pieca'. W godzinach nocnych to zda egzamin, o ile akurat to nie jest średniej wielkości stronka na której google sobie wymarzyło zapuścić indeksowanie w trakcie backupu.

Cała mechanika backupu MySQL sprowadza się do tego, żeby mieć wierną i spójną kopię plików bazy danych z danej chwili 't0'.

Posiadanie 'logicznej' kopii danych (czyli dumpa) nie jest warunkiem niezbędnym, ale się bardzo przydaje, gdy właśnie trwa 'czarna godzina' i wszystko poszło źle. Szczególnie, jak nie jest to bardzo stara logiczna kopia danych i jest na zewnętrznym względem maszyny nośniku, np. na szyfrowanym hdd trzymanym w tzw. bezpiecznej lokalizacji.

Z replikacją problem może być taki, że wcale nie jest powiedziane, że slave jest wierną kopią mastera. Te same tabele mogą mieć inne silniki. Slave może nie replikować wszystkich baz (np. nie włączysz replikacji bazy 'mysql', w której siedzą procedury i nawet tego nie zauważysz bo one mogą być potrzebne tylko masterowi. A jak będzie awaria to nagle 'zonk' - nie mamy pełnej kopii).
Gdy programiści mogą samodzielnie tworzyć bazy/tabele to może się okazać, że ktoś dodał coś, co nie jest replikowane, a po pół roku okazało się, że jednak powinno replikacji podlegać.
Zgodnie z prawem Murphy'ego awaria będzie dotyczyć właśnie tego czegoś :-)

Jeśli slave ma służyć wyłącznie backupowi, to są lepsze sposoby wykorzystania maszyny, np. DRBD.
Zwykle aplikacja korzystająca z architektury replikowanej ma jakiś poziom opóźnienia, który jest akceptowalny i dosłownie wszystko zależy tu od specyfiki systemu - gdy prawie nie ma aktualizacji danych a odczyty są problemem, to wyłączenie slave zapewni backup, ale obciąży mastera, a gdy zapisów jest dużo, to wyłączenie slave spowoduje najprawdopodobniej osiągnięcie nieakceptowalnego opóźnienia (można na czas doganiania mastera selecty kierować do mastera, ale znowu pojawia się obciążenie, wszak nie bez powodu bazę obsługują dwa serwery).

Z powyższych powodów nadal bym obstawał przy wersji z migawką LVM na masterze.
Natomiast pliki bym skopiował na slave'a i tam je wciągał do drugiej instancji MySQL i potem robił dumpa - dla systemu powinno być to pomijalne obciążenie.
A jeśli nie jest pomijalne, ale bazy nie są jakoś astronomicznie wielkie (terabajty?), to można pliki z migawki przepchnąć dosłownie gdziekolwiek indziej i tam sobie je wciągać, choćby i pół dnia na desktopie z dużym dyskiem, 2GB RAM i jednym rdzeniem 1.7 GHz :-)Paweł Skarżyński edytował(a) ten post dnia 09.04.10 o godzinie 14:53
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Jeszcze raz dzięki za informacje :)
Link do wypowiedziLink
Krzysztof Stachyra

Krzysztof Stachyra Szef Wydziału
Produkcji Systemów
Handlowo-Magazynowyc
h i ...

Temat: MySQL i SLES 10 backup

samą logiczną spójną kopie mysqla można uzyskać stosując blokady, oczywiście to ma impact na dostęp do danych. Dla innodb będzie to wykorzystanie single transaction a dla myisam read lock na tabele przy łaczonych bodajże -x do mysqldumpa.
Oczywiście migawki LVM są bardzo dobrym rozwiązaniem a replikacja może być przydatna nie tylko do backupu pytanie ile jest maszyn i co chcemy uzyskać.
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Witam,

Pozwoliłem sobie zrobić zrzut ekranu z jednego ze slajdów prezentacji porównującej najpopularniejsze metody wykonywania backupów MySQL, również z podziałem na silniki, bo to jeden z bardziej istotnych elementów przy podejmowaniu decyzji "jak?". Każdy z przypadków oczywiście zakłada spójność backupu.


Obrazek


W zależności od warunków, w szczególności od silników tabel użytych w konkretnej instancji, można wybrać najbardziej odpowiadający mechanizm, a następnie oskryptować według potrzeb lub skorzystać z gotowców.
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Pytnako. Możesz udostępnić gdzieś całą prezentacje?
Link do wypowiedziLink
Daniel Częstki

Daniel Częstki senior php developer

Temat: MySQL i SLES 10 backup

SERVER OFFLINE
1. MySQL stop
2. Kopia plików bazy ;)
3. MySQL Start

SERVER ONLINE
1. Replikacja
1. MySQL stop (serwer replikujący)
2. Kopia plików bazy ;)
3. MySQL Start (serwer replikujący)Daniel Częstki edytował(a) ten post dnia 15.04.10 o godzinie 14:36
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Kamil Grabowski:
Pytnako. Możesz udostępnić gdzieś całą prezentacje?

Do mojej wypowiedzi wkradł się błąd nieco zmieniający jej sens. Powinno być: "zrzut ekranu z jednego ze slajdów prezentacji porównujący najpopularniejsze metody wykonywania backupów MySQL". Cała prezetnacja nie dotyczy oczywiście porównania metod, a jedynie narzędzia Xtrabackup.

Póki co prezentacja chyba nie była jeszcze publikowana, więc mnie "za plecami" autora nie wypada tego robić, ale być może wkrótce, już po zakończeniu MySQL Users Conference, pojawi się na http://www.percona.com/about-us/presentations
Link do wypowiedziLink
Rafał T.

Rafał T. Senior Java
Developer, SQL
developer

Temat: MySQL i SLES 10 backup

Dobrze prawicie. Wszystko zależy od sytuacji: mechanizmu składowania i dostępności bazy.

@Sebastian Jaczek
Nie napisałeś, jakiego mechanizm składowania danych wykorzystujesz. Dla MEMORY kopia fizyczna chyba odpada.

Sam korzystałem z mysqldump. Pamiętaj, że to narzędzie zapisuje dane jako polecenia SQL (CREATE, INSERT).
Dla MyISAM Krzysztof Stachyra już napisał, należy założyć blokady na tabele, bo ten mechanizm nie wspiera transakcji i nie posiada więzów integralności.

Dla InnoDB jest --single-trasaction. Jeżeli masz włączony dziennik transakcji, w czasie wykonywania kopii, praca klientów będzie zapisana do dziennika.

Radzę dodać --events --routines --triggers.
mysqldump domyślnie nie zachowuje procedur i funkcji.
Link do wypowiedziLink

konto usunięte

Temat: MySQL i SLES 10 backup

Można backup zrobić np. tak:

1. FLUSH TABLES WITH READ LOCK;
2. Snapshot (lvm, ...).
3. UNLOCK TABLES;

Jak już ten snapshot masz to sobie go gdzieś przegraj. :)
Dodatkowo jak masz taki snapshot na slave-ie to masz też binlogi. :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

mysql backup all




Wyślij zaproszenie do
Anuluj