Blog

Często przed administratorami oraz architektami odpowiedzialnymi za systemy wykorzystujące bazy danych, staje wyzwanie w postaci wykorzystania rozproszonej architektury, w celu optymalizacji rozwiązania. Niezależnie od tego, jakie to rozwiązanie, pojawia się zagadnienie replikacji. I o tym kilka słów w tym artykule.

Mechanizmy replikacji w bazie danych

Zważywszy na to, że bazy danych w swoim założeniu przechowują dane, to w ogromnej większości przypadków dane te przechowywane są w systemie plików. Część z nich najczęściej znajduje się również w pamięci operacyjnej serwera, w postaci pamięci podręcznej. Dla ułatwienia będziemy się posługiwać pojęciem bloku, czyli jednostką danych o zdefiniowanym rozmiarze, która jest najmniejszym, niepodzielnym fragmentem możliwym do zapisania lub odczytania. W świecie baz danych (i nie tylko) funkcjonuje mechanizm Write-ahead logging (WAL), odpowiadający za zapisanie do osobnego pliku informacji o tym, co zostanie zapisane na dysk. Otrzymujemy zatem rozwiązanie zespołu plików oraz komplementarnego z nim dziennika zmian w tychże plikach. Na podstawie tych informacji, baza danych jest w stanie doprowadzić się do konsystentnego obrazu po nieprawidłowym zatrzymaniu (dzięki informacjom o zakończonych, bądź niedokończonych operacjach). Przyjrzyjmy się przykładowi poniżej:

Grzegorz posiada 100 eurocoinów i chce część z nich przekazać Joannie. Nasza aplikacja, dbająca o integralność danych, planuje wykonać taki blok transakcyjny:

BEGIN
UPDATE user SET balance = balance – 50 WHERE name = ‚GRZEGORZ’
UPDATE user set balance = balance + 50 WHERE name = ‚JOANNA’
COMMIT

W momencie, w którym serwer bazodanowy wykonał:

UPDATE user SET balance = balance – 50 WHERE name = ‚GRZEGORZ’

Następuje katastrofalna awaria serwera, która doprowadza do jego fizycznego wyłączenia.

Dzięki mechanizmom WAL, Grzegorz dalej ma 100 eurocoinów, a Joanna dalej 0. Jeżeli aplikacja poprawnie obsługuje przypadki awarii bazy danych, Grzegorz otrzymał stosowny komunikat zachęcający go, aby spróbował później. W przeciwnym wypadku Grzegorz miałby 50 eurocoinów, a Joanna 0. Zapewne żadne z nich nie byłoby z tego zadowolone.

Replikacja poza bazą – RAID, DRBD?

Mamy zatem dwa niezwykle istotne zasoby: pliki zawierające bloki danych bazy (wraz z indeksami i danymi nadmiarowymi) oraz dziennik zmian w tychże plikach. Od dawna istnieją mechanizmy, które pozwalają na replikację bloków na dysku mechanizmami replikacji pomiędzy urządzeniami blokowymi. Niezależnie od wybranej metody, czy wręcz filozofii (RAID – Redundant Array of Independent Disks, DRBD – Distributed Replicated Block Device, Replikacja macierzowa, etc.) dane w postaci zmienionych bloków na fizycznym bądź logicznym urządzeniu, są przesyłane i utrwalane w drugim urządzeniu.

Wymaga to takiej samej przestrzeni dyskowej jak źródłowa baza. Z przyczyn oczywistych zreplikowany system jest niedostępny dla użytkownika. Natomiast po jego udostępnieniu (tymczasowym lub permanentnym) przestajemy otrzymywać zmiany odbywające się w systemie źródłowym. Rozwiązanie jest proste, natomiast nie do końca nas zadowala. Bo czy sprzęt wie, jakie dane replikuje? Czy potrafi wykorzystać je w jakikolwiek sposób ? Odpowiedź brzmi nie.

Wymogi rynku i nieustanny rozwój oprogramowania oraz dryf globalnych rozwiązań w kierunku rozwiązań „software defined”, doprowadził do przeniesienia mechanizmów replikacji do silników bazodanowych.

Rozwój sposobów replikacji w PostgreSQL

Przeanalizujemy ten rozwój na przykładzie silnika PostgreSQL. Pojawiła się idea przesyłania przez (coraz szybszą) sieć wspomnianego wcześniej dziennika. Powstało rozwiązanie, w którym można było skopiować całą bazę danych, a następnie przez sieć przesyłać tylko dziennik. Tym sposobem silniki wiedziały o tym, że pracują w klastrze, aplikacje mogły monitorować stan tej replikacji, a sam proces przywracania dostępu do danych zajmował sekundy.

Niedługo później pojawiła się idea, że skoro dane w zapasowej bazie już są i zmiany są aplikowane na bieżąco, to można umożliwić ich odczyt. Taki klaster pozwala na zapis w źródłowej instancji i odczyt w obydwu (z pewnymi obostrzeniami, ale to poza zakresem tego artykułu).

Niemniej jednak w dalszym ciągu potrzebujemy tyle samo przestrzeni na utrzymywanie obu baz danych. Jest to rozwiązanie akceptowalne w wypadku wykorzystywania baz do celów wysokiej dostępności.

Wyzwania dla replikacji logicznej

Pojawia się jednak kolejny problem, wraz z coraz większą popularyzacją rozwiązań BI (Business Intelligence). Wyobraźmy sobie bazę danych, która ma tysiąc tabel. W pięciu z nich znajdują się dane niezbędne do wygenerowania raportu (bądź różnicowego zasilenia systemu BI). Jak więc zapewnić dostęp do tych pięciu tabel tak, aby raporty można było generować bez obciążania bazy produkcyjnej, a jednocześnie nie replikować pozostałych 99,5% bazy danych? Jak umieścić te pięć tabel na szybkich dyskach SSD tylko do celów raportowych, a do celów transakcyjnych w produkcyjnej bazie danych utrzymywać je na wolniejszych i tańszych dyskach talerzowych?

Weźmy pod uwagę również inny problem, jak przy użyciu mechanizmów bazodanowych zrealizować archiwizację danych? Najlepiej bez konieczności kopiowania danych w oknach serwisowych, bez przestojów aplikacji, czyli w możliwie najbardziej optymalny sposób.

Kolejnym wyzwaniem jest obsługa środowiska rozproszonego geograficznie, gdzie różne bazy realizują różne cele, a z uwagi na ich rozmiar, finansowo nieoptymalne jest replikowanie całości danych. Czy można utworzyć bazę będącą repliką skomponowaną z poszczególnych tabel pochodzących z wielu różnych baz źródłowych?

Te i wiele innych problemów rozwiązuje mechanizm replikacji logicznej dostępny w EuroDB – platformie bazodanowej opartej o PostgreSQL. Nastawienie na potrzeby biznesowe oraz dołączenie wielu modułów adresujących wyzwania administracyjne, w znaczący sposób ułatwia obsługę potrzeb klientów przetwarzających ogromne ilości danych. Informacje modułach EuroDB można znaleźć w poszczególnych zakładkach. Zachęcamy do zapoznania się z informacjami dotyczącymi replikacji logicznej w naszym Postgresie. Zapraszamy do kontaktu.