W artykule „State of the Open-Source DBMS Market, 2018” Gartner przewiduje, że do 2022 roku 70 procent nowych aplikacji wewnętrznych będzie opracowywanych na bazie danych typu open source. A 50% istniejących komercyjnych baz danych zostanie przekonwertowanych. Tak więc administratorzy baz danych Oracle, przygotuj się do rozpoczęcia wdrażania nowych baz danych typu open source i zarządzania nimi — wraz ze starszymi instancjami Oracle. Chyba że już to robisz.
Jak więc replikacja MySQL lub MariaDB wypada w porównaniu z Oracle Data Guard? W tym blogu porównamy te dwa z punktu widzenia rozwiązania bazy danych o wysokiej dostępności.
Na co zwrócić uwagę
Nowoczesna architektura replikacji danych opiera się na elastycznych projektach, które umożliwiają jednokierunkową i dwukierunkową replikację danych, a także szybkie, zautomatyzowane przełączanie awaryjne na dodatkowe bazy danych w przypadku nieplanowanej przerwy w działaniu usługi. Przełączanie awaryjne powinno być również łatwe do wykonania i niezawodne, aby żadne zatwierdzone transakcje nie zostały utracone. Ponadto przełączanie lub przełączanie awaryjne powinno być idealnie niewidoczne dla aplikacji.
Rozwiązania do replikacji danych muszą umożliwiać kopiowanie danych z bardzo małym opóźnieniem, aby uniknąć wąskich gardeł w przetwarzaniu i gwarantować dostęp do danych w czasie rzeczywistym. Kopie w czasie rzeczywistym mogą być wdrażane w innej bazie danych działającej na tanim sprzęcie.
W przypadku użycia do odzyskiwania po awarii system musi zostać zweryfikowany, aby zapewnić dostęp aplikacji do systemu dodatkowego przy minimalnych przerwach w działaniu usług. Idealne rozwiązanie powinno umożliwiać regularne testowanie procesu odzyskiwania po awarii.
Główne tematy porównania
- Dostępność i spójność danych
- Gtid, scm
- Wspomnij o replikacji do wielu modeli w trybie gotowości, asynchronicznej + synchronizacji
- Izolacja stanu gotowości od błędów produkcyjnych (np. opóźniona replikacja dla mysql)
- Unikaj utraty danych (replikacja synchronizacji)
- Wykorzystanie systemów rezerwowych
- Korzystanie z trybu gotowości
- Przełączanie awaryjne, przełączanie i automatyczne przywracanie
- Awaria bazy danych
- Przejrzyste przełączanie awaryjne aplikacji (TAF vs ProxySQL, MaxScale)
- Bezpieczeństwo
- Łatwość użytkowania i zarządzania (ujednolicone zarządzanie wstępnie zintegrowanymi komponentami)
Dostępność i spójność danych
GTID MySQL
Replikacja MySQL 5.5 była oparta na zdarzeniach z dziennika binarnego, w których wszystko, co wiedział slave, to dokładne zdarzenie i dokładna pozycja, którą właśnie odczytał z mastera. Każda pojedyncza transakcja z urządzenia nadrzędnego mogła zakończyć się w różnych dziennikach binarnych z różnych urządzeń podrzędnych, a transakcja zazwyczaj miałaby różne pozycje w tych dziennikach. Było to proste rozwiązanie, które miało pewne ograniczenia, zmiany topologii mogły wymagać od administratora zatrzymania replikacji w zaangażowanych instancjach. Zmiany te mogą powodować inne problemy, np. niewolnik nie może zostać przeniesiony w dół łańcucha replikacji bez czasochłonnej przebudowy. Naprawienie uszkodzonego łącza replikacji wymagałoby ręcznego określenia nowego pliku dziennika binarnego i pozycji ostatniej transakcji wykonanej na urządzeniu podrzędnym i wznowienia stamtąd lub całkowitego przebudowania. Wszyscy musieliśmy obejść te ograniczenia, marząc o globalnym identyfikatorze transakcji.
MySQL w wersji 5.6 (oraz MariaDB w wersji 10.0.2) wprowadził mechanizm do rozwiązania tego problemu. GTID (Global Transaction Identifier) zapewnia lepsze mapowanie transakcji między węzłami.
Dzięki GTID urządzenia podrzędne mogą zobaczyć unikalną transakcję przychodzącą od kilku urządzeń nadrzędnych, co można łatwo zmapować na listę wykonania urządzeń podrzędnych, jeśli zachodzi potrzeba ponownego uruchomienia lub wznowienia replikacji. Dlatego radzimy, aby zawsze używać GTID. Zwróć uwagę, że MySQL i MariaDB mają różne implementacje GTID.
Oracle SCN
W 1992 roku wraz z wydaniem 7.3 firma Oracle wprowadziła rozwiązanie do przechowywania zsynchronizowanej kopii bazy danych jako rezerwowej, znanej jako Data Guard od wersji 9i wydanie 2. Konfiguracja Data Guard składa się z dwóch głównych komponentów, jednej podstawowej bazy danych i rezerwowej bazy danych (do 30). Zmiany w podstawowej bazie danych są przekazywane przez rezerwową bazę danych, a zmiany te są wprowadzane do rezerwowej bazy danych w celu utrzymania jej synchronizacji.
Oracle Data Guard jest początkowo tworzony z kopii zapasowej podstawowej bazy danych. Data Guard automatycznie synchronizuje podstawową bazę danych i wszystkie rezerwowe bazy danych, przesyłając informacje o ponownym wykonaniu podstawowej bazy danych — informacje używane przez każdą bazę danych Oracle do ochrony transakcji — i stosując je do rezerwowej bazy danych. Oracle używa wewnętrznego mechanizmu o nazwie SCN (System Change Number). Numer zmiany systemu (SCN) to zegar Oracle, za każdym razem, gdy dokonujemy zatwierdzenia, zegar zwiększa się. SCN wyznacza spójny punkt w czasie w bazie danych, który jest punktem kontrolnym, który polega na zapisywaniu brudnych bloków (zmodyfikowanych bloków z bufora bufora na dysk). Możemy to porównać do GTID w MySQL.
Usługi transportowe Data Guard obsługują wszystkie aspekty ponownego przesyłania danych z podstawowej do rezerwowej bazy danych. Gdy użytkownicy zatwierdzają transakcje na serwerze podstawowym, rekordy ponawiania są generowane i zapisywane w lokalnym pliku dziennika online. Usługi transportowe Data Guard jednocześnie przesyłają to samo ponawianie bezpośrednio z bufora dziennika podstawowej bazy danych (pamięć przydzielona w obszarze globalnym systemu) do rezerwowych baz danych, gdzie jest ono zapisywane w rezerwowym pliku dziennika ponawiania.
Istnieje kilka głównych różnic między replikacją MySQL a ochroną danych. Bezpośrednia transmisja Data Guard z pamięci pozwala uniknąć narzutu we/wy dysku w podstawowej bazie danych. Różni się to od tego, jak działa MySQL - odczytywanie danych z pamięci zmniejsza I/O w podstawowej bazie danych.
Data Guard przesyła tylko ponawianie bazy danych. Stanowi to wyraźny kontrast do zdalnego dublowania pamięci masowej, które musi przesyłać każdy zmieniony blok w każdym pliku, aby zachować synchronizację w czasie rzeczywistym.
Modele asynchroniczne + synchronizowane
Oracle Data Guard oferuje trzy różne modele ponownego zastosowania. Modele adaptacyjne zależne od dostępnego sprzętu, procesów i ostatecznie potrzeb biznesowych.
- Maksymalna wydajność - domyślny tryb działania, umożliwiający zatwierdzenie transakcji, gdy tylko dane dotyczące ponownego wykonania potrzebne do odzyskania transakcji zostaną zapisane w lokalnym dzienniku ponownego wykonania w urządzeniu głównym.
- Maksymalna ochrona — brak utraty danych i maksymalny poziom ochrony. Dane ponownego wykonania potrzebne do ulepszenia każdej operacji muszą być zapisane zarówno w lokalnym dzienniku ponownego wykonywania online na urządzeniu głównym, jak i w dzienniku ponownego wykonywania w trybie gotowości w co najmniej jednej rezerwowej bazie danych przed zatwierdzeniem transakcji (Oracle zaleca co najmniej dwa rezerwy). Podstawowa baza danych zostanie zamknięta, jeśli błąd zablokuje jej możliwość zapisania strumienia ponawiania do co najmniej jednej zsynchronizowanej rezerwowej bazy danych.
- Maksymalna dostępność — podobna do maksymalnej ochrony, ale podstawowa baza danych nie zostanie zamknięta, jeśli usterka uniemożliwi jej zapisanie strumienia ponawiania.
Jeśli chodzi o wybór konfiguracji replikacji MySQL, masz wybór między replikacją asynchroniczną a replikacją półsynchroniczną.
- Asynchroniczne stosowanie dziennika binarnego jest domyślną metodą replikacji MySQL. Master zapisuje zdarzenia w swoim dzienniku binarnym, a urządzenia podrzędne żądają ich, gdy są gotowe. Nie ma gwarancji, że jakiekolwiek wydarzenie kiedykolwiek dotrze do jakiegokolwiek niewolnika.
- Zatwierdzenie półsynchroniczne na poziomie podstawowym jest opóźnione do momentu, gdy urządzenie nadrzędne otrzyma potwierdzenie od półsynchronicznego urządzenia podrzędnego, że dane zostały odebrane i zapisane przez urządzenie podrzędne. Należy pamiętać, że replikacja półsynchroniczna wymaga zainstalowania dodatkowej wtyczki.
Wykorzystanie systemów w trybie gotowości
MySQL jest dobrze znany ze swojej prostoty i elastyczności replikacji. Domyślnie możesz odczytywać, a nawet zapisywać na swoich serwerach oczekujących/podrzędnych. Na szczęście MySQL 5.6 i 5.7 przyniosły wiele znaczących ulepszeń do replikacji, w tym globalne identyfikatory transakcji, sumy kontrolne zdarzeń, wielowątkowe moduły podrzędne i odporne na awarie moduły podrzędne/nadrzędne, aby uczynić ją jeszcze lepszą. Administratorzy baz danych przyzwyczajeni do odczytu i zapisu replikacji MySQL oczekiwaliby podobnego lub nawet prostszego rozwiązania od jego większego brata, firmy Oracle. Niestety nie domyślnie.
Standardowa implementacja fizycznej gotowości dla Oracle jest zamknięta dla wszelkich operacji odczytu i zapisu. W rzeczywistości Oracle oferuje logiczne zróżnicowanie, ale ma wiele ograniczeń i nie jest przeznaczony do HA. Rozwiązaniem tego problemu jest dodatkowa płatna funkcja o nazwie Active Data Guard, której można używać do odczytywania danych z trybu gotowości podczas stosowania logów ponownego przetwarzania.
Active Data Guard to płatne rozwiązanie dodatkowe do bezpłatnego oprogramowania do odzyskiwania danych po awarii firmy Oracle, dostępnego tylko dla Oracle Database Enterprise Edition (licencja o najwyższym koszcie). Zapewnia dostęp tylko do odczytu, stale wprowadzając zmiany wysyłane z podstawowej bazy danych. Jako baza danych w aktywnej rezerwie pomaga odciążyć kwerendy odczytu, raportowanie i tworzenie przyrostowych kopii zapasowych z podstawowej bazy danych. Architektura produktu została zaprojektowana tak, aby umożliwić izolację rezerwowych baz danych od awarii, które mogą wystąpić w podstawowej bazie danych.
Ekscytującą cechą bazy danych Oracle 12c i czymś, czego brakuje Oracle DBA, jest sprawdzanie poprawności danych. Kontrole korupcji Oracle Data Guard są przeprowadzane w celu upewnienia się, że dane są dokładnie wyrównane, zanim dane zostaną skopiowane do rezerwowej bazy danych. Ten mechanizm może być również używany do przywracania bloków danych na podstawowym urządzeniu bezpośrednio z rezerwowej bazy danych.
Przełączanie awaryjne, przełączanie i automatyczne odzyskiwanie
Aby konfiguracja replikacji była stabilna i działała, system musi być odporny na awarie. Awarie są spowodowane błędami oprogramowania, problemami z konfiguracją lub problemami ze sprzętem i mogą się zdarzyć w dowolnym momencie. W przypadku awarii serwera potrzebujesz powiadomienia alarmowego o degradacji konfiguracji. Failover (promocję niewolnika na mastera) może wykonać administrator, który musi zdecydować, którego slave'a promować.
Administrator potrzebuje informacji o awarii, statusie synchronizacji na wypadek utraty jakichkolwiek danych, a na koniec kroki do wykonania akcji. W idealnym przypadku wszystko powinno być zautomatyzowane i widoczne z jednej konsoli.
Istnieją dwa główne podejścia do przełączania awaryjnego MySQL, automatyczne i ręczne. Obie opcje mają swoich fanów, koncepcje opisujemy w innym artykule.
Dzięki GTID ręczne przełączanie awaryjne staje się znacznie łatwiejsze. Składa się z kroków takich jak:
- Zatrzymaj moduł odbiornika (STOP SLAVE IO_THREAD)
- Przełącz master (ZMIEŃ MASTER NA
) - Uruchom moduł odbiornika (START SLAVE IO_THREAD)
Oracle Data Guard jest dostarczany z dedykowanym rozwiązaniem do przełączania awaryjnego/przełączania — Data Guard Broker. Broker to rozproszona struktura zarządzania, która automatyzuje i centralizuje tworzenie, konserwację i monitorowanie konfiguracji Oracle Data Guard. Dzięki dostępowi do narzędzia brokerskiego DG możesz dokonywać zmian konfiguracji, przełączeń, przełączeń awaryjnych, a nawet suchego testu swojej konfiguracji wysokiej dostępności. Dwie główne akcje to:
- Do wykonania operacji przełączania służy polecenie PRZEŁĄCZ NA
. Po pomyślnej operacji przełączania instancje bazy danych zamieniają się miejscami i replikacja jest kontynuowana. Nie można przełączyć, gdy tryb gotowości nie odpowiada lub jest wyłączony. - Do przełączenia awaryjnego jest używany typowy tryb FAILOVER TO
. Po operacji przełączania awaryjnego poprzedni serwer główny wymaga odtworzenia, ale nowy serwer podstawowy może przejąć obciążenie bazy danych.
Mówiąc o przełączaniu awaryjnym, musimy zastanowić się, jak bezproblemowe może być przełączanie awaryjne aplikacji. W przypadku planowanego/nieplanowanego przestoju, jak skutecznie można przekierować sesje użytkowników do dodatkowej lokalizacji, przy minimalnej przerwie w działalności.
Standardowym podejściem dla MySQL byłoby użycie jednego z dostępnych Load Balancerów. Począwszy od HAProxy, który jest powszechnie używany do przełączania awaryjnego HTTP lub TCP/IP, do obsługi baz danych Maxscale lub ProxySQL.
W Oracle ten problem jest rozwiązywany przez TAF (Transparent Application Failover). Po przełączeniu lub przełączeniu awaryjnym aplikacja jest automatycznie kierowana do nowej bazy. TAF umożliwia aplikacji automatyczne i przejrzyste ponowne łączenie się z nową bazą danych, jeśli instancja bazy danych, z którą nawiązywane jest połączenie, nie powiedzie się.
Bezpieczeństwo
Bezpieczeństwo danych to obecnie gorący temat dla wielu organizacji. Dla tych, którzy muszą wdrożyć standardy, takie jak PCI DSS lub HIPAA, bezpieczeństwo bazy danych jest koniecznością. Środowiska obejmujące różne sieci WAN mogą budzić obawy o prywatność i bezpieczeństwo danych, zwłaszcza że coraz więcej firm musi przestrzegać przepisów krajowych i międzynarodowych. Dzienniki binarne MySQL używane do replikacji mogą zawierać łatwe do odczytania poufne dane. Przy standardowej konfiguracji kradzież danych jest bardzo łatwym procesem. MySQL obsługuje SSL jako mechanizm szyfrowania ruchu zarówno pomiędzy serwerami MySQL (replikacja), jak i pomiędzy serwerami MySQL a klientami. Typowym sposobem implementacji szyfrowania SSL jest użycie certyfikatów z podpisem własnym. W większości przypadków uzyskanie certyfikatu SSL wydanego przez urząd certyfikacji nie jest wymagane. Możesz użyć openssl do tworzenia certyfikatów, przykład poniżej:
$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pemNastępnie zmodyfikuj replikację z parametrami dla SSL.
….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';Aby uzyskać bardziej zautomatyzowaną opcję, możesz użyć ClusterControl, aby włączyć szyfrowanie i zarządzać kluczami SSL.
W Oracle 12c transport ponownego wykonania Data Guard można zintegrować z zestawem dedykowanych funkcji bezpieczeństwa o nazwie Oracle Advanced Security (OAS). Zaawansowane zabezpieczenia mogą służyć do włączania usług szyfrowania i uwierzytelniania między systemem podstawowym a systemem rezerwowym. Na przykład włączenie algorytmu szyfrowania Advanced Encryption Standard (AES) wymaga tylko kilku zmian parametrów w pliku sqlnet.ora, aby wykonać ponowne szyfrowanie (podobne do logu MySQL). Nie jest wymagana konfiguracja certyfikatu zewnętrznego i wymaga jedynie ponownego uruchomienia rezerwowej bazy danych. Modyfikacje w sqlnet.ora i portfelu są proste:
Utwórz katalog portfela
mkdir /u01/app/walletEdytuj sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/wallet)))Utwórz magazyn kluczy
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;Otwórz sklep
ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;Utwórz klucz główny
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;W trybie gotowości
skopiuj pliki p12 i .sso do katalogu portfela i zaktualizuj plik sqlnet.ora podobny do węzła podstawowego.
Aby uzyskać więcej informacji, zapoznaj się z białą księgą Oracle TDE, z której możesz dowiedzieć się, jak zaszyfrować plik danych i sprawić, by portfel był zawsze otwarty.
Łatwość użytkowania i zarządzania
Podczas zarządzania lub wdrażania konfiguracji Oracle Data Guard może się okazać, że jest wiele kroków i parametrów, których należy szukać. Aby odpowiedzieć na to pytanie, Oracle stworzył DG Broker.
Z pewnością możesz stworzyć konfigurację Data Guard bez wdrażania DG Broker, ale może to znacznie zwiększyć komfort Twojego życia. Po wdrożeniu narzędzie wiersza poleceń Brokera – DGMGRL jest prawdopodobnie głównym wyborem dla DBA. Dla tych, którzy wolą GUI, Cloud Control 13c ma opcję dostępu do DG Broker za pośrednictwem interfejsu internetowego.
Zadania, w których może pomóc Broker, to automatyczne uruchomienie zarządzanego odzyskiwania, jedno polecenie przełączania awaryjnego/przełączania, monitorowanie replikacji DG, weryfikacja konfiguracji i wiele innych.
DGMGRL> show configuration
Configuration - orcl_s9s_config
Protection Mode: MaxPerformance
Members:
s9sp - Primary database
s9ss - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 12 seconds agoMySQL nie oferuje podobnego rozwiązania do Oracle DG Broker. Możesz jednak rozszerzyć jego funkcjonalność, korzystając z narzędzi takich jak Orchestrator, MHA i load balancerów (ProxySQL, HAProxy czy Maxscale). Rozwiązaniem do zarządzania bazami danych i load balancerami jest ClusterControl. ClusterControl Enterprise Edition zapewnia pełny zestaw funkcji zarządzania i skalowania, oprócz funkcji wdrażania i monitorowania oferowanych jako część bezpłatnej wersji Community.
