MySQL to otwarty relacyjny system zarządzania bazami danych, który jest powszechnie używany do zarządzania i przechowywania danych strukturalnych. Jest znany z prostoty, łatwości użycia i skalowalności, co czyni go popularnym wyborem dla różnych aplikacji, od małych stron internetowych po duże przedsiębiorstwa.
Aby zapewnić synchronizację danych w czasie rzeczywistym, podstawowym wymaganiem jest jej realizacja na bazie dzienników (logów), co umożliwia niemal natychmiastową synchronizację danych. Nie nakłada to dodatkowych ograniczeń na projektowanie i wdrażanie samej bazy danych. Celem replikacji synchronicznej MySQL w architekturze aktywny-aktywny (synchronous replication) jest zapewnienie ciągłej dostępności i odporności na błędy. Poniżej przedstawiono 4 metody osiągnięcia synchronicznej replikacji aktywny-aktywny w MySQL.
Replikacja typu master-master w oparciu o natywną funkcję replikacji bazy danych MySQL
Zwykle nadaje się do mniejszych i średnich wdrożeń.
W tej architekturze dwa węzły mogą przyjąć prosty tryb dual-master i korzystać z dedykowanego połączenia. W przypadku awarii węzła master_A połączenia aplikacji mogą szybko przełączyć się na węzeł master_B, i odwrotnie.
Aby uniknąć scenariuszy split-brain, w których oba węzły zapisują sprzeczne dane, ważne jest, aby ustawić różne wartości dla parametrów auto-increment-increment i auto-increment-offset na obu węzłach. Dzieje się tak dlatego, że jeśli główny węzeł niespodziewanie ulegnie awarii lub stanie się niedostępny, istnieje możliwość, że niektóre zdarzenia binlog nie zostaną skopiowane na węzeł podrzędny. W takich przypadkach mogą wystąpić konflikty między generowaną wartością auto-increment na węźle podrzędnym a oryginalną wartością na węźle głównym.
Jednak, jeśli istnieje odpowiedni mechanizm odporny na błędy, który może rozwiązać konflikty ID autoinkrementacji w relacji master-slave, można uniknąć stosowania takiej metody. W zaktualizowanych wersjach MySQL 5.7+, wykorzystanie replikacji wielowątkowej może znacząco zmniejszyć opóźnienie replikacji. Dodatkowo, innym alternatywnym rozwiązaniem, które jest szczególnie wrażliwe na opóźnienie replikacji, jest replikacja pół-synchroniczna, oferująca praktycznie brak opóźnienia. Może ona jednak spowodować spadek wydajności współbieżności transakcji, zwłaszcza przy zapisie dwukierunkowym. Do podjęcia decyzji wymagana jest kompleksowa ocena.
Rozwiązanie oparte na replikacji Galera
Galera to mechanizm replikacji danych w wielu masterach, oferowany przez Codership. Umożliwia synchroniczną replikację danych oraz operacje odczytu i zapisu na wielu węzłach, zapewniając wysoką dostępność i spójność danych w bazie danych. Główne rozwiązania zapewniające wysoką dostępność oparte na Galera to MariaDB Galera Cluster oraz Percona XtraDB Cluster (PXC).
Obecnie PXC jest bardziej powszechnie stosowany i zapewnia ścisłą spójność danych, co czyni go szczególnie odpowiednim dla e-commerce. Jednakże PXC ma również swoje ograniczenia. W scenariuszach z dużym wolumenem jednoczesnych transakcji, zaleca się zastosowanie sieci InfiniBand, aby zmniejszyć opóźnienie sieciowe. Dzieje się tak ponieważ PXC może napotykać problem wzmacniania operacji zapisu oraz efekt wąskiego gardła, co powoduje znaczącą utratę wydajności współbieżnych operacji. Podobnie jak replikacja półsynchroniczna, replikacja Galera jest zazwyczaj ograniczona do trzech węzłów. Ponadto, fluktuacje sieciowe mogą powodować problemy z wydajnością i stabilnością.
Rozwiązanie oparte na replikacji grupowej
MGR (MySQL Group Replication) to oficjalnie zaprezentowane przez MySQL rozwiązanie o wysokiej dostępności. Zapewnia silne gwarancje spójności danych pomiędzy węzłami w klastrze bazy danych dzięki protokołowi Paxos. MGR bazuje na natywnej technologii replikacji i jest oferowane jako wtyczka. Pozwala na zapisywanie danych ze wszystkich węzłów w klastrze, eliminując ograniczenia wydajności pojedynczego klastra, rozwiązując problem rozpadu sieciowego powodującego konflikty split-brain oraz poprawiając niezawodność replikowanych danych.
Jednak rzeczywistość jest dość surowa. Obecnie nie ma zbyt wielu wczesnych adeptów MGR. Dodatkowo obsługuje ona jedynie tabele InnoDB i wymaga, aby każda tabela miała klucz podstawowy do wykrywania konfliktów zestawów zapisu. Funkcja GTID musi być włączona, a format dziennika binarnego ustawiony na ROW w celu wyboru lidera i zestawu zapisu.
POWÓD może zakończyć się niepowodzeniem, podobnie jak w przypadku scenariuszy awarii na poziomie izolacji migawek. Obecnie klaster MGR (MySQL Group Replication) obsługuje maksymalnie 9 węzłów. Nie obsługuje kluczy obcych oraz funkcji punktów zapisu, uniemożliwiając sprawdzanie globalnych ograniczeń i częściowe wycofywanie zmian. Dziennik binarny nie obsługuje sumy kontrolnej zdarzeń binlog.
Rozwiązanie oparte na Canal
Aby uzyskać synchronizację bazy danych w czasie rzeczywistym, Alibaba ma specjalny projekt open source o nazwie Otter, który umożliwia synchroniczne replikowanie rozproszonej bazy danych. Podstawową ideą Otter nadal jest przechwytywanie dzienników danych przyrostowych baz danych w celu osiągnięcia niemal natychmiastowej synchronicznej replikacji. Otter sam w sobie opiera się na innym projekcie open source zwanym Canal, który koncentruje się na przechwytywaniu informacji dziennika synchronizacji przyrostowej bazy danych.
Obecnie Otter koncentruje się na osiągnięciu synchronicznej replikacji między bazami danych MySQL. Wykorzystuje podobne technologie do zrealizowania dwukierunkowej synchronicznej replikacji między dwiema bazami danych MySQL. Warto zaznaczyć, że dwukierunkowość oznacza tutaj możliwość synchronizacji danych z A do B oraz z B do A, jednak w konkretnej chwili może ona być jednokierunkowa.
Proces replikacji master-slave można podzielić na trzy kroki:
1. Mistrz zapisuje zmiany w dzienniku binarnym, który jest znany jako zdarzenia dziennika binarnego. Te zdarzenia można wyświetlić za pomocą polecenia "show binlog events".
2. Slajd kopiuje zdarzenia dziennika binarnego z serwera głównego do własnego dziennika pośredniego.
3. Slave będzie sekwencyjnie odtwarzał zdarzenia zapisane w logu rejestrowym, aby zastosować zmiany z serwera głównego do swoich własnych danych.
Zasada działania kanału jest stosunkowo prosta:
1. Canal symuluje protokół interakcji MySQL slave, udając się za MySQL slave i wysyłając żądanie zrzutu do głównego serwera MySQL.
2. Po otrzymaniu żądania zrzutu, główny serwer MySQL zaczyna przesyłać dzienniki binarne do serwera podrzędnego (czyli Canal).
3. Następnie Canal analizuje obiekty dziennika binarnego (pierwotnie w formacie strumienia bajtów), aby wyodrębnić odpowiednie informacje.
Tworzenie kopii zapasowych baz danych MySQL za pomocą Vinchin Backup & Recovery
Aby lepiej chronić dane, zaleca się wykonywanie kopii zapasowych baz danych. Vinchin Backup & Recovery umożliwia skuteczną ochronę baz danych zarówno w maszynach wirtualnych, jak i na serwerach fizycznych. Dzięki dobrej współpracy z backupem na poziomie maszyn wirtualnych, użytkownicy środowisk wirtualnych otrzymują podwójne zabezpieczenie dla swoich kluczowych danych i systemów informacyjnych.
Vinchin Backup & Recovery umożliwia ochronę Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro i MariaDB zainstalowanych zarówno na maszynach fizycznych, jak i wirtualnych dzięki zaawansowanym funkcjom tworzenia kopii zapasowych i przywracania baz danych. Oferuje również strategie tworzenia kopii zapasowych: pełnej, różnicowej, przyrostowej oraz dziennika transakcji, pozwalając dostosować plan tworzenia kopii zapasowych do własnych potrzeb.
Tworzenie kopii zapasowych i odzyskiwanie danych Vinchin umożliwiają wydajne wykonywanie gorących kopii zapasowych bez wpływu na normalną pracę baz danych oraz łatwe tworzenie niestandardowych zadań tworzenia kopii zapasowych baz danych.
1 Wybierz bazę danych docelową
2 Wybierz miejsce przechowywania kopii zapasowej
3 Wybierz strategie tworzenia kopii zapasowych
4 Wyślij pracę
Możesz zacząć korzystać z tego zaawansowanego systemu dzięki 60-dniowej wersji próbnej z pełnymi funkcjami. Kliknij przycisk, aby pobrać pakiet instalacyjny. Kliknij tutaj, aby dowiedzieć się więcej o tworzeniu kopii zapasowych MySQL za pomocą Vinchin Backup & Recovery.
Podsumowanie
Replikacja MySQL active-active synchroniczna została zaprojektowana w celu zapewnienia wysokiej dostępności i elastyczności. Pozwala na jednoczesne działanie wielu instancji MySQL i synchronizację danych pomiędzy nimi, umożliwiając dwukierunkowe operacje odczytu i zapisu. Gwarantuje ciągłą dostępność, równoważenie obciążenia, spójność danych i elastyczność. Jednakże, odpowiednia konfiguracja i zarządzanie są kluczowe, a wybór rozwiązania i narzędzi implementacyjnych zależy od konkretnych wymagań.
Aby skutecznie chronić dane w bazie danych, możesz wybrać Vinchin Backup & Recovery, aby łatwo wykonywać kopie zapasowe i odzyskiwać dane. Nie przegap darmowej wersji próbnej.
