Porównanie rozwiązań do replikacji Oracle i MySQL

Bazy danych mogą zawieść bez ostrzeżenia — albo z powodu awarii spowodowanej błędem oprogramowania, albo podstawowych komponentów sprzętowych. Chmura nadaje temu problemowi inny wymiar, ze względu na efemeryczny charakter zasobów obliczeniowych i pamięci masowej. Aby odizolować naszą infrastrukturę bazodanową od tych awarii, w naszych systemach wbudowujemy nadmiarowość. Jeśli instancja stanie się niedostępna, system gotowości powinien być w stanie przejąć obciążenie i kontynuować od tego momentu. Replikacja jest dobrze znaną i powszechnie stosowaną metodą tworzenia nadmiarowych kopii głównej bazy danych.

W tym poście porównamy funkcjonalność replikacji w dwóch najpopularniejszych systemach bazodanowych na świecie (wg db-engines) - Oracle i MySQL. Przyjrzymy się w szczególności replikacji logicznej Oracle 12c i MySQL 5.7. Obie technologie oferują niezawodne systemy rezerwowe, które odciążają zadania produkcyjne i pomagają w przypadku awarii. Przyjrzymy się ich różnym architektom, przeanalizujemy zalety i wady oraz przejdziemy przez kroki, jak skonfigurować replikację z Oracle i MySQL.

Architektura Oracle Data Guard — jak to działa

Oracle Data Guard zapewnia wysoką dostępność, ochronę danych i odzyskiwanie danych po awarii. Jest to prawdopodobnie pierwszy wybór Oracle DBA do replikacji danych. Technologia została wprowadzona w 1990 roku (wersja 7.0) z zasadniczym zastosowaniem logów archiwalnych w rezerwowych bazach danych. Data Guard ewoluowała przez lata i obecnie zapewnia kompleksowy zestaw usług, które tworzą, utrzymują, zarządzają i monitorują zapasowe bazy danych.

Data Guard utrzymuje rezerwowe bazy danych jako kopie produkcyjnej bazy danych. Jeśli podstawowa baza danych przestanie odpowiadać, Data Guard może przełączyć dowolny stan wstrzymania na rolę produkcyjną, a tym samym przestój. Data Guard może być używany do tworzenia kopii zapasowych, przywracania i technik klastrowych w celu zapewnienia wysokiego poziomu ochrony danych i dostępności danych.

Data Guard to technologia Ship Redo / Apply Redo, „ponowne” to informacje potrzebne do odzyskania transakcji. Produkcyjna baza danych, określana jako podstawowa baza danych, rozgłasza powtórzenia do jednej lub większej liczby replik, określanych jako rezerwowe bazy danych. Po wprowadzeniu lub zaktualizowaniu tabeli ta zmiana jest przechwytywana przez program piszący dziennik do dziennika archiwum i replikowana do systemu rezerwowego. Bazy danych w stanie gotowości są w ciągłej fazie odtwarzania, weryfikują i stosują ponawianie, aby zachować synchronizację z podstawową bazą danych. Rezerwowa baza danych również automatycznie zsynchronizuje się ponownie, jeśli zostanie tymczasowo odłączona od podstawowej z powodu przerw w dostawie prądu, problemów z siecią itp.

Usługi transportowe Data Guard Redo regulują transmisję powtórzeń z podstawowej bazy danych do rezerwowej bazy danych. Proces LGWR (zapisujący dziennik) przesyła dane ponawiania do jednego lub większej liczby procesów serwera sieciowego (LNS1, LSN2, LSN3, ...LSNn). LNS odczytuje z bufora redo w SGA (Shared Global Area) i przekazuje ponowne wykonanie do Oracle Net Services w celu przesłania do rezerwowej bazy danych. Możesz wybrać atrybuty LGWR:synchroniczny (LogXptMode =„SYNC”) lub asynchroniczny (LogXptMode =„ASYNC”). Dzięki takiej architekturze możliwe jest dostarczanie danych ponawiania do kilku rezerwowych baz danych lub wykorzystanie ich z Oracle RAC (Real Application Cluster). Proces zdalnego serwera plików (RFS) odbiera ponowne wykonanie od LNS i zapisuje je w zwykłym pliku zwanym plikiem dziennika ponownych operacji w trybie gotowości (SRL).

Istnieją dwa główne typy Oracle Data Guard. Fizyczne z zastosowaniem ponownego wykonania i logiczne rezerwowe bazy danych z zastosowaniem SQL.

Zastosowanie SQL wymaga więcej przetwarzania niż ponownego wykonania, proces najpierw odczytuje obiekt SRL i „wykopuje” powtórzenie, przekształcając je w rekordy zmian logicznych, a następnie buduje transakcje SQL przed zastosowaniem kodu SQL do rezerwowej bazy danych. Jest więcej ruchomych części, więc wymaga więcej procesora, pamięci i we/wy, a następnie zastosuj ponownie.

Główną zaletą "zastosowania SQL" jest to, że baza danych jest otwarta do odczytu i zapisu, podczas gdy proces stosowania jest aktywny.

Możesz nawet tworzyć widoki i indeksy lokalne. To sprawia, że ​​idealnie nadaje się do narzędzi do raportowania. Rezerwowa baza danych nie musi być kopią jeden do jednego podstawowej bazy danych, a zatem może nie być najlepszym kandydatem do celów DR.

Kluczowe cechy tego rozwiązania to:

• Zapasowa baza danych, która jest otwierana do odczytu i zapisu, gdy aktywne jest zastosowanie SQL
• Możliwa blokada modyfikacji danych utrzymywanych przez SQL
• Możliwość wykonywania stopniowych aktualizacji bazy danych

Są wady. Oracle korzysta z dodatkowego rejestrowania z kluczem podstawowym lub z ograniczeniami unikatowymi/indeksem, aby logicznie rozpoznać zmodyfikowany wiersz w logicznej bazie danych rezerwowej. Gdy włączone jest rejestrowanie uzupełniające dla całej bazy danych z kluczem podstawowym i ograniczeniem przez unikalność/indeksem, każda instrukcja UPDATE zapisuje również wartości kolumn, które są niezbędne w dzienniku ponownego wykonywania, aby jednoznacznie zidentyfikować zmodyfikowany wiersz w logicznej bazie danych rezerwowej. Oracle Data Guard obsługuje replikację łańcuchową, która nazywa się tutaj „kaskadą”, jednak nie jest to typowe ze względu na złożoność konfiguracji.

Firma Oracle zaleca dodanie klucza podstawowego lub indeksu unikatowego innego niż null do tabel w podstawowej bazie danych, gdy tylko jest to możliwe, aby zapewnić, że aplikacja SQL Apply może wydajnie zastosować ponowne aktualizacje danych w logicznej rezerwowej bazie danych. Oznacza to, że nie działa w żadnej konfiguracji, może być konieczne zmodyfikowanie aplikacji.

Architektura Oracle Golden Gate — jak to działa

Dzięki Data Guard, gdy bloki są zmieniane w bazie danych, rekordy są dodawane do dziennika przeróbek. Następnie, w zależności od uruchomionego trybu replikacji, te rekordy dziennika zostaną natychmiast skopiowane do stanu wstrzymania lub przeszukane pod kątem poleceń SQL i zastosowane. Golden Gate działa w inny sposób.

Golden Gate replikuje zmiany tylko po zatwierdzeniu transakcji, więc jeśli masz długo trwającą transakcję, replikacja może zająć trochę czasu. „Proces wyodrębniania” Golden Gate utrzymuje zmiany transakcyjne w pamięci.

Kolejną dużą różnicą jest to, że Oracle Golden Gate umożliwia wymianę i manipulację danymi na poziomie transakcji między wieloma heterogenicznymi platformami. Nie ograniczasz się tylko do bazy danych Oracle. Zapewnia elastyczność w wyodrębnianiu i replikowaniu wybranych rekordów danych, zmian transakcyjnych i zmian w DDL (języku definicji danych) w różnych topologiach.

Typowy przepływ Golden Gate pokazuje nowe i zmienione dane bazy danych przechwycone ze źródłowej bazy danych. Przechwycone dane są zapisywane w pliku zwanym śladem źródłowym. Ślad jest następnie odczytywany przez pompę danych, przesyłany przez sieć i zapisywany w zdalnym pliku śladów przez proces kolektora. Funkcja dostarczania odczytuje zdalny ślad i aktualizuje docelową bazę danych. Każdy z komponentów jest zarządzany przez proces menedżera.

Replikacja logiczna MySQL – jak to działa

Replikacja w MySQL istnieje od dłuższego czasu i przez lata ewoluowała. Istnieją różne sposoby włączenia replikacji MySQL, w tym replikacja grupowa, klastry Galera, asynchroniczne „Master to Slave”. Aby porównać architekturę Oracle i MySQL, skupimy się na formatach replikacji, ponieważ jest to podstawa dla wszystkich różnych typów replikacji.

Po pierwsze, różne formaty replikacji odpowiadają formatowi rejestrowania binarnego określonemu w pliku konfiguracyjnym my.cnf. Niezależnie od formatu logi są zawsze przechowywane w postaci binarnej, której nie można wyświetlić w zwykłym edytorze. Istnieją trzy typy formatów:oparte na wierszach, oparte na instrukcjach i mieszane. Mieszany to połączenie dwóch pierwszych. Przyjrzymy się oświadczeniom i opartym na wierszach.

Statement based – w tym przypadku są to zapytania pisemne. Nie wszystkie instrukcje modyfikujące dane (takie jak instrukcje INSERT DELETE, UPDATE i REPLACE) można replikować za pomocą replikacji opartej na instrukcjach. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() itp. nie zostaną zreplikowane.

Wierszowe – w tym przypadku są to zmiany w rekordach. Wszystkie zmiany można replikować. To najbezpieczniejsza forma replikacji. Od wersji 5.7.7 jest to opcja domyślna.

Przyjrzyjmy się teraz, co dzieje się pod maską, gdy włączona jest replikacja.

Przede wszystkim baza danych master zapisuje zmiany w pliku o nazwie log binarny lub log binlog. Zapisywanie w dzienniku binarnym jest zwykle czynnością lekką, ponieważ zapisy są buforowane i sekwencyjne. Plik dziennika binarnego przechowuje dane, które urządzenie podrzędne replikacji będzie później przetwarzać, a aktywność główna nie jest od nich zależna. Kiedy rozpocznie się replikacja, mysql uruchomi trzy wątki. Jeden na pana, dwa na niewolnika. Master ma wątek, zwany wątkiem zrzutu, który odczytuje dziennik binarny mastera i dostarcza go do slave'a.

Na urządzeniu podrzędnym proces zwany wątkiem IO łączy się z urządzeniem nadrzędnym, odczytuje zdarzenia dziennika binarnego z urządzenia nadrzędnego w miarę ich wprowadzania i kopiuje je do lokalnego pliku dziennika zwanego dziennikiem przekaźników. Drugi proces podrzędny – wątek SQL – odczytuje zdarzenia z dziennika przekaźnika przechowywanego lokalnie na podrzędnym replikacji, a następnie je wykorzystuje.

MySQL obsługuje replikację łańcuchową, która jest bardzo łatwa w konfiguracji. Slave, które są również masterami, muszą działać z parametrami --log-bin i --log-slave-update.

Aby sprawdzić stan replikacji i uzyskać informacje o wątkach, uruchamiasz na urządzeniu podrzędnym:

MariaDB [(brak)]> pokaż status urządzenia podrzędnego\G*************************** 1. wiersz ** ************************* Slave_IO_State:Oczekiwanie na wysłanie zdarzenia przez urządzenie master Master_Host:master Master_User:rpl_user Master_Port:3306 Connect_Retry:10 Master_Log_File:binlog.000005 Read_Master_Log_Pos:339 Relay_Log_File:relay-bin.000002 Relay_Log_Pos:635 Relay_Master_Log_File:binlog.000005 Slave_IO_Running:Yes Slave_SQL_Running:Yes Replicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno:0 Last_Error:Skip_Counter:0 Exec_Master_Log_Pos:339 Relay_Log_Space:938 Until_Condition:Brak Until_Log_File :Until_Log_Pos:0 Master_SSL_Allowed:No Master_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master:0Master_SSL_Verify_Server_Cert:No Last_IO_Errno:0 Last_IO_Error:Last_SQL_Errno:0 Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id:1 Master_SSL_Crl:Master_SSL_Crlpath:Using_Gtid:Current_Pos Gtid_IO_Pos:0-1- 8 Replicate_Do_Domain_Ids:Replicate_Ignore_Domain_Ids:Parallel_Mode:konserwatywny SQL_Delay:0 SQL_Remaining_Delay:NULL Slave_SQL_Running_State:Slave odczytał cały dziennik przekazywania; czekanie, aż wątek we/wy podrzędnego zaktualizuje go1 wiersz w zestawie (0,00 s) 

Konfigurowanie replikacji logicznej Data Guard w Oracle

1. Utwórz fizyczną bazę danych gotowości

   Aby utworzyć logiczną rezerwową bazę danych, należy najpierw utworzyć fizyczną rezerwową bazę danych, a następnie przenieść ją do logicznej rezerwowej bazy danych.

2. Zatrzymaj ponawianie stosowania w fizycznej bazie danych gotowości

   Zatrzymanie Ponów Zastosuj jest konieczne, aby uniknąć stosowania zmian.

   SQL> ZMIEŃ ODZYSKIWANIE BAZY DANYCH ZARZĄDZANE STANOWISKO ANULOWANIE BAZY DANYCH; 

3. Przygotuj podstawową bazę danych do obsługi logicznej rezerwowej bazy danych

   Zmień atrybut VALID_FOR w oryginalnym LOG_ARCHIVE_DEST_1 i dodaj LOG_ARCHIVE_DEST_3 dla logicznej bazy danych.

   LOG_ARCHIVE_DEST_1='LOCATION=/arch1/kilka lat/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=kilka lat'LOG_ARCHIVE_DEST_3='LOCATION=/arch2/kilka lat/(LEW_BYD. WŁĄCZ

   Tworzenie słownika w danych Redo

   SQL> WYKONAJ DBMS_LOGSTDBY.BUILD; 

4. Konwertuj na logiczną rezerwową bazę danych

   Aby kontynuować ponawianie danych w fizycznej rezerwowej bazie danych, dopóki nie będzie ona gotowa do konwersji na logiczną rezerwową bazę danych, wydaj następującą instrukcję SQL:

   SQL> ZMIEŃ ODZYSKIWANIE BAZY DANYCH DO GOTOWOŚCI LOGICZNEJ nazwa_db; 

5. Dostosuj parametry inicjalizacji bazy danych w trybie gotowości logicznej

   LOG_ARCHIVE_DEST_1='LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote'LOG_ARCHIVE_DEST_2='SERVICE=kilka lat_LOG_FORNIC. /arch2/severalnines_remote/VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_DEST_STATE_3>

6. Otwórz bazę danych w trybie gotowości logicznej

   SQL> ALTER DATABASE OPEN RESETLOGS; 

   Sprawdź, czy baza danych w trybie gotowości logicznej działa prawidłowo

   widok v$data_guard_stats

   SQL> COL FORMAT WARTOŚCI A20SQL> COL FORMAT WARTOŚCI A12SQL> COL FORMAT JEDNOSTKI A30SQL> SELECT NAZWA, WARTOŚĆ, JEDNOSTKA Z V$Data_Guard_STATS; NAZWA WARTOŚĆ JEDNOSTKA -------------------- ------------ --------------- ---------------zastosuj czas zakończenia +00 00:00:00 dzień(2) do sekundy(1) odstęp zastosuj opóźnienie +00 00:00:00 dzień(2) do sekundy( 0) interwał transport lag +00 00:00:00 dzień(2) do sekund(0) interwał 

   widok v$logstdby_process

   SQL> KOLUMNA SERIAL# FORMAT 9999SQL> KOLUMNA SID FORMAT 9999SQL> SELECT SID, SERIAL#, SPID, TYP, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# TYP SPID HIGH_SCN ----- ------- ----------- ----- ----- -----48 6 11074 KOORDYNATOR 7178242899 56 56 10858 CZYTNIK 7178243497 46 1 10860 KONSTRUKTOR 7178242901 45 1 10862 PRZYGOTOWAWCZY 7178243295 37 1 10864 ANALIZATOR 7178242900 36 1 10866 APLIKATOR 7178239467 35 3 10868 APLIKATOR 7178239463 7178239463 34 7 7 10823L APLIKACJA Wybrano 9 wierszy.