4.5 System testowy a system rzeczywisty

System testowy jest wyposażony tylko w funkcje niezbędne do testowania algorytmów replikacji. Rzeczywisty system transakcyjny powinien zawierać o wiele więcej elementów, niezbędnych do zapewnienia wysokiego stopnia niezawodności.

SRT nie udostępnia usług prezentacji, uwierzytelniania i autoryzacji zwykle udostępnianych przez monitor transakcyjny. Nadzór nad zleceniami jest bardzo ograniczony, a równoważenie obciążenia ogranicza się do umieszczenia zadania we wspólnej kolejce. Brak jest funkcji kontroli liczby dostępnych serwerów. Komunikacja między komponentami powinna być realizowana w sposób niezawodny -- za pomocą trwałych kolejek komunikatów lub TRPC.

W systemie testowym istnieje kronika, która pełni funkcję rejestru transakcji. Jednak rzeczywisty rejestr powinien zapewniać własności ACID -- i znajdować się na każdej z maszyn systemu. Serializator zawarty w systemie SRT pełni funkcję koordynatora transakcji -- lecz działa prawidłowo tylko w warunkach bezawaryjnej pracy. W rzeczywistości koordynator powinien trwale przechowywać kontekst przetwarzania (wykorzystując w tym celu rejestr transakcji) oraz realizować algorytm rekonstrukcji zasobów (np. bazy danych) podczas restartu maszyny po awarii.

System utrzymujący wiele kopii danych powinien być odporny na awarie połączeń między maszynami. Problem występuje już przy dwóch kopiach danych -- w momencie utraty łączności między maszyną podstawową a zapasową nie wiadomo, która z maszyn powinna się wyłączyć, a która działać dalej jako podstawowa. Jednym z rozwiązań może być dodanie dodatkowej maszyny pełniącej rolę arbitra. Ogólnie, także w przypadku większej liczby maszyn, należy ustalić zbiór działających i mogących się bez przeszkód komunikować maszyn stanowiących bezwzględną większość maszyn w systemie -- jest to problem wyboru kworum [14]. Następnym zadaniem jest wybranie maszyny, należącej do wymienionego zbioru, która będzie pełnić rolę maszyny podstawowej. Rozwiązaniem może być algorytm elekcji, opisany w [17] i [5].

Pomimo awarii maszyny podstawowej każda transakcja zrealizowana na niej musi zostać zreplikowana, aby zapewnić własność trwałości. Najprostszy algorytm zakłada, że maszyny zapasowe powinny brać udział w protokole zatwierdzenia transakcji inicjowanym na maszynie podstawowej. Jeżeli maszyna podstawowa ulegnie awarii podczas drugiej fazy protokołu 2PC, to maszyny zapasowe mogą znajdować się w stanie niepewności, który uniemożliwia kontynuację pracy4.3. Problem ten powinien zostać rozwiązany.

Jak można zauważyć, implementacja systemu transakcyjnego, który udostępnia replikację transakcji, łączy się z wieloma problemami. Ich szczegółowe omówienie wykracza poza ramy niniejszej pracy.



K. Kowalewski, R. Żmijewski
1999-12-17