Wprowadzenie replikacji danych do usług oferowanych przez system transakcyjny może w znaczący sposób podnieść poziom jego niezawodności. Przetrzymywanie danych w więcej niż jednej kopii zmniejsza szanse na ich nieodwracalne uszkodzenie, a tym samym zwiększa ich bezpieczeństwo. Dopóki jest dostępna chociaż jedna z kopii danych, dopóty wszelkie awarie można naprawić bez konieczności wyłączania systemu. Dzięki temu możliwe jest tolerowanie uszkodzeń, zarówno tych sprzętowych, jak i programowych. Skutkiem tego jest poprawa dostępności systemu.
Istnieją dwa podstawowe podejścia do problemu replikacji danych. Pierwsze zakłada, iż proces powielania jest realizowany na poziomie sprzętowym. Oznacza to, że kopiowane są operacje zapisu do pamięci trwałej (np. operacje zapisu na dysk twardy). Podejście takie ma niestety tę wadę, iż wymaga dodatkowego wspomagania sprzętowego. Ze względów wydajnościowych nie jest również możliwe zastosowanie tej metody do utrzymania kopii danych odległych geograficznie5.1.
Innym sposobem jest replikacja danych na poziomie oprogramowania. W tym przypadku różnorodność możliwych do zastosowania technik jest bardzo duża i zależy w znacznej mierze od specyfiki systemu oraz od tego, w jakim stopniu implementowany mechanizm ma być uniwersalny. Jedną z możliwych do przyjęcia technik jest powielanie danych na poziomie operacji zapisu do kroniki transakcji. Metoda ta znajduje szerokie zastosowanie we współczesnych systemach bazodanowych. Jej zaletą jest możliwość wykorzystania informacji o strukturze kroniki oraz zależnościach między kolejnymi odwołaniami do niej do zwiększenia efektywności replikacji danych. Korzystanie ze specyficznych cech konkretnej implementacji w znaczący sposób zmniejsza jednak uniwersalność projektowanego algorytmu. Skutkiem tego są ograniczone możliwości jego zastosowania. Inną wadą jest brak pełnej odporności na awarię aktywnej kopii5.2 danych. Wynika to z faktu, iż wszystkie transakcje, które są aktywne w trakcie wystąpienia awarii, muszą być wycofane, wskutek czego klient jest zmuszony do obsługi tego typu sytuacji.
W naszej pracy bazowaliśmy na modelu przetwarzania charakterystycznym dla środowiska RTR (opisanego w rozdziale 3.6). We wszystkich zaprojektowanych i przetestowanych algorytmach za podstawową jednostkę replikacji przyjęliśmy transakcję. Szereg komunikatów przesyłanych między klientem a serwerem tworzy pojedynczą transakcję. Ponieważ jednak liczba komunikatów nie wpływa znacząco na sposób działania żadnego z algorytmów, przyjęliśmy, że każda transakcja składa się z jednego komunikatu.