Zum Inhalt springen

Hochverfügbarkeitsdatenbank (HA DB)

RDM, das Datenbankverwaltungssystem, wurde entwickelt, um Hochverfügbarkeit und überlegene Verfügbarkeit zu gewährleisten. RDM repliziert und spiegelt Ihre Daten nahtlos zwischen verschiedenen Umgebungen und bietet Ihnen nahezu Echtzeitzugriff auf verwaltete Daten ohne Ausfallzeiten.

Was ist Datenbankreplikation?

Bei der Datenbankreplikation werden Daten aus einer Datenbank auf eine oder mehrere Kopien oder Replikate kopiert, um normalerweise die Zugänglichkeit oder Fehlertoleranz zu verbessern.

Die Begriffe "aktive Replikation" und "passive Replikation" werden manchmal verwendet, um die Funktionsweise dieses Prozesses zu charakterisieren. Wie in Wikipedia definiert, wird die aktive Replikation durchgeführt, indem bei jedem Replikat dieselbe Anforderung verarbeitet wird. Bei der passiven Replikation wird jede Anforderung auf einem einzelnen Replikat verarbeitet und anschließend ihr Status auf die anderen Replikate übertragen.

Replikationsfähigkeiten von RDM

Raima Database Manager (RDM) unterstützt beide Techniken; In der Raima-Dokumentation wird die aktive Replikation nur als "Replikation" bezeichnet, während die passive Replikation als "Spiegelung" bezeichnet wird. Im Kontext von RDM führt die Spiegelung zu Kopien, die Byte für Byte mit der ursprünglichen Datenbank identisch sind, während die Replikation zu Kopien führt, die nicht identisch sind. Diese Kopien enthalten alle vom Original übertragenen Datensätze, die physische Organisation der Datensätze in den Datenbankdateien (oder im Speicher) kann jedoch abweichen. Die Kopie kann auch zusätzliche Tabellen oder Indizes enthalten, die sich nie in der ursprünglichen Datenbank befanden. Oder es enthält möglicherweise nicht einige der Tabellen aus der ursprünglichen Datenbank, da RDM Enterprise Lite die gefilterte Replikation unterstützt, bei der nur die angegebenen Tabellen repliziert werden.

"Aktiv-Aktiv" vs. "Aktiv-Passiv"

Im Zusammenhang mit der Replikation sind die Begriffe "Aktiv-Aktiv" und "Aktiv-Passiv" ebenfalls gebräuchlich, beziehen sich jedoch auf andere Konzepte als die gerade beschriebenen. Aktiv-Aktiv-Replikation bedeutet bidirektionale Replikation von Daten zwischen zwei Datenbanken, die beide aktiv aktualisiert werden, und wird auch als "Multi-Master-Replikation" bezeichnet. Aktiv-Passiv-Replikation bedeutet eine Einwegreplikation von einer Master-Datenbank, die aktiv aktualisiert wird, zu einer Slave-Datenbank, die nur durch den Replikationsprozess aktualisiert wird. Dies wird auch als "Master-Slave" -Replikation bezeichnet.

Bei der RDM-Replikation handelt es sich immer um eine Master-Slave-Replikation, die asynchron ausgeführt wird. Es kann zwei Formen annehmen:

  1. Replikation von einer RDM-Datenbank in eine andere: Sowohl der Master als auch der Slave sind RDM-Datenbanken, wobei der Slave eine schreibgeschützte Kopie des Masters ist.
  2. Replikation von einer RDM-Datenbank auf einen anderen Datenbanktyp, z. B. eine Microsoft SQL Server-Datenbank, eine Oracle-Datenbank, eine MySQL-Datenbank oder eine RDM-SQL-Datenbank. Hier kann der Slave andere als die vom Master kopierten Daten enthalten und von anderen Anwendungen aktualisiert werden. Die Replikation ist jedoch immer noch "einseitig" in dem Sinne, dass Daten nur von der RDM-Datenbank zum Slave übertragen werden und niemals umgekehrt.

Optimierung der Replikation in eingebetteten Systemen

Im Kontext eingebetteter Systeme ist die zweite Form der Replikation nützlich, um Daten von mehreren eingebetteten Geräten zu sammeln und auf demselben Computer zu speichern, wo sie für Benutzeranfragen oder Berichte verfügbar sind. Normalerweise kommen auf einem eingebetteten Gerät gespeicherte Daten in Echtzeit von Sensoren und anderer angeschlossener Hardware an und sind sehr zeitkritisch. Jeder Vorgang, der Aktualisierungen auf dem eingebetteten Gerät blockieren oder verlangsamen kann, ist nicht akzeptabel. Ohne große CPU-Kosten können die Daten jedoch (asynchron) vom eingebetteten Gerät in eine PC-basierte Datenbank repliziert werden, in der leistungsfähigere Hardware vorhanden ist und weniger begrenzte Antwortzeiten erforderlich sind.

Unterschiede zwischen Datenreplikation und Spiegelung

In RDM gibt es einige funktionale Überschneidungen zwischen Replikation und Spiegelung, aber im Allgemeinen wird die Replikation hauptsächlich zur Verbesserung der Zugänglichkeit bereitgestellt. Durch die Verwaltung mehrerer Slave-Kopien derselben Daten auf mehreren Knoten wird ein Teil der Arbeitslast vom Master abgeladen. Dies verbessert die Aktualisierungsleistung in der Master-Datenbank und ermöglicht schnellere Lesevorgänge auf den anderen Knoten, auf denen Anwendungen auf eine lokale Slave-Kopie der Datenbank zugreifen können. In Verbindung mit der Unterstützung von RDM für Datenbankverbände können Sie so ein verteiltes Datenbanksystem erstellen. Eine Anwendung kann mehrere Datenbanken auf demselben Computer oder auf verschiedenen Computern in einer Datenbankunion öffnen und eine einheitliche Ansicht der Daten erhalten, als ob sie sich alle in derselben Datenbank befänden. Diese Unterstützung für Replikation und verteilte Datenbanken macht RDM zu einem hoch skalierbaren Datenbanksystem.

Die Replikation kann auch eine bequeme Möglichkeit sein, Konfigurationsdaten über ein Netzwerk von Prozessoren zu verbreiten. Eine Master-Datenbank kann die aktuellen Konfigurationsdaten für das System enthalten, und diese können über eine mehrschichtige Struktur auf die anderen Knoten im Netzwerk repliziert werden. Jeder Knoten kann so programmiert werden, dass er eine verfügbare Quelle zum Replizieren erkennt und eine Verbindung zu dieser herstellt. Die Replikation unterstützt speicherinterne und festplattenbasierte Datenbanken. In diesem Beispiel kann die Quelle der mehrschichtigen Replikation eine speicherinterne Datenbank sein, die von der Festplatte gelesen wird und beim Start jedes Knotens systemweit in speicherinterne lokale Datenbanken repliziert wird oben.

Datenbankspiegelung

Um eine Datenbank zu spiegeln, muss eine Byte-für-Byte-Kopie einer Datenbank an einem anderen Speicherort erstellt werden. Das Spiegeln unterscheidet sich vom Kopieren oder Sichern einer Datenbank darin, dass eine Spiegeldatenbank gleichzeitig mit der Originaldatenbank (synchron) oder so schnell wie möglich nach der Aktualisierung der Originaldatenbank (asynchron) aktualisiert wird. Seitenbilder vom Master werden auf die Slaves angewendet, um die Spiegelung zu implementieren.

Die 3 Hauptzwecke für die Spiegelung

  1. So pflegen Sie eine weitere Kopie einer Datenbank zur sicheren Aufbewahrung. Die Sicherungskopie kann eine Kopie einer In-Memory-Master-Datenbank auf der Festplatte sein.
  2. So verlagern Sie das Lesen einer Datenbank auf einen anderen Computer.
  3. Um darauf vorbereitet zu sein, die Verarbeitung auf einen anderen Computer umzuschalten, wenn der primäre Computer ausfällt. Dies wird häufig als hochverfügbare Datenbank bezeichnet.

Der Unterschied zwischen Hochverfügbarkeit und Spiegelung

Obwohl Spiegelung häufig im Zusammenhang mit Hochverfügbarkeit (HA) betrachtet wird, ist dies nicht dasselbe. HA bedeutet mehr als nur eine Spiegelung in Bezug auf die Datenbank, da HA die Fähigkeit umfasst, eine ausgefallene Komponente im System zu erkennen und darauf zu reagieren und zu einer Standby-Komponente zu wechseln (Failover). Spiegelung ist die Komponente innerhalb eines HA-Systems, die verwaltet eine redundante Kopie der Datenbank.

Spiegelungsfähigkeiten von RDM

In Raima Database Manager (RDM) verfügt die Spiegelung über eine hochmodulare und flexible Architektur, die es einfach macht, RDM-Komponenten miteinander zu verbinden, um eine Datenbankspiegelung innerhalb eines einzelnen Systems oder über mehrere Systeme hinweg zu erreichen. Die Spiegelungskomponenten können alle von einer Anwendung über veröffentlichte API-Funktionen gesteuert werden.
Im einfachsten Fall besteht die RDM-Spiegelung aus folgenden Komponenten:

  1. Eine Master-Datenbank - Diese Datenbank wird von der Anwendung kontinuierlich aktualisiert.
  2. Eine Slave-Datenbank - Dies ist eine schreibgeschützte Kopie des Masters.
  3. EIN Datenbankserver Steuern des Zugriffs auf die Master-Datenbank.
  4. Ein Datenbankserver, der den Zugriff auf die Slave-Datenbank steuert.
  5. Ein Spiegelungsagent, der geänderte Daten aus der Masterdatenbank veröffentlicht.
  6. Ein Spiegelungsagent, der die Daten von Komponente #5 abonniert und diese Daten auf seine Slave-Datenbank anwendet.

In dieser Liste gehören die Komponenten 1, 3 und 5 zum Master-System, während die Komponenten 2, 4 und 6 zum Slave-System gehören.
In der Praxis kann es aus einem der folgenden Gründe mehr Komponenten geben:

  • Es kann mehr als eine Slave-Datenbank für jeden Master geben.
  • Die Datenbankserver und Spiegelungsagenten können bei Bedarf mehrere Datenbanken verarbeiten.
  • Die Spiegelungsagenten können eine Verbindung zu mehreren anderen Spiegelungsagenten herstellen, entweder als Herausgeber oder Abonnenten.
  • Das Spiegeln kann ein mehrschichtiges System sein.

Für Parallelität optimierte Architektur

Diese Architektur ermöglicht Parallelität und verwendet Transaktionsprotokolle, die automatisch im Rahmen der Transaktionsverarbeitung von RDM generiert werden, sodass die Spiegelung den CPU-Anforderungen von RDM keinen großen Aufwand auferlegt.

Spiegeln mit RDM - synchron oder asynchron

  • Bei der synchronen Spiegelung ist nur eine Slave-Datenbank pro Master zulässig. Wenn eine Anwendung eine Transaktion in die Master-Datenbank schreibt, wird das Commit im Master erst abgeschlossen, wenn es im Slave abgeschlossen ist. Dies bedeutet, dass der Slave mit dem Master verbunden sein muss, da sonst Transaktionen in der Master-Datenbank fehlschlagen. Dies bedeutet auch, dass die synchrone Spiegelung über das Internet nicht praktikabel ist.
  • Bei der asynchronen Spiegelung sind für jeden Master mehrere Slave-Datenbanken zulässig. Die Slaves müssen nicht immer mit dem Master verbunden sein. Sie können die Verbindung trennen und später wieder herstellen, um die dazwischen aufgetretenen Aktualisierungen nachzuholen. In dieser Konfiguration werden Anwendungen, die Transaktionen in die Master-Datenbank schreiben, nicht blockiert, bis die Slave-Transaktion abgeschlossen ist.

Der Status der RDM-Komponenten kann von einer Anwendung programmgesteuert ermittelt werden, sodass die RDM-Spiegelung in ein effektives HA-System integriert werden kann. Die Anwendung stellt die Steuerlogik für das HA-System bereit: die Fähigkeit, zu bestimmen, dass ein Failover erforderlich ist, und die Gesamtsteuerung des Failovers und des Failbacks. Die RDM-Spiegelungskomponenten bieten Mechanismen zum Wechseln der Rollen von Master und Slave.

RDM wird häufig verwendet eingebettete Systeme, wobei eine Spiegeldatenbank im Speicher oder in einem vom Stammdatenbankspeicherort getrennten Dateisystem verwaltet werden kann. Diese Lösung erfordert relativ wenig zusätzliche Hardware.

In einigen eingebetteten Systemen kann die RDM-Spiegelung als Mechanismus zum Übertragen des Datenbankinhalts auf ein externes System, normalerweise ein PC-System, verwendet werden. Obwohl es für die PC-Software möglich wäre, eine direkte Verbindung zum Datenbankserver des eingebetteten Systems herzustellen, könnte dies eine unvorhersehbare Belastung für das eingebettete System darstellen, während die Spiegelung nur sehr geringe Auswirkungen hat. In dieser Situation kann entweder Spiegelung oder Replikation verwendet werden. Die Auswahl hängt normalerweise davon ab, ob die Slave-Datenbank eine Byte-für-Byte-Kopie des Masters sein muss (Spiegelung) oder nur logisch äquivalent (Replikation).