Verteiltes DBMS - Replikationssteuerung

Dieses Kapitel befasst sich mit der Replikationssteuerung, die erforderlich ist, um an allen Standorten konsistente Daten zu erhalten. Wir werden die Replikationssteuerungstechniken und die für die Replikationssteuerung erforderlichen Algorithmen untersuchen.

Wie vorhin besprochen, replicationist eine Technik, die in verteilten Datenbanken verwendet wird, um mehrere Kopien einer Datentabelle an verschiedenen Standorten zu speichern. Das Problem bei mehreren Kopien an mehreren Standorten ist der Aufwand für die Aufrechterhaltung der Datenkonsistenz, insbesondere bei Aktualisierungsvorgängen.

Um an allen Standorten konsistente Daten zu erhalten, müssen Replikationssteuerungstechniken angewendet werden. Es gibt zwei Ansätze zur Replikationssteuerung:

Synchrone Replikationssteuerung
Asynchrone Replikationssteuerung

Synchrone Replikationssteuerung

Beim synchronen Replikationsansatz wird die Datenbank synchronisiert, sodass alle Replikationen immer den gleichen Wert haben. Eine Transaktion, die ein Datenelement anfordert, hat an allen Standorten Zugriff auf denselben Wert. Um diese Einheitlichkeit sicherzustellen, wird eine Transaktion, die ein Datenelement aktualisiert, erweitert, sodass die Aktualisierung in allen Kopien des Datenelements erfolgt. Im Allgemeinen wird zu diesem Zweck ein zweiphasiges Festschreibungsprotokoll verwendet.

Betrachten wir zum Beispiel eine Datentabelle PROJECT (PId, PName, PLocation). Wir müssen eine Transaktion T1 ausführen, die PLocation auf 'Mumbai' aktualisiert, wenn PLocation 'Bombay' ist. Wenn keine Replikationen vorhanden sind, lauten die Operationen in Transaktion T1 -

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

Wenn die Datentabelle zwei Replikate an Standort A und Standort B enthält, muss T1 zwei untergeordnete Knoten T1A und T1B erzeugen, die den beiden Standorten entsprechen. Die erweiterte Transaktion T1 lautet -

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;

Asynchrone Replikationssteuerung

Beim asynchronen Replikationsansatz behalten die Replikate nicht immer den gleichen Wert bei. Ein oder mehrere Replikate können einen veralteten Wert speichern, und eine Transaktion kann die verschiedenen Werte anzeigen. Der Vorgang, bei dem alle Replikate auf den aktuellen Wert gebracht werden, wird aufgerufensynchronization.

Eine beliebte Synchronisationsmethode ist die Store-and-Forward-Methode. Bei dieser Methode wird ein Standort als primärer Standort festgelegt, und die anderen Standorte sind sekundäre Standorte. Die primäre Site enthält immer aktualisierte Werte. Alle Transaktionen werden zuerst am primären Standort eingegeben. Diese Transaktionen werden dann für die Anwendung an den sekundären Standorten in die Warteschlange gestellt. Die sekundären Standorte werden mithilfe der Rollout-Methode nur aktualisiert, wenn eine Transaktion für die Ausführung geplant ist.

Replikationssteuerungsalgorithmen

Einige der Replikationssteuerungsalgorithmen sind -

Algorithmus zur Steuerung der Master-Slave-Replikation.
Verteilter Abstimmungsalgorithmus.
Mehrheitskonsensalgorithmus.
Zirkulierender Token-Algorithmus.

Algorithmus zur Steuerung der Master-Slave-Replikation

Es gibt eine Master-Site und 'N' Slave-Sites. Am Master-Standort wird ein Master-Algorithmus ausgeführt, um Konflikte zu erkennen. An jedem Slave-Standort wird eine Kopie des Slave-Algorithmus ausgeführt. Der Gesamtalgorithmus wird in den folgenden zwei Phasen ausgeführt:

Transaction acceptance/rejection phase- Wenn eine Transaktion in den Transaktionsmonitor eines Slave-Standorts eingeht, sendet der Slave-Standort eine Anforderung an den Master-Standort. Die Master-Site sucht nach Konflikten. Wenn keine Konflikte vorliegen, sendet der Master eine "ACK +" - Nachricht an den Slave-Standort, der dann die Transaktionsanwendungsphase startet. Andernfalls sendet der Master eine "ACK-" Nachricht an den Slave, der die Transaktion dann ablehnt.
Transaction application phase- Beim Eintritt in diese Phase sendet die Slave-Site, an der die Transaktion eingegeben wurde, eine Anfrage an alle Slaves zur Ausführung der Transaktion. Beim Empfang der Anforderungen führen die Peer-Slaves die Transaktion aus und senden nach Abschluss eine „ACK“ an den anfordernden Slave. Nachdem der anfordernde Slave von allen Peers "ACK" -Nachrichten erhalten hat, sendet er eine "DONE" -Nachricht an die Master-Site. Der Master versteht, dass die Transaktion abgeschlossen wurde, und entfernt sie aus der ausstehenden Warteschlange.

Verteilter Abstimmungsalgorithmus

Dies umfasst 'N' Peer-Sites, die alle eine Transaktion "OK" machen müssen, bevor sie ausgeführt werden kann. Es folgen die beiden Phasen dieses Algorithmus:

Distributed transaction acceptance phase- Wenn eine Transaktion in den Transaktionsmanager einer Site eingeht, sendet sie eine Transaktionsanforderung an alle anderen Sites. Beim Empfang einer Anfrage löst eine Peer-Site Konflikte mithilfe prioritätsbasierter Abstimmungsregeln. Wenn alle Peer-Sites mit der Transaktion „OK“ sind, startet die anfordernde Site die Anwendungsphase. Wenn eine der Peer-Sites eine Transaktion nicht „OK“ macht, lehnt die anfordernde Site die Transaktion ab.
Distributed transaction application phase- Beim Eintritt in diese Phase sendet die Site, an der die Transaktion eingegeben wurde, eine Anfrage an alle Slaves zur Ausführung der Transaktion. Beim Empfang der Anforderungen führen die Peer-Slaves die Transaktion aus und senden nach Abschluss eine "ACK" -Nachricht an den anfordernden Slave. Nachdem der anfordernde Slave von allen Peers "ACK" -Nachrichten erhalten hat, teilt er dem Transaktionsmanager mit, dass die Transaktion abgeschlossen wurde.

Mehrheitskonsensalgorithmus

Dies ist eine Abweichung vom verteilten Abstimmungsalgorithmus, bei dem eine Transaktion ausgeführt werden darf, wenn eine Mehrheit der Peers eine Transaktion „OK“ macht. Dies ist in drei Phasen unterteilt -

Voting phase- Wenn eine Transaktion in den Transaktionsmanager einer Site eingeht, sendet sie eine Transaktionsanforderung an alle anderen Sites. Beim Empfang einer Anforderung prüft eine Peer-Site anhand von Abstimmungsregeln auf Konflikte und hält die etwaigen widersprüchlichen Transaktionen in der ausstehenden Warteschlange. Dann sendet es entweder eine "OK" - oder eine "NICHT OK" -Nachricht.
Transaction acceptance/rejection phase- Wenn die anfordernde Site bei der Transaktion die Mehrheit "OK" erhält, akzeptiert sie die Transaktion und sendet "ACCEPT" an alle Sites. Andernfalls wird "REJECT" an alle Sites gesendet und die Transaktion abgelehnt.
Transaction application phase- Wenn eine Peer-Site eine "REJECT" -Nachricht empfängt, entfernt sie diese Transaktion aus ihrer ausstehenden Liste und überprüft alle zurückgestellten Transaktionen erneut. Wenn eine Peer-Site eine "ACCEPT" -Nachricht empfängt, wendet sie die Transaktion an und lehnt alle zurückgestellten Transaktionen in der ausstehenden Warteschlange ab, die mit dieser Transaktion in Konflikt stehen. Nach Abschluss sendet es eine „ACK“ an den anfordernden Slave.

Zirkulierender Token-Algorithmus

Bei diesem Ansatz werden die Transaktionen im System unter Verwendung eines zirkulierenden Tokens serialisiert und entsprechend für jedes Replikat der Datenbank ausgeführt. Somit werden alle Transaktionen akzeptiert, dh keine wird abgelehnt. Dies hat zwei Phasen -

Transaction serialization phase- In dieser Phase sollen alle Transaktionen in einer Serialisierungsreihenfolge ausgeführt werden. Jeder Transaktion an jedem Standort wird ein eindeutiges Ticket aus einer sequentiellen Serie zugewiesen, das die Reihenfolge der Transaktion angibt. Sobald einer Transaktion ein Ticket zugewiesen wurde, wird es an alle Standorte gesendet.
Transaction application phase- Wenn eine Site eine Transaktion zusammen mit ihrem Ticket empfängt, platziert sie die Transaktion gemäß ihrem Ticket zur Ausführung. Nach Abschluss der Ausführung der Transaktion sendet diese Site eine entsprechende Nachricht. Eine Transaktion endet, wenn die Ausführung an allen Standorten abgeschlossen ist.