Rozproszony DBMS - Kontrola replikacji

W tym rozdziale omówiono kontrolę replikacji, która jest wymagana do utrzymania spójnych danych we wszystkich lokacjach. Zbadamy techniki kontroli replikacji i algorytmy wymagane do kontroli replikacji.

Jak wspomniano wcześniej, replicationto technika używana w rozproszonych bazach danych do przechowywania wielu kopii tabeli danych w różnych witrynach. Problem z posiadaniem wielu kopii w wielu witrynach polega na obciążeniu związanym z utrzymaniem spójności danych, szczególnie podczas operacji aktualizacji.

Aby zachować wzajemnie spójne dane we wszystkich lokalizacjach, należy zastosować techniki kontroli replikacji. Istnieją dwa podejścia do kontroli replikacji, a mianowicie -

Synchroniczna kontrola replikacji
Asynchroniczna kontrola replikacji

Synchroniczna kontrola replikacji

W podejściu replikacji synchronicznej baza danych jest zsynchronizowana, aby wszystkie replikacje zawsze miały tę samą wartość. Transakcja żądająca pozycji danych będzie miała dostęp do tej samej wartości we wszystkich witrynach. Aby zapewnić tę jednolitość, transakcja, która aktualizuje element danych, jest rozszerzana tak, że dokonuje aktualizacji we wszystkich kopiach elementu danych. Zwykle do tego celu służy protokół zatwierdzania dwufazowego.

Na przykład rozważmy tabelę danych PROJECT (PId, PName, PLocation). Musimy uruchomić transakcję T1, która aktualizuje PLocation do „Mumbai”, jeśli PLocation to „Bombay”. Jeśli nie ma replikacji, operacje w transakcji T1 będą -

Begin T1: 
   Update PROJECT Set PLocation = 'Mumbai' 
   Where PLocation = 'Bombay'; 
End T1;

Jeśli tabela danych zawiera dwie repliki w Ośrodku A i Ośrodku B, T1 musi odrodzić dwa elementy podrzędne T1A i T1B odpowiadające dwóm lokalizacjom. Rozszerzona transakcja T1 będzie -

Begin T1: 
   Begin T1A : 
      Update PROJECT Set PLocation = 'Mumbai' 
      Where PLocation = 'Bombay'; 
   End T1A;  
	
   Begin T2A : 
      Update PROJECT Set PLocation = 'Mumbai'
      Where PLocation = 'Bombay'; 
   End T2A; 
	
End T1;

Asynchroniczna kontrola replikacji

W podejściu replikacji asynchronicznej repliki nie zawsze zachowują tę samą wartość. Co najmniej jedna replika może przechowywać nieaktualną wartość, a transakcja może wyświetlać różne wartości. Nazywa się proces przywracania wszystkich replik do aktualnej wartościsynchronization.

Popularną metodą synchronizacji jest metoda store and forward. W tej metodzie jedna lokacja jest wyznaczana jako lokacja główna, a pozostałe lokacje są lokacjami dodatkowymi. Lokacja główna zawsze zawiera zaktualizowane wartości. Wszystkie transakcje najpierw trafiają do lokacji głównej. Transakcje te są następnie umieszczane w kolejce do zastosowania w lokacjach dodatkowych. Lokacje dodatkowe są aktualizowane przy użyciu metody wdrażania tylko wtedy, gdy zaplanowano wykonanie transakcji.

Algorytmy kontroli replikacji

Niektóre z algorytmów kontroli replikacji to:

Algorytm sterowania replikacją typu master-slave.
Rozproszony algorytm głosowania.
Algorytm konsensusu większości.
Algorytm krążącego tokena.

Algorytm sterowania replikacją typu master-slave

Jest jedna witryna główna i witryny podrzędne „N”. Algorytm nadrzędny działa w ośrodku wzorcowym w celu wykrywania konfliktów. Kopia algorytmu slave działa w każdym miejscu slave. Ogólny algorytm jest wykonywany w dwóch następujących fazach -

Transaction acceptance/rejection phase- Kiedy transakcja wchodzi do monitora transakcji strony podrzędnej, strona podrzędna wysyła żądanie do strony głównej. Witryna główna sprawdza, czy nie występują konflikty. Jeśli nie ma żadnych konfliktów, master wysyła komunikat „ACK +” do witryny slave, która następnie rozpoczyna fazę składania wniosków transakcyjnych. W przeciwnym razie master wysyła komunikat „ACK-” do slave'a, który następnie odrzuca transakcję.
Transaction application phase- Po wejściu w tę fazę, strona slave, w której została zawarta transakcja, rozsyła żądanie do wszystkich slave'ów o wykonanie transakcji. Po odebraniu żądań peer slave wykonują transakcję i wysyłają „ACK” do żądającego slave'a po jej zakończeniu. Po tym, jak żądający slave otrzyma komunikaty „ACK” od wszystkich swoich peerów, wysyła komunikat „DONE” do strony głównej. Master rozumie, że transakcja została zakończona i usuwa ją z oczekującej kolejki.

Rozproszony algorytm głosowania

Obejmuje to „N” peer-site, z których wszystkie muszą „zatwierdzić” transakcję przed rozpoczęciem jej wykonywania. Poniżej przedstawiono dwie fazy tego algorytmu -

Distributed transaction acceptance phase- Gdy transakcja wchodzi do menedżera transakcji w witrynie, wysyła żądanie transakcji do wszystkich innych witryn. Po otrzymaniu żądania witryna równorzędna rozwiązuje konflikty za pomocą reguł głosowania na podstawie priorytetów. Jeśli wszystkie witryny równorzędne są „OK” z transakcją, witryna żądająca rozpoczyna fazę składania wniosków. Jeśli żadna z witryn równorzędnych nie zatwierdzi transakcji, witryna żądająca odrzuca transakcję.
Distributed transaction application phase- Po wejściu w tę fazę, strona, w której transakcja została zawarta, rozsyła żądanie do wszystkich slave'ów o wykonanie transakcji. Po odebraniu żądań równorzędne slave'y wykonują transakcję i wysyłają komunikat „ACK” do żądającego slave'a po jej zakończeniu. Po tym, jak żądający slave otrzyma komunikaty „ACK” od wszystkich swoich partnerów, informuje menedżera transakcji, że transakcja została zakończona.

Algorytm konsensusu większości

Jest to odmiana algorytmu głosowania rozproszonego, w którym transakcja może zostać wykonana, gdy większość partnerów „zgadza się” na transakcję. Dzieli się to na trzy fazy -

Voting phase- Gdy transakcja wchodzi do menedżera transakcji w witrynie, wysyła żądanie transakcji do wszystkich innych witryn. Po otrzymaniu żądania strona równorzędna sprawdza konflikty przy użyciu reguł głosowania i umieszcza konfliktowe transakcje, jeśli takie istnieją, w kolejce oczekujących. Następnie wysyła komunikat „OK” lub „NIE OK”.
Transaction acceptance/rejection phase- Jeśli strona żądająca otrzyma większość „OK” transakcji, akceptuje transakcję i rozgłasza „AKCEPTUJ” do wszystkich witryn. W przeciwnym razie wysyła komunikat „ODRZUĆ” do wszystkich witryn i odrzuca transakcję.
Transaction application phase- Kiedy strona równorzędna otrzyma komunikat „ODRZUĆ”, usuwa tę transakcję ze swojej listy oczekujących i ponownie rozpatruje wszystkie odroczone transakcje. Gdy strona równorzędna otrzyma komunikat „AKCEPTUJ”, stosuje transakcję i odrzuca wszystkie odroczone transakcje w kolejce oczekującej, które są w konflikcie z tą transakcją. Po zakończeniu wysyła „ACK” do żądającego slave'a.

Algorytm krążących tokenów

W tym podejściu transakcje w systemie są serializowane za pomocą krążącego tokena i odpowiednio wykonywane na każdej replice bazy danych. W ten sposób wszystkie transakcje są akceptowane, tj. Żadna nie jest odrzucana. Ma to dwie fazy -

Transaction serialization phase- W tej fazie wszystkie transakcje są planowane do uruchomienia w kolejności serializacji. Każdej transakcji w każdej witrynie przypisywany jest unikalny bilet z serii sekwencyjnej, wskazujący kolejność transakcji. Po przypisaniu transakcji bilet jest transmitowany do wszystkich witryn.
Transaction application phase- Gdy witryna otrzymuje transakcję wraz z biletem, umieszcza transakcję do wykonania zgodnie z biletem. Po zakończeniu transakcji ta witryna emituje odpowiedni komunikat. Transakcja kończy się po zakończeniu wykonywania we wszystkich witrynach.