Co wziąć pod uwagę podczas tworzenia kopii zapasowej zdalnego serwera MySQL za pomocą ZRM przez Internet
Autorzy: Dmitri Joukovski i Pavel Pragin
Baza danych MySQL stała się najpopularniejszą na świecie bazą danych typu open source ze względu na stałą, szybką wydajność, wysoką niezawodność i łatwość użycia. Być może używasz bazy danych MySQL na forach internetowych i wiki znajdujących się u zarządzanego dostawcy usług hostingowych, możesz używać jej w zdalnym biurze do śledzenia błędów w Bugzilli, lub możesz po prostu myśleć o stworzeniu nowej aplikacji Web 2.0 korzystającej z MySQL . Tak czy inaczej, jeśli cenisz informacje przechowywane w bazie danych MySQL, będziesz musiał zapewnić skuteczne, bezpieczne i spójne kopie zapasowe MySQL przy minimalnym wpływie na aplikację bazy danych. Upewnij się, że Twoje rozwiązanie do tworzenia kopii zapasowych zapewnia najbardziej efektywne wykorzystanie zasobów sieciowych, serwerowych i pamięci masowej.
Jeśli szukasz rozwiązania, które uprości Twoje życie, zapewniając łatwy w użyciu, a jednocześnie elastyczny i solidne tworzenie kopii zapasowych i odzyskiwanie dla MySQL, Zmanda Recovery Manager (ZRM) może być właściwym wyborem dla Ciebie. Szczegóły dot Funkcjonalność ZRM jest dostępna tutaj.
W przypadku każdej kopii zapasowej bazy danych najważniejsze są spójność kopii zapasowej oraz jej wpływ na użytkowników i aplikacje. Tworzenie kopii zapasowej zdalnego MySQL wiąże się jednak z dodatkowymi wyzwaniami związanymi z:
- Wykorzystanie sieci
- bezpieczeństwo i
- elastyczność odzyskiwania danych MySQL na inny host.
Ostatni punkt może być ważny, jeśli nie masz pełnej kontroli nad swoim środowiskiem MySQL i chcesz mieć możliwość odzyskania danych u innego zarządzanego dostawcy usług hostingowych z inną wersją serwera MySQL lub innym systemem operacyjnym.
Przyrostowe kopie zapasowe znacznie zmniejszają czas tworzenia kopii zapasowych i wykorzystanie sieci, ponieważ przewodem przenoszone są tylko zmiany od ostatniej pełnej lub ostatniej przyrostowej kopii zapasowej. ZRM ułatwia odzyskiwanie danych z przyrostowych kopii zapasowych, nawet jeśli musisz użyć wielu przyrostowych obrazów kopii zapasowych, aby przywrócić dane do określonego momentu. Przyrostowe kopie zapasowe wymagają włączenia dzienników binarnych MySQL, ale zgodnie z dokumentacją MySQL włączenie dzienników binarnych spowoduje spadek wydajności o mniej niż 1%.
Logiczne kopie zapasowe zapewniają większą elastyczność odzyskiwania, ponieważ plik kopii zapasowej jest plikiem tekstowym zawierającym wszystkie instrukcje MySQL umożliwiające odtworzenie zarówno schematu, jak i zawartości bazy danych. Logiczna kopia zapasowa działa we wszystkich silnikach pamięci masowej z wyjątkiem silnika NDB używanego do klastrowania MySQL. Największą zaletą logicznej kopii zapasowej jest elastyczność odzyskiwania bazy danych. Możesz przywrócić logiczną kopię zapasową MySQL na inną architekturę, a nawet do innej bazy danych. Możliwość przenoszenia logicznych obrazów kopii zapasowych ZRM sprawia, że ZRM jest wygodnym narzędziem do migracji. Na przykład możesz przenieść dane MySQL:
- Od MySQL w systemie Solaris do MySQL w systemie Linux
- Z jednego silnika pamięci masowej do drugiego
- Z serwera 32-bitowego na serwer 64-bitowy
- Od jednego zarządzanego dostawcy hostingu do Twojego centrum danych lub innego dostawcy z inną konfiguracją MySQL
Oczywiście za takie elastyczne odzyskiwanie trzeba zapłacić cenę. Przywracanie danych z logicznych kopii zapasowych może zająć dużo czasu, ponieważ trzeba przeczytać i odtworzyć wszystkie instrukcje MySQL. Kolejną wadą jest to, że przewidzenie rozmiaru logicznej kopii zapasowej może być trudne. W zależności od typu danych i schematu bazy danych rozmiar logicznej kopii zapasowej może być większy niż sama baza danych. Jednym z rozwiązań jest to, że ponieważ logiczna kopia zapasowa jest w zasadzie plikiem tekstowym, zwykle można uzyskać przyzwoitą kompresję.
Surowa kopia zapasowa zapewnia spójną kopię bazy danych, a kopia zapasowa jest plikiem binarnym. Zalety surowych kopii zapasowych w porównaniu z logicznymi kopiami zapasowymi to:
- Kopie zapasowe, a zwłaszcza odzyskiwanie, są znacznie szybsze. Na przykład nie jest niczym niezwykłym, że dla tej samej bazy danych o rozmiarze 4-5 GB, surowa kopia zapasowa jest 5 razy szybsza niż logiczna kopia zapasowa, a odzyskiwanie surowego obrazu kopii zapasowej jest 20 razy szybsze niż odzyskiwanie logicznej obraz.
- Zawsze będziesz znać dokładny rozmiar kopii zapasowej, ponieważ jest to tylko kopia bazy danych.
- Zapewnia lepszą skalowalność, co może być ważne, jeśli baza danych MySQL jest dość duża, np. 10-20 GB lub więcej.
Surowe kopie zapasowe można odzyskać TYLKO do tej samej wersji serwera MySQL w tym samym systemie operacyjnym, co oryginalne dane. Oznacza to, że szanse na odzyskanie nieprzetworzonych obrazów kopii zapasowych MySQL u innego zarządzanego dostawcy usług hostingowych nie są zbyt duże i należy to wziąć pod uwagę przy wyborze kopii zapasowej surowej lub logicznej.
Zarówno surowe, jak i logiczne kopie zapasowe zapewniają ciepłą kopię zapasową, co oznacza, że nie musisz wyłączać serwera MySQL w celu wykonania kopii zapasowej, ale wszystkie tabele są blokowane podczas tworzenia kopii zapasowej, a użytkownicy nie mogą wprowadzać swoich danych. Dlatego warto rozważyć użycie wtyczki do planowania ZRM, która umożliwia opóźnianie tworzenia kopii zapasowych w oparciu o zdefiniowane przez Ciebie progi. Na przykład możesz odłożyć tworzenie kopii zapasowej na godzinę, jeśli do bazy danych uzyskuje dostęp więcej niż 50 użytkowników.
Jedną z ważnych kwestii związanych ze zdalnym tworzeniem kopii zapasowych MySQL jest decyzja o tym, jakiego typu połączenie należy ustanowić pomiędzy ZRM a zdalnym serwerem MySQL. ZRM zapewnia wtyczkę do połączenia w oparciu o gniazdo i inną wtyczkę do połączenia w oparciu o SSH. Elastyczna architektura ZRM umożliwia użytkownikom pisanie własnych wtyczek.
Jak sama nazwa wskazuje, wtyczka kopiująca gniazdo ustanawia gniazdo, które zapewnia komunikację pomiędzy ZRM i MySQL poprzez sieć opartą na protokole IP. Wtyczka kopiująca gniazdo wymaga uruchomienia usługi xinetd na serwerze MySQL i otwarcia domyślnego portu 25300. W razie potrzeby administrator kopii zapasowej może zmienić port. Wtyczka kopiująca gniazdo nie jest bezpieczna i powinna być używana tylko wtedy, gdy bezpieczeństwo nie jest istotne lub gdy bezpieczeństwo jest zapewnione w inny sposób, na przykład, gdy masz połączenie VPN pomiędzy ZRM a zdalnym serwerem MySQL.
Wtyczka kopiująca SSH zapewnia bezpieczny kanał pomiędzy ZRM a zdalnym serwerem MySQL. Wykorzystuje kryptografię klucza publicznego do uwierzytelniania zdalnego serwera MySQL i użytkownika zapasowego korzystającego z ZRM. Wtyczka SSH wymaga otwarcia standardowego portu TCP 22 i uruchomienia demona SSH. Wtyczka SSH do kopiowania najlepiej sprawdza się, gdy ważne jest zapewnienie bezpieczeństwa danych kopii zapasowych. Ponieważ połączenie SSH wymaga dodatkowych cykli procesora do szyfrowania, wydajność tworzenia kopii zapasowych może być niższa w porównaniu z kopiami zapasowymi przy użyciu połączenia przez gniazdo.
Poniższa tabela podsumowuje kwestie związane z wyborem wtyczki kopiującej Socket lub SSH do zdalnej kopii zapasowej MySQL:
| Zdalne połączenie plug-in |
Używany port | Bezpieczeństwo | Wydajność względna | Komentarze dotyczące instalacji |
|---|---|---|---|---|
| Kopia SSH | 22 (stały) | Zapewnia silne uwierzytelnianie i szyfrowanie przesyłania danych kopii zapasowych drogą kablową | Niższa wydajność i zależy od pamięci serwera MySQL, zasobów procesora i dostępnej przepustowości. | Często zdarza się, że połączenie SSH ze zdalnym serwerem MySQL zostało już nawiązane z powodów innych niż tworzenie kopii zapasowych i odzyskiwanie. W przeciwnym razie musisz ustanowić połączenie SSH pomiędzy ZRM a serwerem MySQL. |
| Kopia gniazda | 25300 (można zmienić) | Dane kopii zapasowej przesyłane przewodowo nie są bezpieczne | Wyższa wydajność | Na serwerze MySQL należy zainstalować dodatkowe oprogramowanie. Na przykład w przypadku wersji Enterprise ZRM 1.1 użyj MySQL-zrm-enterprise-socket-server-1.1-1.noarch.rpm. Aby zapoznać się z wersją społecznościową, zobacz stronę pobierania, aby uzyskać dokładny pakiet. |
Aby uzyskać więcej szczegółów technicznych, zarejestruj się bezpłatnie w Zmanda Network i pobierz pełną wersję tego oficjalnego dokumentu. Dowiesz się, jak używać ZRM w kilku typowych scenariuszach. Na przykład podamy szczegóły techniczne dotyczące wykonywania kopii zapasowych, gdy dane są bezpieczne w sieci i w spoczynku, przy użyciu wtyczki kopiowania SSH w tym przypadku użycia:
Dodatkowo przedstawimy szczegóły techniczne dotyczące wydajniejszych logicznych i surowych kopii zapasowych za pomocą wtyczki do kopiowania gniazd.
Przy całej swojej bogatej funkcjonalności, ZRM dla MySQL to po prostu narzędzie do wdrażania strategii tworzenia kopii zapasowych i odzyskiwania, która jest optymalna dla Twoich konkretnych potrzeb w zakresie ochrony danych. ZRM jest solidny i łatwy w użyciu, ale w zależności od twojej własnej implementacji zdalnego serwera MySQL i twoich specyficznych wymagań dotyczących tworzenia kopii zapasowych i odzyskiwania, powinieneś rozważyć wszystkie kompromisy związane z każdą opcją operacyjną zapewnianą przez ZRM dla MySQL.
Referencje:
ZRM dla MySQL
ZRM dla Wiki MySQL
Forum Zmanda