-
Gebiet der Erfindung
-
Die
Erfindung betrifft Techniken zum Reduzieren der Nachteile, welche
damit assoziiert sind, wenn ein Knoten Daten von einem Datenspeicher
anfordert, wenn sich die neueste Version der angeforderten Daten
im Zwischenspeicher eines anderen Knotens befindet.
-
Hintergrund der Erfindung
-
Um
die Skalierbarkeit zu verbessern, erlauben manche Datenbank-Systeme
es mehr als einem Datenbankserver (von denen jeder separat läuft) konkurrierend
auf gemeinsam benutzten Speicher, wie sie zum Beispiel auf Plattenmedien
gespeichert sind, zuzugreifen. Jeder Datenbankserver hat einen Zwischenspeicher
zum Zwischenspeichern gemeinsam benutzter Ressourcen, wie zum Beispiel
Plattenblöcke.
Solche Systeme werden hierin als Parallel-Server-Systeme bezeichnet.
-
Ein
Problem, welches mit Parallel-Server-Systemen assoziiert ist, ist
die Möglichkeit
für so genannte „Pings". Ein Ping tritt
auf, wenn die Version einer Ressource, welche sich in dem Zwischenspeicher
eines Servers befindet, zu dem Zwischenspeicher eines anderen Servers
geliefert werden muss. Dadurch tritt ein Ping auf, sobald, nachdem
ein Datenbankserver A eine Ressource x in seinem Zwischenspeicher
modifiziert hat, ein Datenbankserver B die Ressource x zum modifizieren
anfordert. Datenbankserver A und B werden typischerweise auf verschiedenen
Knoten laufen, können
aber auch in manchen Fällen
auf demselben Knoten laufen.
-
Ein
Ansatz, Pings zu handhaben wird hierin als der „Platten-Interventions"-Ansatz bezeichnet. Der Platten-Interventions-Ansatz verwendet
eine Platte als intermediären
Speicher, um die letzte Version von einer Ressource zwischen zwei
Zwischenspeichern zu übertragen.
Daher erfordert der Platten-Interventions-Ansatz,
im oben beschriebenen Beispiel, einen Datenbankserver 1, um die
Version der Ressource X aus seinem Zwischenspeicher Platte zu schreiben
und einen Datenbankserver 2, um diese Version von Platte in seinen
Zwischenspeicher zu laden. Das Stützen des Platten-Interventions-Ansatzes
auf zwei Platten E/As je Zwischenserver-Übertragung einer Ressource
limitiert die Skalierbarkeit von Parallel-Server-Systemen. Insbesondere sind
die Platten E/As, welche benötigt
werden, um ein Ping zu handhaben, relativ teuer und zeitraubend und
je mehr Datenbankserver zu dem System hinzugefügt werden, desto höher wird
die Anzahl der Pings.
-
Jedoch
sorgt der Platten-Interventions-Ansatz für eine relativ effiziente Wiederherstellung
von Einzel-Datenbankserver-Ausfällen, indem
für solch ein
Wiederherstellen nur das Ausführen
des Wiederherstellungsprotokoll (Wiederholungsprotokoll) des abgestürzten Datenbankservers
nötig ist.
Das Ausführen
des Wiederholungsprotokolls des abgestürzten Datenbankservers stellt
sicher, dass alle durchgeführten Änderungen,
welche Transaktionen auf dem abgestürzten Datenbankserver an den
Ressourcen in dem Zwischenspeicher des abgestürzten Server gemacht haben,
wiederhergestellt werden. Das Verwenden von Wiederholungsprotokollen
während einer
Wiederherstellung ist im Detail beschrieben in dem U.S. Patent 5,832,516
mit dem Titel „Caching Data
in Recoverable Objects",
eingereicht am 21. Januar 1997.
-
Parallel-Server-Systeme,
welche den Platten-Interventions-Ansatz
anwenden, verwenden typischerweise ein Protokoll, in welchem jede
global Entscheidung, welche den Ressourcenzugriff und Ressourcenmodifikationen
betrifft, mittels eines Verteilten-Sperrmanagers (DLM) durchgeführt wird.
Die Funktion eines beispielhaften DLM ist im Detail beschrieben
in dem U.S. Patent 5,596,754 mit dem Titel „Method for Performing Private
Lock Management".
-
Das
Dokument US-A-5,327,566 lehrt eine schnelle Technik zum Übertragen
von Einheiten von Daten zwischen Transaktionssystemen in einer Mehrbenutzer-Platten-Umgebung,
wo Zugriff auf die Mehrbenutzer-Ressourcen unter Verwendung eines globalen
Lock-Management-Systems in Verbindung mit lokalen Lock-Managern
verwaltet wird. Jede Seite ist mit einem bestimmten Signalspeicher
verknüpft,
welcher individuell für
jede Seite den Zugriff zu dieser Seite durch Angabe entweder einer
Genehmigung zum gemeinsamen Verwenden oder einer Genehmigung zum
ausschließenden
Sperren steuert.
-
In
typischen Verteilten-Sperrmanager-Systemen werden Informationen,
welche irgendeine gegebene Ressource betreffen, in einem Sperr-Objekt
gespeichert, welches mit der Ressource korrespondiert. Jedes Sperr-Objekt
ist in dem Speicher eines einzelnen Knoten gespeichert. Der Sperrmanager,
welcher in dem Knoten, in welchem ein Sperr-Objekt gespeichert ist, residiert, wird
als Hauptserver des Sperr-Objekts und der Ressource, die es umfasst, bezeichnet.
-
In
Systemen, welche den Platten-Interventions-Ansatz zum Handhaben
von Pings anwenden, tendieren Pings dazu, den DLM in eine Vielzahl
von sich auf Sperren beziehende Kommunikationen zu verwickeln. Insbesondere,
wenn ein Datenbankserver (der „anfordernde
Server") auf eine
Ressource zugreifen muss, prüft
der Datenbankserver darauf, ob er die gewünschte Ressource in dem passenden Modus
gesperrt hat: entweder gemeinschaftlich im Falle eines Lesens, oder
ausschließlich
im Falle eines Schreibens. Wenn der anfordernde Datenbankserver
die gewünschte
Ressource nicht in dem richtigen Modus gesperrt hat oder keinerlei
Sperre auf die Ressource hat, dann sendet der anfordernde Server eine
Anforderung zu dem Hauptserver für
die Ressource, um die Sperre im spezifiziertem Modus zu erlangen.
-
Die
Anforderung, welche von dem anfordernden Datenbankserver veranlasst
wird, kann mit dem aktuellen Status der Ressource im Konflikt stehen (z.B.
könnte
es einen anderen Datenbankserver geben, welcher jetzt eine Ausschließlich-Sperre auf die Ressource
hält).
Wenn es keinen Konflikt gibt, erteilt der Hauptserver der Ressource
die Sperre und speichert die Erteilung. Im Falle eines Konflikts
initiiert der Hauptserver der Ressource ein Konflikt-Lösungs-Protokoll.
Der Hauptserver der Ressource instruiert den Datenbankserver, welcher
die im Widerspruch stehende Sperre hält (den „Halter") seine Sperre in einen niedrigeren,
kompatiblen Modus herabzusetzen.
-
Unglücklicherweise
kann, wenn der Halter (z.B. der Datenbankserver A) jetzt eine aktualisierte („unreine") Version der gewünschten
Ressource in seinem Zwischenspeicher hat, er nicht unmittelbar seine
Sperre herabsetzen. Um seine Sperre herabzusetzen, durchläuft der
Datenbankserver A etwas, was als „Hard-Ping" Protokoll bezeichnet wird. Gemäß dem Hard-Ping
Protokoll, erzwingt Datenbankserver A, dass das Wiederholungsprotokoll,
welches mit dem Aktualisieren assoziiert ist, auf die Platte geschrieben
wird, schreibt die Ressource auf Platte, setzt seine Sperre herab
und meldet dem Hauptserver, dass Datenbankserver A fertig ist. Nach
Empfangen der Benachrichtigung registriert der Hauptserver das Erteilen
der Sperre und benachrichtigt den anfordernden Server, dass die
angeforderte Sperre erteilt wurde. Zu diesem Punkt liest der anfordernde
Server B die Ressource von der Platte in seinen Zwischenspeicher.
-
Wie
oben beschrieben, erlaubt der Platten-Interventions-Ansatz nicht, dass
eine Ressource, welche mittels eines Datenbankserver aktualisiert wurde
(eine „unreine
Ressource"), direkt
an einen anderen Datenbankserver versendet wird. Solch ein direktes
Versenden wird wegen Problemen, welche mit dem Wiederherstellen
verbunden sind, als undurchführbar
betrachtet. Beispielsweise wird angenommen, dass eine Ressource
am Datenbankserver A modifiziert wird und dann direkt zum Datenbankserver
B versendet wird. Am Datenbankserver B wird die Ressource ebenfalls
modifiziert und dann zum Datenbankserver A zurückgesendet. Im Datenbankserver
A wird die Ressource ein drittes Mal modifiziert. Ferner wird angenommen,
dass jeder Server alle Wiederholungsprotokolle auf Platte schreibt,
bevor er die Ressource zu einem anderen Server sendet, um es dem
Empfänger
zu ermöglichen,
sich auf frühere Änderungen
zu verlassen.
-
Nach
der dritten Aktualisierung wird angenommen, dass der Datenbankserver
A abstürzt.
Das Protokoll des Datenbankservers A enthält Datensätze der Modifikationen an der
Ressource mit einer Lücke.
Insbesondere enthält
das Protokoll des Servers A nicht solche Modifikationen, welche
vom Datenbankserver B gemacht wurden. Vielmehr sind die Modifikationen,
welche vom Server B gemacht wurden, in dem Protokoll des Datenbankservers
B gespeichert. An diesem Punkt müssen,
um die Ressource wiederherzustellen, die zwei Protokolle erst zusammengefügt werden,
bevor sie angewandt werden. Diese Protokoll-Zusammenfüg-Operation
würde,
wenn realisiert, Zeit und Hilfsmittel proportional zu der Gesamtanzahl
von Datenbankservern, inklusive derer, die nicht abgestürzt sind,
benötigen.
-
Der
oben beschriebene Platten-Interventions-Ansatz vermeidet das Problem,
welches mit dem Zusammenfügen
von Wiederherstellungsprotokollen nach einem Absturz verbunden ist,
aber verschlechtert die Leistungsfähigkeit von sich im Dauerzustand (Normalzustand)
befindenden Parallel-Server-Systemen
zu Gunsten einer leichten und effizienten Wiederherstellung. Der
Direkt-Versendungs-Ansatz vermeidet den Overhead, welcher mit dem
Platten-Interventions-Ansatz assoziiert ist, aber hat im Falle von Abstürzen komplexe
und nicht skalierbare Wiederherstellungs-Operationen zur Folge.
-
Basierend
auf dem Vorhergehenden ist es anschaulich wünschenswert ein System und
Verfahren zum Reduzieren des Overheads, welcher mit einem Ping assoziiert
ist, bereitzustellen, ohne die Komplexität und die Dauer der Wiederherstellungsoperationen
stark zu erhöhen.
-
Zusammenfassung der Erfindung
-
Gemäß der Erfindung,
welche im Detail in den anhängenden
unabhängigen
Ansprüchen
definiert ist, werden ein Verfahren und eine Vorrichtung zum Übertragen
einer Ressource von dem Zwischenspeicher eines Datenbankservers
zu dem Zwischenspeicher eines anderen Datenbankservers, ohne die
Ressource zuerst auf Platte zu schreiben, bereitgestellt.
-
Wenn
ein Datenbankserver (Nachfrager) wünscht, eine Ressource zu modifizieren,
fragt der Nachfrager nach der aktuellen Version der Ressource. Der
Datenbankserver, welcher die aktuelle Version hat (Halter), versendet
die aktuelle Version direkt an den Nachfrager. Nach Versenden der
Version, verliert der Halter die Genehmigung, die Ressource zu modifizieren,
aber behält
weiterhin eine Kopie der Ressource im Speicher. Wenn die behaltene
Version der Ressource oder eine spätere Version davon auf Platte
geschrieben wird, kann der Halter die behaltene Version der Ressource
verwerfen. Anderenfalls verwirft der Halter die behaltene Version
nicht. Im Falle eines Serverabsturzes, werden, so notwendig, die
früheren
Kopien aller Ressourcen mit Modifikationen in dem Wiederherstellungsprotokoll
des abgestürzten
Server als Startpunkt zum Ausführen
des Wiederherstellungsprotokolls des abgestürzten Servers verwendet. Unter
Verwenden dieser Technik werden Einzel-Server-Abstürze (die üblichste
Form von Abstürzen)
wiederhergestellt, ohne dass die Wiederherstellungsprotokolle der
verschiedenen Datenbankserver, welche Zugriff auf die Ressource
hatten, zusammengefügt
werden müssen.
-
Kurzbeschreibung der Figuren
-
Die
Erfindung ist mittels Beispiels und nicht mittels Einschränkung anhand
der Figuren der beiliegenden Zeichnungen erläutert, in welchen gleiche Bezugszeichen
sich auf ähnliche
Elemente beziehen und in welchen:
-
1 ein
Blockdiagramm ist, welches Zwischenspeicher zu Zwischenspeicher Übertragungen der
neuesten Versionen von Ressourcen erläutert;
-
2 ein
Flussdiagramm ist, welches Schritte zum Übertragen einer Ressource von
einem Zwischenspeicher zu einem anderen, ohne Platten- Intervention gemäß einem
Ausführungsbeispiel
der Erfindung erläutert;
-
3 ein
Flussdiagramm ist, welches Schritte zum Freigeben früherer Abbilder
von Ressourcen gemäß einem
Ausführungsbeispiel
der Erfindung erläutert;
-
4 ein
Flussdiagramm ist, welches Schritte zum Wiederherstellen nach einem
Absturz eines einzelnen Servers gemäß einem Ausführungsbeispiel
der Erfindung erläutert;
-
5 ein
Blockdiagramm ist, welches einen Prüfpunkt-Zyklus, gemäß einem Ausführungsbeispiel der
Erfindung, erläutert;
und
-
6 ein
Blockdiagramm eines Computersystems ist, auf welchem ein Ausführungsbeispiel der
Erfindung realisiert werden kann.
-
Detaillierte Beschreibung
des bevorzugten Ausführungsbeispiels
-
Es
werden ein Verfahren und eine Vorrichtung zum Reduzieren des Overheads,
welcher mit einem Ping assoziiert ist, beschrieben. In der folgenden
Beschreibung werden zum Zweck der Erläuterung zahlreiche spezifische
Details erklärt,
um ein vollständiges
Verständnis
der Erfindung zu schaffen. Es wird jedoch für einen Fachmann ersichtlich
sein, dass die Erfindung ohne diese spezifischen Details umgesetzt
werden kann. In anderen Datenbankservern werden allseits bekannte
Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um unnötiges Verschleiern
der Erfindung zu verhindern.
-
Funktioneller Überblick
-
Gemäß einem
Aspekt der Erfindung, werden Pings mittels direkten Versendens von
aktualisierten Versionen der Ressourcen, ohne vorher auf Platte gespeichert
worden zu sein, direkt zwischen Datenbankservern gehandhabt, wodurch
der E/A Overhead, welcher mit dem Platten-Interventions-Ansatz assoziiert
ist, vermieden wird. Ferner werden die Schwierigkeiten, welche mit
dem Wiederherstellen eines Einzelinstanz-Absturzes assoziiert sind,
vermieden, indem, sogar wenn die Ressource zu einem anderen Zwischenspeicher übertragen
wurde, verhindert wird, dass eine modifizierte Version der Ressource
im Zwischenspeicher ersetzt wird, bis die modifizierte Ressource
oder irgendein Nachfolger davon auf Platte geschrieben wurde.
-
Zum
Zweck der Erläuterung
wird eine Kopie einer Ressource, welche im Zwischenspeicher nicht ersetzt
werden kann, hierin als eine „festgehaltene" Ressource bezeichnet.
Die Handlung, eine festgehaltene Ressource ersetzbar zu machen,
wird als „Freigeben" der Ressource bezeichnet.
-
Der M- und W-Sperren-Ansatz
-
Gemäß einem
Aspekt der Erfindung sind die Genehmigungen zum Modifizieren und
Auf-Platte-Schreiben für
eine Ressource getrennt. Daher hat ein Datenbankserver, welcher
die Genehmigung hat, eine aktualisierte Version einer Ressource
vom Zwischenspeicher auf Platte zu schreiben, nicht notwendigerweise
die Genehmigung, die Ressource zu aktualisieren. Umgekehrt hat ein
Datenbankserver, welcher die Genehmigung hat, eine zwischengespeicherte
Version einer Ressource zu modifizieren, nicht Notwendigerweise
die Genehmigung, diese zwischengespeicherte Version auf Platte zu
schreiben.
-
Gemäß einem
Ausführungsbeispiel
wird diese Trennung der Genehmigungen mittels des Verwendens von
speziellen Sperren durchgesetzt. Insbesondere kann die Genehmigung,
eine Ressource zu modifizieren, mittels einer „M"-Sperre erteilt werden, während die
Genehmigung, eine Ressource auf Platte zu schreiben, mittels einer „W"-Sperre erteilt werden
kann. Es ist jedoch zu bemerken, dass das Benutzen von M- und W-Sperren wie hierin
beschrieben nur einen Mechanismus darstellt, welcher eine übertragene
Version einer Ressource davor schützt, im Zwischenspeicher ersetzt
zu werden, bis diese Version oder ein Nachfolger davon auf Platte
geschrieben wurde.
-
Bezug
nehmend auf 2 erläutert sie die Schritte, welche
in Antwort auf ein Ping in einem Datenbank-System, welches Mund
W-Sperren gemäß einem
Ausführungsbeispiel
der Erfindung, verwendet, ausgeführt
werden. In Schritt 200 fordert ein Datenbankserver, welcher
wünscht,
eine Ressource zu modifizieren, die M-Sperre vom Hauptserver der Ressource
(d.h. dem Datenbankserver, welcher die Sperren der Ressource verwaltet)
an. In Schritt 202 instruiert der Hauptserver den Datenbankserver,
welcher gerade die M-Sperre der Ressource hält („der Halter"), die M-Sperre zusammen
mit der zwischengespeicherten Version der Ressource mittels direkter Übertragung über den
Kommunikationskanal (-kanäle),
welche(r) die zwei Server koppelt(n) (die „Verbindung"), zu dem anfordernden
Datenbankserver zu übertragen.
-
In
Schritt 204 schickt der Halter die aktuelle Version der
Ressource und die M-Sperre zu dem Anforderer. In Schritt 206,
informiert der Halter den Hauptserver über die Übertragung der M-Sperre. In Schritt 208 aktualisiert
der Hauptserver die Sperren-Information für die Ressource, um anzuzeigen, dass
der Anforderer nun die M-Sperre hält.
-
PI-Ressourcen
-
Der
Halter der M-Sperre hat nicht notwendigerweise die W-Sperre und mag daher
nicht die Genehmigung haben, die Version der Ressource, welche in
seinem Zwischenspeicher enthalten ist, auf Platte heraus zu schreiben.
Der übertragende
Datenbankserver (d.h. der Datenbankserver, welcher zuletzt die M-Sperre
hielt) setzt daher fort, seine Version der Ressource im dynamischen
Speicher festzuhalten, weil er, wie unten beschrieben, zu einem
Zeitpunkt in der Zukunft aufgefordert werden könnte, seine Version herauszuschreiben.
Die Version der Ressource, welche in dem übertragenden Datenbankserver
verbleibt, wird veraltet werden, wenn der empfangende Datenbankserver
seine Kopie der Ressource modifiziert. Der übertragende Datenbankserver
wird nicht notwendigerweise wissen, wann der empfangende Datenbankserver
(oder ein Nachfolger von ihm) die Ressource modifiziert, daher behandelt
er seine verbleibende Version von der Zeit an, wo der übertragende
Datenbankserver eine Kopie der Ressource schickt, als „möglicherweise
veraltet". Solche möglicherweise
veralteten Versionen einer Ressource werden hierin als Frühere-Abbild-Ressourcen (PI-Ressourcen)
bezeichnet.
-
Freigeben von PI-Ressourcen
-
Nachdem
eine zwischengespeicherte Version einer Ressource freigegeben ist,
kann sie mit neuen Daten überschrieben
werden. Typischerweise kann eine unreine Version einer Ressource
mittels Schreibens der Ressource auf Platte freigegeben werden.
Jedoch haben Datenbankserver mit PI-Ressourcen im Zwischenspeicher nicht
Notwendigerweise das Recht, PI-Ressourcen auf Platte zu speichern. Eine
Technik zum Freigeben von PI-Ressourcen unter diesen Umständen ist
in 3 erläutert.
-
Bezugnehmend
auf 3, schickt ein Datenbankserver, wenn er wünscht, eine
PI-Ressource in seinem Zwischenspeicher freizugeben, eine Anforderung
für die
W-Sperre (Schritt 300) an den Verteilten-Sperrmanager (DLM).
Im Schritt 302 beauftragt der DLM dann den anfordernden
Datenbankserver, oder irgendeinen Datenbankserver, welcher eine neuere
Version der Ressource (ein Nachfolger) in seinem Zwischenspeicher
hat, die Ressource auf Platte herauszuschreiben. Dem Datenbankserver, welcher
so aufgefordert wird, die Ressource auf Platte zu schreiben, wird
die W-Sperre erteilt. Nachdem der Datenbankserver, welchem die W-Sperre
erteilt wurde, die Ressource auf Platte geschrieben hat, gibt der
Datenbankserver die W-Sperre frei.
-
Der
DLM sendet dann eine Nachricht zu allen Datenbankservern aus, welche
die Version der Ressource anzeigt, welche herausgeschrieben wurde
(Schritt 304), so dass alle früheren PI-Versionen der Ressource
freigegeben werden können
(Schritt 306). Beispielsweise wird angenommen dass die Version,
welche zur Zeit T10 modifiziert wurde, auf Platte geschrieben wurde.
Ein Datenbankserver mit einer Version der Ressource, welche zuletzt
zu einer früheren
Zeit T5 modifiziert wurde, könnte
jetzt den Puffer, in welchem sie gespeichert ist, für andere
Daten verwenden. Ein Datenbankserver mit einer Version, welche zu
einer späteren
Zeit T11 modifiziert wurde, müsste
jedoch fortfahren, seine Version der Ressource in seinem Speicher
zu halten.
-
Ping Management unter
dem M- und W-Sperren-Ansatz
-
Gemäß einem
Ausführungsbeispiel
der Erfindung, kann, um Pings zu handhaben, der M- und W-Sperren-Ansatz,
wie er nun mit Bezug auf 1 beschrieben werden soll, realisiert
werden Bezug nehmend auf 1 ist es ein Blockschaltbild,
welches vier Datenbankserver A, B, C, und D erläutert, von denen alle Zugang
zu einer Datenbank haben, welche eine spezielle Ressource enthält. Zu dem dargestellten
Zeitpunkt hat jeder der Datenbankserver A, B und C Versionen der
Ressource. Die Version, welche im Zwischenspeicher des Datenbankservers
A gehalten wird, ist die vor der kürzesten Zeit modifizierte Version
der Ressource (modifiziert zur Zeit T10). Die Versionen, welche
in den Datenbankservern B und C gehalten werden, sind PI-Versionen der
Ressource. Datenbankserver D ist der Hauptserver der Ressource.
-
Zu
diesem Punkt wird angenommen dass ein anderer Datenbankserver (der „Anforderer") wünscht, die
Ressource zu modifizieren. Der Anforderer fordert die Modifizier-Sperre
vom Hauptserver an. Der Hauptserver schickt einen Befehl zum Datenbankserver
A, die Sperre wegen der im Widerspruch stehenden Anforderung des
Anforderers herabzukonvertieren (ein „BAST"). In Antwort auf das Herabkonvertierungskommando,
wird das aktuelle Abbild der Ressource (egal ob sauber oder unrein)
vom Datenbankserver A zusammen mit der Genehmigung, die Ressource
zu modifizieren, zu dem Anforderer gesandt. Die so gesandte Genehmigung
schließt
keine Genehmigung ein, die Ressource auf Platte zu schreiben.
-
Wenn
Datenbankserver A die M-Sperre zu dem Anforderer weiterreicht, setzt
Datenbankserver A seine M-Sperre zu einer „Halte"-Sperre (und „H-Sperre") herab. Die H-Sperre zeigt an, dass
der Datenbankserver A eine festgehaltene PI-Kopie hält. Besitz
einer H-Sperre verpflichtet den Besitzer die PI-Kopie in seinem
Puffer-Zwischenspeicher zu halten, aber gibt dem Datenbankserver
keinerlei Rechte die PI-Kopie auf Platte zu schreiben. Es kann mehrere
gleichzeitige H-Halter für
die gleiche Ressource geben, aber zu einer Zeit kann nicht mehr
als ein Datenbankserver die Ressource schreiben, daher kann nur
ein Datenbankserver eine W-Sperre an der Ressource halten.
-
Bevor
die Ressource versendet wird, stellt der Datenbankserver A sicher,
dass die Sperre durchgesetzt ist (d.h. dass das Wiederherstellungsprotokoll,
welches für
die Änderungen
der Ressource erzeugt wurde, welche mittels des Datenbankservers A
gemacht wurden, dauerhaft gespeichert wird). Mittels Weiterreichens
der Modifikations-Genehmigung, verliert Datenbankserver A sein eigenes
Recht die Ressource zu modifizieren. Die Kopie der Ressource (wie
sie gerade zum Zeitpunkt des Versendens war) wird immer noch im
verschickenden Datenbankserver A gehalten. Nach dem Verschicken
der Ressource ist die Kopie der Ressource, welche im Datenbankserver
A gehalten wird, eine PI-Ressource.
-
Gefälligkeits-Schreiben
-
Nachdem
ein Datenbankserver eine unreine Ressource direkt zu einem anderen
Datenbankserver geschickt hat, wird die zurückgehaltene Kopie der Ressource
eine festgehaltene Ressource, deren Puffer, bis sie freigegeben
wird, nicht für
eine andere Ressource genutzt werden kann. Die Puffer, welche PI-Ressourcen
enthalten werden hierin als PI Puffer bezeichnet. Diese Puffer belegen
wertvollen Platz in den Zwischenspeichern der Datenbankserver und müssen letztlich
für andere
Daten wieder verwendet werden.
-
Um
PI-Puffer im Puffer-Zwischenspeicher (welcher als veraltet gekennzeichnet
oder zu überprüfen ist)
zu ersetzen, wird ein neues Platten-Schreib-Protokoll angewendet,
welches hierin als „Gefälligkeits-Schreiben" bezeichnet wird.
Gemäß dem Gefälligkeits-Schreib-Protokoll
sendet der Datenbankserver, wenn ein Datenbankserver eine Ressource
auf Platte schreiben muss, eine Anforderung an den DLM. Der DLM
wählt eine
Version der Ressource aus, welche auf Platte geschrieben werden soll,
findet den Datenbankserver, welcher die ausgewählte Version hat und veranlasst
im Interesse des Datenbankservers, welcher die Schreibanforderung initiiert
hat, diesen Datenbankserver, die Ressource auf Platte zu schreiben.
Der Datenbankserver, welcher die Ressource wirklich auf Platte schreibt,
kann, abhängig
von der letzten Trajektorie der Ressource, der Datenbankserver,
welcher das Schreiben angefordert hat, oder irgendein anderer Datenbankserver sein.
-
Schreiben
der ausgewählten
Version einer Ressource auf Platte, gibt alle PI-Versionen, welche gleich
alt oder älter
als die ausgewählte
Version sind, der Ressource, welche auf Platte geschrieben wurde,
in allen Puffer-Zwischenspeichern eines Clusters frei. Die Kriterien,
welche verwendet werden, um die Version zu wählen, welche auf Platte geschrieben wird,
sollen nachfolgend in größerem Detail
beschrieben werden. Jedoch kann die ausgewählte Version entweder die neueste
PI-Version, welche
dem Hauptserver bekannt ist, oder die aktuelle Version („CURR") der Ressource sein.
Ein Vorteil des Auswählens
einer anderen Version als der aktuellen Version ist, dass die Auswahl
einer anderen Version die aktuelle Kopie ununterbrochen für Modifikationen verfügbar lässt.
-
Ein
Datenbankserver, welcher eine PI-Ressource hält, kann, vorausgesetzt, dass
er eine W-Sperre auf die Ressource erlangt hat, seine PI-Kopie herausschreiben.
Die Schreibvorgänge
der Ressource sind von der Migration des CURR-Ressourcen-Abbildes
zwischen den verschiedenen Datenbankservern entkoppelt.
-
Effektivitätsfaktoren
-
Es
besteht keine Notwendigkeit, jedes mal, wenn eine Ressource zu einem
anderen Datenbankserver verschickt wird, eine PI-Kopie zu schreiben. Folglich
ist das Ziel vom dauerhaften Speichern von Ressourcen, die Plattenkopien
aktuell genug zu halten und die Anzahl von nicht-überschreibbaren
Ressourcen in den Puffer-Zwischenspeichern vernünftig zu halten. Verschiedene
Faktoren bestimmen die Effizienz eines Systems, welches das oben
beschriebene Gefälligkeits-Schreib-Protokoll
anwendet. Insbesondere ist es wünschenswert:
- (1) E/A Aktivität, welche durch das Schreiben
von unreinen Ressourcen auf Platte verursacht wird, zu minimieren;
- (2) die Plattenversionen der Ressourcen ausreichend aktuell
halten, um die Wiederherstellungs-Operationen nach einem Absturz
zu beschleunigen; und
- (3) Überlauf
des Puffer-Zwischenspeichers mit festgehaltenen PI-Ressourcen zu
verhindern.
-
Maximieren
des ersten Kriteriums hat einen negativen Einfluss auf das zweite
und dritte Kriterium und umgekehrt. Dadurch ist ein Kompromiss notwendig.
Gemäß einem
Ausführungsbeispiel
der Erfindung kann, gekoppelt mit einer Kontrolle über den gesamten
E/A-Haushalt, ein selbst-abgestimmter Algorithmus, welcher verschiedene
Techniken von mit Prüfpunkten
versehen kombiniert (LRU gemischt mit zufälligen kontinuierlichen mit
Prüfpunkten
versehen), verwendet werden.
-
Der Aktuell-Schreiben-Ansatz
-
Eine
Alternative zu dem oben beschriebenen Gefälligkeits-Schreib-Protokoll wird hierin als der
Aktuell-Schreiben- Ansatz
bezeichnet. Gemäß dem Aktuell-Schreiben-Ansatz
haben alle Datenbankserver die Genehmigung ihre PI-Ressourcen auf
Platte zu schreiben. Bevor sie dies jedoch machen, erlangt ein Datenbankserver
eine Sperre auf die plattenresidente Kopie der Ressource. Nach Erlangen
der Sperre vergleicht der Datenbankserver die Plattenversion mit
der PI-Version, welche er zu schreiben wünscht. Wenn die Plattenversion älter ist,
dann wird die PI-Version auf Platte geschrieben. Wenn die Plattenversion
neuer ist, dann kann die PI-Version abgelegt werden und der Puffer,
welcher belegt ist, kann wieder verwendet werden.
-
Im
Gegensatz zu dem Gefälligkeits-Schrei-Protokoll
erlaubt der Aktuell-Schreiben-Ansatz einem Datenbankserver seine
eigene PI-Version freizugeben, entweder indem er sie auf Platte
schreibt oder indem er feststellt, dass die Plattenversion neuer
ist. Jedoch erhöht
der Aktuell-Schreiben-Ansatz
den Wettstreit um die Sperre der plattenresidenten Kopie und kann
ein Platten-E/A nach sich ziehen, welcher mit dem Gefälligkeits-Schreib-Ansatz
nicht aufgetreten wäre.
-
Genehmigungsketten
-
Typische
DLMs verwalten den Zugang zu Ressourcen mittels des Verwendens einer
begrenzten Anzahl von Sperrmodi, wobei die Modi entweder kompatibel
sind oder im Konflikt stehen. Gemäß einem Ausführungsbeispiel
ist, um Sperr-Modi mittels einer Ansammlung von verschiedenen Arten
von Genehmigungen und Verpflichtungen zu ersetzen, der Mechanismus
zum Verwalten des Zugangs zu Ressourcen erweitert. Die Genehmigungen
und Verpflichtungen können
zum Beispiel die Genehmigung zum Schreiben einer Ressource, zum
Modifizieren einer Ressource, zum Halten einer Ressource im Zwischenspeicher,
usw. sein.
-
Spezifische
Genehmigungen und Verpflichtungen werden im Folgenden in größerem Detail
beschrieben.
-
Gemäß einem
Ausführungsbeispiel
sind Genehmigungen und Verpflichtungen in Genehmigungsketten kodiert.
Eine Genehmigungskette kann, weil viele Genehmigungen sich eher
auf eine Version einer Ressource als auf die Ressource selbst beziehen,
mittels einer Ressourcen-Versions-Nummer verlängert werden. Zwei verschiedene
Genehmigungsketten stehen in Widerstreit, wenn sie die gleiche exklusive
Genehmigung für
die gleiche Version der Ressource verlangen (z.B. aktuelle Version
zur Modifikation oder ein Plattenzugriff zum Schreiben). Anderenfalls
sind sie kompatibel.
-
Gemeinschaftliches Verwenden
von Genehmigungs-Transfers
-
Wie
oben beschrieben, instruiert der Hauptserver, wenn eine Ressource
an einem Datenbankserver modifiziert wird und sie für weitere
Modifikationen von einem anderen Datenbankserver angefordert wird,
den Datenbankserver, welcher die aktuelle Kopie (CURR-Kopie) der
Ressource hält,
seine M-Sperre (das Recht zu modifizieren) zusammen mit der CURR-Kopie
der Ressource zu dem anderen Datenbankserver weiterzugeben. Signifikanterweise wird,
obgleich die Anforderung für
die M-Sperre an den
Hauptserver gesendet wird, das Erteilen mittels irgendeines anderen
Datenbankservers (den vorherigen M-Sperren Halter) getan. Dieses Dreiecks-Benachrichtigungssystem
weicht signifikant von der herkömmlichen
Zweiweg-Kommunikation ab, bei welcher die Antwort auf eine Sperren-Anforderung von
dem Datenbankserver erwartet wird, welche den Sperrmanager enthält, zu welchen
die Sperren-Anforderung anfänglich
gesendet wurde.
-
Gemäß einem
Ausführungsbeispiel
der Erfindung benachrichtigt Datenbankserver A den Hauptserver,
dass die M-Sperre transferiert wurde, wenn der Halter der CURR Kopie
der Ressource (z.B. Datenbankserver A) die M-Sperre an einen anderen
Datenbankserver weiterreicht. Jedoch wartet der Datenbankserver
A nicht auf Bestätigung,
dass der Hauptserver die Benachrichtigung erhalten hat, sondern
sendet die CURR-Kopie
und die M-Sperre vor Erhalt einer solchen Bestätigung. Mittels des nicht Abwartens
erlegt die Schleifenkommunikation zwischen dem Hauptserver und Datenbankserver
A der Übertragung
keine Verzögerung
auf, wodurch sich eine beträchtliche
Einsparung von Protokoll-Wartezeiten ergibt.
-
Da
Genehmigungen direkt vom aktuellen Halter der Genehmigung zu dem
Anforderer der Genehmigung übertragen
werden, weiß der
Hauptserver nicht immer das exakte globale Bild der Sperren Erteilungen.
Vielmehr weiß der
Hauptserver nur von der Trajektorie der M-Sperre, von den Datenbankservern,
welche „sie
gerade vor Kurzem hielten",
aber nicht von dem exakten Standort der Sperre zu jeder gegebenen
Zeit. Gemäß einem
Ausführungsbeispiel ist
dieses „träge" Benachrichtigungsschema
auf die M-Sperren anwendbar, aber nicht auf die W-, X- oder S-Sperren
(oder ihren Entsprechungen). Verschiedenartige Ausführungsbeispiele
eines Sperrenschemas sind im Folgenden in größerem Detail beschrieben.
-
Absturz-Wiederherstellung
-
Innerhalb
der Erfindung wird davon gesprochen, dass ein Datenbankserver abgestürzt ist,
wenn ein Zwischenspeicher, welcher mit dem Server assoziiert ist,
unzugänglich
wird. Datenbanksysteme, welche das direkte Zwischen-Server-Verschicken von unreinen
Ressourcen mittels Verwendens der hierin beschriebenen Techniken
anwenden, vermeiden die Notwendigkeit des Zusammenfügens von
Wiederherstellungsprotokollen in Antwort auf einen Einzel-Server-Absturz. Gemäß einem
Ausführungsbeispiel
werden Einzel-Server-Abstürze
wie in 4 erläutert
gehandhabt. Bezugnehmend auf 4 führt das
Wiederherstellungsverfahren, nach einem Einzel-Datenbankserver Absturz, für jede Ressource, welche
in dem Zwischenspeicher des abgestürzten Datenbankservers gehalten
wurde, das Folgende aus:
(Schritt 400) Bestimmen des
Datenbankservers, welcher die aktuellste Version der Ressource hält;
(Schritt 402)
wenn der Datenbankserver, welcher in Schritt 400 bestimmt
wurde, nicht der abgestürzte Datenbankserver
ist, dann (Schritt 404) schreibt der bestimmte Datenbankserver
seine zwischengespeicherte Version der Ressource auf Platte und
(Schritt 406) alle PI-Versionen der Ressource werden freigegeben.
Diese Version wird alle an der Ressource durchgeführten Änderungen
haben (inklusive derer, welche mittels des abgestürzten Datenbankservers gemacht
wurden) und daher braucht kein Wiederherstellungsprotokoll irgendeines
Datenbankservers angewandt werden.
-
Wenn
der Datenbankserver, welcher in Schritt 402 bestimmt wurde,
der abgestürzte
Datenbankserver ist, dann (Schritt 408) schreibt der Datenbankserver,
welcher die letzte PI-Version
der Ressource hält,
seine zwischengespeicherte Version der Ressource auf Platte heraus
und (Schritt 410) alle früheren PI-Versionen werden freigegeben.
Die Version, welche auf Platte herausgeschrieben wurde, wird die
begangenen Änderungen
haben, welche von allen Datenbankservern außer dem abgestürzten Datenbankserver
an der Ressource durchgeführt wurden.
Das Wiederherstellungsprotokoll des abgestürzten Datenbankservers wird
angewandt (Schritt 412), um die begangenen Änderungen,
welche mittels des abgestürzten
Datenbankservers durchgeführt
wurden, wiederherzustellen.
-
Alternativ
kann die letzte PI-Version der Ressource als Startpunkt zur Wiederherstellung
der aktuellen Version eher im Zwischenspeicher als auf Platte verwendet
werden. Insbesondere können
die entsprechenden Aufzeichnungen des Wiederherstellungsprotokolls
des abgestürzten
Datenbankservers direkt auf die letzte PI-Version, welche im Zwischenspeicher
liegt, angewandt werden, wodurch die aktuelle Version im Zwischenspeicher
des Datenbankservers, welcher die letzte PI-Version hält, rekonstruiert wird.
-
Mehrere-Datenbankserver-Absturz
-
Im
Falle eines Mehrere-Server-Absturzes, wenn weder die letzte PI-Kopie
noch irgendeine CURR Kopie überlebt
hat, kann es passieren, dass die Änderungen, welche an der Ressourcen
gemacht wurden, über
viele Protokolle der abgestürzten
Datenbankserver verstreut sind. Unter diesen Umständen müssen die
Protokolle der abgestürzten
Datenbankserver zusammengefügt
werden. Jedoch müssen
nur die Protokolle der abgestürzten
Datenbankserver zusammengefügt
werden und nicht Protokolle von allen Datenbankservern. Dadurch
ist der Umfang der Arbeit, welche für das Wiederherstellen benötigt wird,
proportional zu dem Ausmaß des
Absturzes und nicht zu der Größe der gesamten
Konfiguration.
-
In
Systemen, in denen es möglich
ist, zu bestimmen, welche abgestürzten
Datenbankserver die Ressource aktualisiert haben, müssen nur
die Protokolle der abgestürzten Datenbankserver,
welche die Ressource aktualisiert haben, zusammengefügt und angewandt
werden. Gleichermaßen
brauchen in Systemen, in denen es möglich ist, zu bestimmen, welche
der abgestürzten
Datenbankservern die Ressource nach der dauerhaft gespeicherten
Version der Ressource aktualisiert haben, nur die Protokolle der abgestürzten Datenbankserver,
welche die Ressource nach der dauerhaft gespeicherten Version der Ressource
aktualisiert haben, zusammengefügt
und angewandt werden.
-
Beispielhafter Betrieb
-
Zum
Zwecke der Erläuterung
soll im Bezug auf 1 eine exemplarische Serie von
Ressourcen Übertragungen
beschrieben werden. Während
der Serie von Übertragungen
wird an vielen Datenbankservern auf eine Ressource zugegriffen.
Insbesondere wird die Ressource zum Modifizieren entlang eines Clusterknotens
verschickt und dann verursacht ein Prüfpunkt an einem der Datenbankserver
einen physischen E/A dieser Ressource.
-
Wieder
auf die 1 Bezug nehmend gibt es vier
Datenbankserver: A, B, C und D. Datenbankserver D ist der Hauptserver
der Ressource. Datenbankserver C modifiziert die Ressource zuerst.
Datenbankserver C hat die Ressourcen Version 8. An diesem Punkt,
hat Datenbankserver C auch eine M-Sperre (ein exklusives Modifikationsrecht)
an dieser Ressource.
-
Angenommen,
dass zu diesem Punkt Datenbankserver B die Ressource, welche derzeit
Datenbankserver C hält,
modifizieren möchte.
Datenbankserver B sendet eine Anforderung (1) für eine M-Sperre an der Ressource.
Datenbankserver D reiht die Anforderung in eine Modifizierer- Warteschlange ein,
welche mit der Ressource assoziiert ist, und instruiert (Nachricht
2: BAST) Datenbankserver C zum:
- (a) Weiterreichen
der Modifikations-Genehmigung (M-Sperre)
an Datenbankserver B,
- (b) Senden des aktuellen Abbildes der Ressource an Datenbankserver
B, und
- (c) Herabsetzen der M-Sperre des Datenbankservers C auf eine
H-Sperre.
-
Nach
dieser Herabsetzungs-Operation ist C verpflichtet, seine Version
der Ressource (die PI-Kopie) in seinem Puffer-Zwischenspeicher zu halten.
-
Datenbankserver
C führt
die angeforderten Operationen durch und kann zusätzlich das Protokollieren der
neuen Änderungen
erzwingen. Zusätzlich benachrichtigt
Datenbankserver C „träge" (3 AckM) den Hauptserver,
dass er die Operationen (AST) durchgeführt hat. Die Benachrichtigung
informiert den Hauptserver auch, dass Datenbankserver C die Version
8 hält.
Datenbankserver C wartet nicht auf irgendeine Bestätigung vom
Hauptserver. Als Konsequenz daraus ist es möglich, dass Datenbankserver B
eine M-Sperre erhält,
bevor der Hauptserver davon weiß.
-
Indessen
wird angenommen, dass Datenbankserver A auch entscheidet, die Ressource
zu modifizieren. Datenbankserver A sendet eine Nachricht (4) zu
Datenbankserver D. Diese Nachricht kann vor der asynchronen Benachrichtigung
vom Datenbankserver C bei Datenbankserver D ankommen.
-
Datenbankserver
D (der Hauptserver) sendet eine Nachricht (5) zu Datenbankserver
B den letzten bekannten Modifizierer dieser Ressource, die Ressource
(nachdem B sie bekommen und modifiziert hat) an Datenbankserver
A weiterzureichen. Zu beachten ist, dass Datenbankserver D nicht
weiß,
ob die Ressource dort ist oder noch nicht. Aber Datenbankserver
D weiß,
dass die Ressource schließlich bei
B ankommen wird.
-
Nachdem
Datenbankserver B die Ressource bekommen hat und die beabsichtigten Änderungen gemacht
hat (jetzt hat B die Version 9 der Ressource), setzt er seine eigene
Sperre auf H herab, sendet (6) gemeinsam mit der M-Sperre die aktuelle
Version der Ressource („CURR-Ressource") zu Datenbankserver
A. Datenbankserver B sendet auch eine „träge" Benachrichtigung (6 AckM) an den Hauptserver.
-
Während die
Ressource im Datenbankserver A modifiziert wird, wird angenommen,
dass ein Prüfpunktmechanismus
an Datenbankserver C entscheidet, die Ressource auf Platte zu schreiben.
Hinsichtlich der oben beschriebenen asynchronen Ereignisse, wird
angenommen, dass 3AckM und 6AckM schon beim Hauptserver angekommen
sind. Die Operationen, welche in Antwort auf die mit Prüfpunkt versehende
Operation ausgeführt
werden, werden unter Bezug auf 5 erläutert.
-
Bezugnehmend
auf 5 sendet, weil der Datenbankserver C eine H-Sperre,
welche kein Schreibprivileg beinhaltet, auf Version 8 hält, Datenbankserver
C Nachricht 1 an den Hauptserver (D), womit er die W- (Schreib-)
Sperre für
seine Version anfordert. Zu diesen Zeitpunkt weiß der Hauptserver, dass die
Ressource zu Datenbankserver A geschickt wurde (angenommen, dass
die Benachrichtigung angekommen ist). Datenbankserver D sendet eine
(unaufgeforderte) W-Sperre an Datenbankserver A (2 BastW) mit der
Instruktion die Ressource zu schreiben.
-
Im
allgemeinen Fall wird diese Instruktion zu dem letzten Datenbankserver
gesendet, dessen gesendete Benachrichtigung angekommen ist (oder
zu dem Datenbankserver, welcher die Ressource vom letzten bekannten
Sender erhalten soll). Datenbankserver A schreibt (3) seine Version
der Ressource. Die Ressource, welche vom Datenbankserver A geschrieben
wird, ist Version 10 der Ressource. Zu dieser Zeit kann, wenn zusätzliche
Anforderer die Ressource verlangt haben, die aktuelle Kopie der
Ressource irgendwo anders sein. Die Platte bestätigt, wenn das Schreiben komplettiert
ist (4Ack).
-
Wenn
das Schreiben komplettiert ist, versorgt Datenbankserver A Datenbankserver
D mit der Information, dass Version 10 jetzt auf Platte ist (5 AckW).
Datenbankserver A setzt freiwillig seine W-Sperre herab (wofür er nicht
zuerst um Erlaubnis fragt).
-
Der
Hauptserver (D) richtet sich an den Datenbankserver C und, anstelle
des Erteilens der angeforderten W-Sperre, benachrichtigt C, dass
das Schreiben komplettiert ist (6). Der Hauptserver teilt die aktuelle
Versions-Nummer auf der Platte an die Halter aller PI-Kopien mit,
so dass alle früheren PI-Kopien
auf C freigegeben werden können.
In diesem Szenario setzt es, da Datenbankserver C keine PI-Kopien älter als
10 hat, die Sperre des Datenbankservers C auf NULL.
-
Der
Hauptserver sendet auch eine Bestätigungsnachricht zu Datenbankserver
B, wobei er Datenbankserver B instruiert seine PI-Versionen, welche
früher
als 10 sind, freizugeben (7AckW(10)).
-
Der Verteilte-Sperrmanager
-
Im
Gegensatz zur konventioneller DLM Logik, kann der Hauptserver in
einem System, welches die Direkt-Verschickungstechniken,
welche hierin beschrieben sind, realisiert, unvollständige Informationen über die
Zustände
der Sperren an den Datenbankservern haben. Gemäß einem Ausführungsbeispiel
unterhält
der Hauptserver einer Ressource die folgenden Informationen und
Datenstrukturen:
- (1) eine Warteschlange von
CURR-Kopie-Anforderern (entweder für Modifikationen oder für gemeinsamen
Zugriff) (die obere Grenze der Warteschlangenlänge ist die Anzahl der Datenbankserver
im Cluster). Diese Warteschlange wird hierin als Aktuelle-Anforderungs-Warteschlange
(CQ) bezeichnet.
- (2) wenn eine Ressource an einen anderen CURR Anforderer gesendet
wird, benachrichtigen die Sender träge (asynchron im Sinne, dass
diese nicht auf eine Bestätigung
warten) den Hauptserver über
das Ereignis. Der Hauptserver führt
Buch über
die letzten paar Sender. Dies ist ein Pointer auf die CQ.
- (3) Die Versionsnummer der letzten Ressourcenversion auf Platte.
- (4) W-Sperren Erteilungen und eine W-Anforderungs-Warteschlange. Gemäß einem
Ausführungsbeispiel
ist W-Genehmigung
synchron: sie wird nur vom Hauptserver erteilt und der Hauptserver
stellt sicher, dass es für
diese Ressource nicht mehr als einen Schreiber in dem Cluster gibt.
Der Hauptserver kann die nächste
Erteilung nur machen, nachdem er benachrichtigt wurde, dass das
vorherige Schreiben komplettiert und die W-Sperre freigegeben wurde.
Wenn es mehr als einen Modifizierer gibt, wird eine W-Sperre für die Zeitdauer
des Schreibens gegeben und freiwillig nach dem Schreiben freigegeben.
Wenn da nur ein Modifizierer ist, kann der Modifizierer die W-Genehmigung
behalten.
- (5) eine Liste von H-Sperren Haltern mit deren entsprechenden
Ressourcen Versions-Nummern. Dies stellt Informationen (obgleich
Möglicherweise
unvollständig) über die
PI-Kopien in Puffer-Zwischenspeichern bereit.
-
Plattenerneuern
-
Da
die direkten Verschickungstechniken, welche hierin beschrieben sind,
signifikant die Lebensdauern der Puffer-Zwischenspeicher-Abbilder der Ressourcen
und der Platten-Abbilder
trennt, gibt es eine Notwendigkeit, diese Wiederherstellungslücke zu überbrücken. Gemäß einem
Ausführungsbeispiel
wird ein neuer Schritt von Wiederherstellung zwischen DLM-Wiederherstellung
und Puffer-Zwischenspeicher-Wiederherstellung
hinzugefügt.
Dieser neue Wiederherstellungsschritt wird hierein als „Plattenerneuern" bezeichnet.
-
Obwohl
während
normaler Zwischenspeicher-Operationen ein Hauptserver einer Ressource nur
ungefähres
Wissen über
den Ort der Ressource und über
die Verfügbarkeit
von PI- und CURR-Kopien hat, sammelt bei DLM-Wiederherstellung (welche Zwischenspeicher-Wiederherstellung
vorangeht) der Hauptserver einer Ressource komplette Informationen über die
Verfügbarkeit
der letzten PI- und CURR-Kopien in den Puffer-Zwischenspeichern überlebender Datenbankserver.
Dies gilt egal, ob der Hauptserver der Ressource ein neuer Hauptserver (wenn
vor dem Absturz die Ressource von einem abgestürzten Datenbankserver gehandhabt
wurde) oder ein überlebender
Hauptserver ist.
-
Nach
Sammeln dieser Informationen weiß der Hauptserver, welcher
Datenbankserver die letzte Kopie der Ressource besitzt. In dem Zustand
des „Plattenerneuerns", gibt der Hauptserver
eine W-Sperre an den Besitzer dieser letzten Kopie der Ressource
heraus (CURR wenn sie verfügbar
ist und letzte PI-Kopie wenn die CURR-Kopie zusammen mit dem abgestürzten Datenbankserver
verschwunden ist). Der Hauptserver instruiert dann diesen Datenbankserver,
die Ressource auf Platte zu schreiben. Wenn das Schreiben komplettiert
ist, wandeln alle anderen Datenbankserver ihre H-Sperren in NULL-Sperren
um (weil die geschriebene Kopie die neueste Verfügbare ist). Nachdem diese Sperren umgewandelt
wurden, kann Zwischenspeicher-Wiederherstellung wie normal weitergehen.
-
Einige
Optimierungen sind während
des Zustands des Plattenerneuerns möglich. Zum Beispiel muss die
Ressource nicht notwendigerweise auf Platte geschrieben werden,
wenn das letzte Abbild in dem Puffer-Zwischenspeicher des Datenbankservers
ist, welcher das Wiederherstellen durchführt.
-
Alternativen zum Sperren-basierten
Schema
-
Verschiedenartige
Techniken für
direktes Verschicken unreiner Kopien von Ressourcen zwischen Datenbankservern
wurden im Zusammenhang mit einem Sperren-Schema beschrieben, welches spezielle
Typen von Sperren (M-, W-, und H-Sperren) verwendet. Insbesondere
werden diese Spezialsperren verwendet, um sicherzustellen, dass
(1) nur der Server mit der aktuellen Version der Ressource die Ressource
modifiziert, (2) alle Server ihre PI-Versionen der Ressource halten,
bis dieselbe Version oder eine neuere Version der Ressource auf
Platte geschrieben ist und (3) die plattenresidente Version der Ressource
nicht von einer älteren
Version der Ressource überschrieben
wird.
-
Jedoch
ist das Sperren-basierte Zugriffs-Steuerschema bloß ein Kontext,
in welchem die Erfindung realisiert werden kann. Zum Beispiel können dieselben
drei Regeln mittels irgendeiner Variation von Zugriffs-Steuerungsschemen
durchgesetzt werden. Daher ist die Erfindung nicht auf irgendein besonderes
Zugriffs-Steuerungsschema beschränkt.
-
Zum
Beispiel kann Zugriff, eher als durch ein auf Sperren basierenden
Verwalten des Zugriffes auf eine Ressource, mittels Markern verwaltet
werden, wobei jeder Marker einen besonderen Typ von Genehmigung
repräsentiert.
Der Marker für
eine bestimmte Ressource kann zwischen den Parallel-Servern in einer
Weise übertragen
werden, welche sicherstellt, dass die drei oben gegebenen Regeln durchgesetzt
werden.
-
Gleichermaßen können die
Regeln mittels Verwendens eines Zustands-basierten Schemas durchgesetzt
werden. In einem Zustands-basierten Schema ändert eine Version einer Ressource
den Zustand als Antwort auf Ereignisse, wobei der Zustand einer
Version den Typ von Aktionen diktiert, welche an dieser Version
durchgeführt
werden können.
Zum Beispiel empfängt
ein Datenbankserver die aktuelle Version einer Ressource in ihrem „aktuellen" Zustand. Der aktuelle
Zustand erlaubt Modifikation der Ressource und Auf-Platte-Schreiben
der Ressource. Wenn ein Datenbankserver die aktuelle Version der
Ressource zu einem anderen Knoten überträgt, ändert sich die gehaltene Version
in einen „PI schreibbaren" Zustand. In dem
PI schreibbaren Zustand kann die Version (1) nicht modifiziert werden, (2)
kann nicht überschrieben
werden aber (3) kann auf Platte geschrieben werden. Wenn irgendeine Version
der Ressource auf Platte geschrieben wird, werden alle Versionen,
welche in einem PI-schreibbaren-Zustand sind, welche gleich oder älter als
die Version ist, welche auf Platte geschrieben wurde, in einem „PI-freigegebenen"-Zustand gesetzt.
In dem PI-freigegebenen-Zustand können Versionen überschrieben
werden, aber können
nicht modifiziert oder auf Platte geschrieben werden.
-
Hardwareübersicht
-
6 ist
ein Blockdiagramm, welches ein Computersystem 600 erläutert, in
welchem ein Ausführungsbeispiel
der Erfindung realisiert werden kann. Das Computersystem 600 enthält einen
Bus 602 oder einen anderen Kommunikationsmechanismus zum
Kommunizieren von Information und einen Prozessor 604,
welcher zum Prozessieren von Informationen mit dem Bus 602 gekoppelt
ist. Das Computersystem 600 weist auch einen Hauptspeicher 606,
wie zum Beispiel einen Direktzugriffspeicher (RAM) oder eine andere
mit dem Bus 602 gekoppelte dynamische Speichervorrichtung
auf, zum Speichern von Informationen und Instruktionen, welche mittels des
Prozessors 604 ausgeführt
werden müssen.
Der Hauptspeicher 606 kann auch zum zeitweiligen Speichern
von Variablen oder anderen Zwischeninformationen während des
Ausführens
von Instruktionen verwendet werden, welche mittels des Prozessors 604 ausgeführt werden
müssen.
Das Computersystem 600 enthält ferner einen Festwertspeicher (ROM) 608 oder
eine andere mit Bus 602 gekoppelte statische Speichervorrichtung
zum Speichern statischer Informationen und Instruktionen für den Prozessor 604.
Eine Speichervorrichtung 610, wie zum Beispiel eine Magnetplatte
oder optische Platte ist bereitgestellt und mit dem Bus 602 gekoppelt,
zum Speichern von Informationen und Instruktionen.
-
Das
Computersystem 600 kann zum Anzeigen von Informationen
für einen
Benutzer mittels des Bus 602 mit einer Anzeige 612,
wie zum Beispiel einer Kathodenstrahlröhre (CRT), gekoppelt werden. Eine
Eingabevorrichtung 614, welche alphanumerische und andere
Tasten aufweist, ist zum Kommunizieren von Informationen und Befehlsauswahlen
an den Prozessor 604, an den Bus 602 gekoppelt.
Eine andere Art von Benutzer-Eingabevorrichtung,
zum Kommunizieren von Richtungsinformationen und Befehlsauswahlen
an den Prozessor 604 und zum Steuern von der Kursorbewegung
auf einem Display 612, ist eine Kursorsteuerung 616 wie
zum Beispiel eine Maus, ein Trackball oder Kursor-Richtungs-Tasten. Diese
Eingabevorrichtung hat typischerweise zwei Freiheitsgrade entlang
zweier Achsen, einer ersten Achse (z.B. X) und einer zweiten Achse
(z.B. Y), welches der Vorrichtung erlaubt, Positionen in einer Ebene
zu spezifizieren.
-
Die
Erfindung betrifft das Benutzen eines Computersystems 600 zum
Reduzieren des Overheads, welcher mit einem Ping assoziiert ist.
Gemäß einem
Ausführungsbeispiel
der Erfindung wird der mit einem Ping assoziierte Overhead, mittels
des Computersystems 600 in Antwort auf das Ausführen einer
oder mehrerer Sequenzen einer oder mehrerer Instruktionen, welche
im Hauptspeicher 606 enthalten sind, des Prozessor 604,
reduziert. Solche Instruktionen können von einem anderen computerlesbaren
Medium, wie zum Beispiel einer Speichervorrichtung 610,
in den Hauptspeicher 606 eingelesen werden. Ausführen der
Sequenzen von Instruktionen, welche im Hauptspeicher 606 enthalten
sind, veranlassen den Prozessor 604, die Prozessschritte, welche
hierin beschrieben sind, auszuführen.
In alternativen Ausführungsbeispielen
können
hart-verdrahtete Schaltkreise anstelle von oder in Kombination mit
Softwareinstruktionen verwendet werden, um die Erfindung zu realisieren.
Daher sind die Ausführungsbeispiele
der Erfindung nicht auf irgendeine spezifische Kombination von Hardware-Schaltkreisen
und Software begrenzt.
-
Der
Ausdruck „Computer-lesbares
Medium" wie er hierin
verwendet wird, bezieht sich auf jedes Medium, welches am Bereitstellen
von Instruktionen zum Ausführen
an den Prozessor 604 teilnimmt. Solch ein Medium kann viele
Formen haben, welche einschließen
aber nicht begrenzt sind auf, nichtflüchtige Medien, flüchtige Medien
und Übertragungsmedien.
Nichtflüchtige
Medien schließen
zum Beispiel optische oder magnetische Platten wie z.B. die Speichervorrichtung 610 ein.
Flüchtige
Medien schließen dynamische
Speicher, wie zum Beispiel den Hauptspeicher 606 ein. Übertragungsmedien
schließen Koaxialkabel,
Kupferkabel und Lichtwellenleiter, inklusive der Kabel, welche der
Bus 602 aufweist, ein. Übertragungsmedien
können
ferner die Form von akustischen oder Lichtwellen annehmen, wie zum Beispiel
solche, welche während
Radiowellen- und Infrarot-Datenkommunikationen
erzeugt werden.
-
Übliche Formen
von Computer-lesbaren Medien schließen zum Beispiel eine Floppy-Disk,
eine flexible Diskette, Festplatte, Magnetband oder jedes andere
magnetische Medium, eine CD-ROM, jedes andere optische Medium, Lochkarten,
Lochstreifen, jedes andere physische Medium mit einem Muster von
Löchern,
eine RAM, eine PROM und EPROM, eine FLASH-EPROM, jeden anderen Speicherchip oder
Speicherkassette, eine Trägerwelle
wie nachfolgend hierin beschrieben oder jedes andere Medium, von
welchem ein Computer lesen kann, ein.
-
Verschiedenartige
Formen von Computer-lesbaren Medien können in das Tragen einer oder mehrerer
Sequenzen von einer oder mehrerer Instruktionen zum Prozessor 604 zum
Ausführen einbezogen
sein. Zum Beispiel können
die Instruktionen anfänglich
auf einer Magnetplatte eines entfernten Computers gespeichert sein.
Der entfernte Computer kann die Instruktionen in seinen dynamischen
Speicher laden und die Instruktionen mittels Verwendens eines Modems über eine
Telefonleitung versenden. Ein Modem am Ort des Computersystems 600 kann die
Daten über
die Telefonleitung empfangen und einen Infrarot-Transmitter verwenden,
um die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor kann
die Daten, welche in dem Infrarotsignal enthalten sind, empfangen
und ein passender Schaltkreis kann die Daten auf den Bus 602 führt. Bus 602 trägt die Daten
zum Hauptspeicher 606, von welchem Prozessor 604 die
Instruktionen empfängt
und ausführt. Die
mittels des Hauptspeichers 606 empfangenen Instruktionen
können,
entweder vor oder nach dem Ausführen
mittels des Prozessors 604 optional in einer Speichervorrichtung 610,
gespeichert werden.
-
Das
Computersystem 600 gehört
zu einem Gemeinschafts-Plattensystem,
in welchem Daten eines oder mehrerer Speichervorrichtungen (z.B.
Plattenlaufwerken 655) für beide, Computersystem 600 und
für eine
oder mehrere CPUs (z.B. CPU 651), zugreifbar sind. In dem
erläuterten
System wird Gemeinschaftszugriff zu den Plattenlaufwerken 655 mittels
eines Systemnetz-Bereiches 653 bereitgestellt. Jedoch können verschiedenartige
Mechanismen alternativ genutzt werden, um Gemeinschaftszugriff bereitzustellen.
-
Das
Computersystem 600 weist auch eine an den Bus 602 gekoppelte
Kommunikations-Schnittstelle 618 auf. Die Kommunikations-Schnittstelle 618 stellt
eine bidirektionale Daten-Kommunikationsverbindung zu einer Netzwerk-Verbindung 620 bereit, welche
mit einem lokalen Netzwerk 622 gekoppelt ist. Zum Beispiel
kann Kommunikations-Schnittstelle 618 eine Dienste-integrierendes-digitales-Nachrichtennetz-(ISDN)
harte oder ein Modem sein, um eine Datenkommunikationsverbindung
zu einer entsprechenden Art von Telephonleitung bereitzustellen.
Als ein anderes Beispiel kann die Kommunikations-Schnittstelle 618 eine
Lokales-Datennetz-
(LAN) Karte sein, um eine Datenkommunikationsverbindung zu einem
kompatiblen LAN bereitzustellen. Ferner können drahtlose Verbindungen
realisiert werden. In einer solchen Realisierung, sendet und empfängt Kommunikations-Schnittstelle 618 elektrische, elektromagnetische
oder optische Signale, welche digitale Datenströme tragen, welche verschiedenartige
Typen von Informationen repräsentieren.
-
Die
Netzwerk-Verbindung 620 stellt typischerweise mittels eines
oder mehrerer Netzwerke Datenkommunikation zu anderen Datenvorrichtungen
bereit. Zum Beispiel kann die Netzwerk-Verbindung 620 mittels des
lokalen Netzwerks 622 eine Verbindung zu einem Zentralrechner 624 oder
zu Datenvorrichtungen, welche von einem Internet-Service-Provider (ISP) 626 betrieben
werden, bereitstellen. Im Gegenzug stellt ISP 626 Datenkommunikationsservices
mittels des Weltweiten-Datenpaket-Kommunikations-Netzwerkes, jetzt
gemeinhin als „Internet" 628 bezeichnet,
bereit. Das Lokale Netzwerk 622 und Internet 628 nutzen
beide elektrische, elektromagnetische oder optische Signale, welche digitale
Datenströme
tragen. Die Signale durch die verschiedenartigen Netzwerke und die
Signale auf der Netzwerk-Verbindung 620 und durch Kommunikations-Schnittstelle 618,
welche die digitalen Daten zu und weg vom Computersystem 600 tragen,
sind exemplarisch als Trägerwellen
ausgebildet, welche die Informationen tragen.
-
Das
Computersystem 600 kann mittels des/der Netzwerk(e), Netzwerk-Verbindung 620 und Kommunikations-Schnittstelle 618 Nachrichten
senden und Daten, inklusive Programmcode, empfangen. In dem Internetbeispiel
kann ein Server 630 mittels Internet 628, ISP 626,
lokales Netzwerk 622 und Kommunikations-Schnittstelle 618 einen
angeforderten Code für
ein Anwendungsprogramm übertragen.
-
Der
empfangene Code kann mittels des Prozessors 604 so wie
er empfangen wurde, ausgeführt werden,
und/oder in der Speichervorrichtung 610 oder anderen nichtflüchtigen
Speichern zum späteren
Ausführen
gespeichert werden. Auf diese Weise kann das Computersystem 600 Anwendungscode
in Form einer Trägerwelle
erhalten.
-
Gemäß einem
anderen Aspekt der Erfindung wird ein Verfahren zum Verwalten einer
Ressource, die von einer Mehrzahl von Knoten verwendet wird, offenbart.
Das Verfahren weist die Schritte auf: Empfangen einer Anforderung
für die
Ressource von einem ersten Knoten der Mehrzahl von Knoten, wobei der
erste Knoten einen ersten Zwischenspeicher aufweist; Identifizieren
eines zweiten Knotens der Mehrzahl von Knoten, wobei der zweite
Knoten einen zweiten Zwischenspeicher aufweist, der eine erste Kopie
der Ressource aufweist; Veranlassen, dass der zweite Knoten eine
zweite Kopie der Ressource von dem zweiten Zwischenspeicher an den
ersten Zwischenspeicher überträgt, ohne
zuerst die Ressource von dem zweiten Zwischenspeicher in einem anhaltenden
Speicher dauerhaft zu speichern; und Veranlassen, dass mindestens
eine Kopie der Ressource in dem zweiten Zwischenspeicher beibehalten
wird, bis die erste Kopie der Ressource oder ein Versionsnachfolger
von ihr dauerhaft gespeichert ist.
-
Der
erste Knoten kann ein erster Datenbank-Server sein und der zweite
Knoten kann ein zweiter Datenbank-Server sein.
-
Das
Verfahren kann ferner die Schritte aufweisen: Empfangen, von einem
dritten Knoten der Mehrzahl von Knoten, einer zusätzlichen
Anforderung für
eine Erlaubnis, wobei der dritte Knoten eine dritte Kopie der Ressource
in einem dritten Zwischenspeicher aufweist und wobei die Erlaubnis
es dem dritten Knoten ermöglicht,
die Ressource auf Platte zu schreiben, aber es dem dritten Knoten
nicht ermöglicht,
die Ressource zu verändern;
Identifizieren eines vierten Knotens der Mehrzahl von Knoten, wobei
der vierte Knoten eine vierte Kopie der Ressource in einem vierten
Zwischenspeicher aufweist und wobei die vierte Kopie mindestens
so neu wie die dritte Kopie ist; und Veranlassen, dass der vierte Knoten
die vierte Kopie auf Platte schreibt.
-
Darüber hinaus
kann das Verfahren den Schritt aufweisen: Veranlassen, dass alle
Kopien der Ressource, die älter
sind als die vierte Kopie, freigegeben werden, als Reaktion darauf,
dass der vierte Knoten die vierte Kopie auf Platte schreibt.
-
Außerdem kann
der vierte Knoten der dritte Knoten sein oder kann nicht der dritte
Knoten sein.
-
Die
vierte Kopie der Ressource kann ein früheres Abbild der Ressource
sein.
-
Ferner
kann das frühere
Abbild der Ressource mindestens so neu wie jedes andere frühere Abbild
der Ressource sein, das aktuell von der Mehrzahl von Knoten beibehalten
wird.
-
Die
vierte Kopie der Ressource kann eine aktuelle Version der Ressource
sein.
-
Der
Schritt des Veranlassens, dass der vierte Knoten die vierte Kopie
auf Platte schreibt, kann den Schritt aufweisen: Bereitstellen einer
zusätzlichen
Erlaubnis für
den vierten Knoten, die es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei die zusätzliche
Erlaubnis es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu verändern.
-
Die
zusätzliche
Erlaubnis, die für
den vierten Knoten bereitgestellt wird, kann eine Schreibsperre sein,
die es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei die Schreibsperre
es dem vierten Knoten nicht ermöglicht,
die vierte Kopie zu verändern.
-
Alternativ
kann die zusätzliche
Erlaubnis, die für
den vierten Knoten bereitgestellt wird, ein Schreib-Token sein,
der es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei der Schreib-Token
es dem vierten Knoten nicht ermöglicht,
die vierte Kopie zu verändern.
-
Der
Schritt des Veranlassens, dass der vierte Knoten die vierte Kopie
auf Platte schreibt, kann den Schritt aufweisen: Zuordnen eines
Zustands zu der vierten Kopie, wobei der Zustand es dem vierten Knoten
ermöglicht,
die vierte Kopie auf Platte zu schreiben.
-
Das
Verfahren kann ferner die Schritte aufweisen: Bereitstellen, vor
dem Empfangen der Anforderung, einer ersten Erlaubnis für den zweiten
Knoten, die es diesem Knoten ermöglicht,
die erste Kopie zu verändern,
wobei die erste Erlaubnis es dem zweiten Knoten nicht ermöglicht,
die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen,
dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Bereitstellen
einer zweiten Erlaubnis für
den zweiten Knoten, die es erfordert, dass der zweite Knoten die
zweite Kopie beibehält, wobei
die zweite Erlaubnis es dem zweiten Knoten nicht ermöglicht,
die zweite Kopie zu verändern
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Die
erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann
eine Änderungssperre
sein, die es dem zweiten Knoten ermöglicht, die erste Kopie zu
verändern,
die Änderungssperre
ermöglicht
es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben,
die zweite Erlaubnis kann eine Haltesperre sein, die es erfordert,
dass der zweite Knoten die zweite Kopie beibehält, und wobei die Haltesperre
es dem zweiten Knoten nicht ermöglicht,
die zweite Kopie zu verändern,
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Die
erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann
ein Änderungs-Token
sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu
verändern,
der Änderungs-Token
ermöglicht es
dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben,
die zweite Erlaubnis kann ein Halte-Token sein, der es erfordert,
dass der zweite Knoten die zweite Kopie beibehält, und wobei der Halte-Token
es dem zweiten Knoten nicht ermöglicht, die
zweite Kopie zu verändern,
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Das
Verfahren kann ferner die Schritte aufweisen: vor dem Empfangen
der Anforderung, Zuordnen eines ersten Zustands zu der ersten Kopie, der
es dem zweiten Knoten ermöglicht,
die erste Kopie zu verändern,
und es dem zweiten Knoten ermöglicht,
die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen,
dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Zuordnen
eines zweiten Zustands zu der ersten Kopie, der es dem zweiten Knoten
ermöglicht,
die erste Kopie auf Platte zu schreiben, wobei der zweite Zustand es
dem zweiten Knoten nicht ermöglicht,
die erste Kopie zu verändern
oder zu überschreiben.
-
Der
erste Zustand kann ein aktueller Zustand sein, der es dem zweiten
Knoten ermöglicht,
die erste Kopie zu verändern,
und es dem zweiten Knoten ermöglicht,
die erste Kopie auf Platte zu schreiben, und der zweite Zustand
kann ein schreibbarer Früheres-Abbild-Zustand
sein, der es dem zweiten Knoten ermöglicht, die erste Kopie auf
Platte zu schreiben, wobei der schreibbare Früheres-Abbild-Zustand es nicht
ermöglicht,
dass der zweite Knoten die erste Kopie verändert oder überschreibt.
-
Das
Verfahren kann ferner den Schritt aufweisen: Veranlassen, dass der
zweite Knoten eine Änderungs-Erlaubnis
von dem zweiten Knoten an den ersten Knoten überträgt.
-
Das
Verfahren kann ferner den Schritt aufweisen: Empfangen einer Nachricht
von dem zweiten Knoten, dass der zweite Knoten die Änderungs-Erlaubnis
an den ersten Knoten übertragen
hat.
-
Die
Nachricht, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten
Knoten übertragen
hat, kann empfangen werden, nachdem der zweite Knoten die Änderungs-Erlaubnis
an den ersten Knoten überträgt.
-
Das
Verfahren kann ferner die Schritte aufweisen: Speichern von Daten,
die anzeigen, dass der erste Knoten die Änderungs-Erlaubnis enthält.
-
Gemäß einem
anderen Aspekt der Erfindung wird ein computerlesbares Medium, das
eine Folge oder mehrere Folgen von Befehlen zum Verwalten einer
Ressource, die von einer Mehrzahl von Knoten verwendet wird, enthält, vorgeschlagen,
wobei die Ausführung
der einen Folge oder der mehreren Folgen von Befehlen mittels eines
Prozessors oder mehrerer Prozessoren den einen Prozessor oder die mehreren
Prozessoren dazu veranlasst, die Schritte auszuführen: Empfangen einer Anforderung
für die Ressource
von einem ersten Knoten der Mehrzahl von Knoten, wobei der erste
Knoten einen ersten Zwischenspeicher aufweist; Identifizieren eines
zweiten Knotens der Mehrzahl von Knoten, wobei der zweite Knoten
einen zweiten Zwischenspeicher aufweist, der eine erste Kopie der
Ressource aufweist; Veranlassen, dass der zweite Knoten eine zweite
Kopie der Ressource von dem zweiten Zwischenspeicher an den ersten
Zwischenspeicher überträgt, ohne
zuerst die Ressource von dem zweiten Zwischenspeicher in einem andauernden
Speicher dauerhaft zu speichern; und Veranlassen, dass mindestens
eine Kopie der Ressource in dem zweiten Zwischenspeicher beibehalten
wird, bis die erste Kopie der Ressource oder ein Versionsnachfolger
von ihr dauerhaft gespeichert ist.
-
Der
erste Knoten kann ein erster Datenbank-Server sein und der zweite
Knoten kann ein zweiter Datenbank-Server sein.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Empfangen, von einem dritten Knoten der Mehrzahl von Knoten, einer
zusätzlichen
Anforderung für
eine Erlaubnis, wobei der dritte Knoten eine dritte Kopie der Ressource
in einem dritten Zwischenspeicher aufweist und wobei die Erlaubnis
es dem dritten Knoten ermöglicht,
die Ressource auf Platte zu schreiben, aber es dem dritten Knoten
nicht ermöglicht,
die Ressource zu verändern;
Identifizieren eines vierten Knotens der Mehrzahl von Knoten, wobei
der vierte Knoten eine vierte Kopie der Ressource in einem vierten
Zwischenspeicher aufweist und wobei die vierte Kopie mindestens
so neu wie die dritte Kopie ist; und Veranlassen, dass der vierte
Knoten die vierte Kopie auf Platte schreibt.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Veranlassen, dass alle Kopien der Ressource, die älter sind als
die vierte Kopie, freigegeben werden, als Reaktion darauf, dass
der vierte Knoten die vierte Kopie auf Platte schreibt.
-
Der
vierte Knoten kann der dritte Knoten sein oder kann nicht der dritte
Knoten sein.
-
Die
vierte Kopie der Ressource kann ein früheres Abbild der Ressource
sein.
-
Das
frühere
Abbild der Ressource kann mindestens so neu wie jedes andere frühere Abbild
der Ressource sein, das aktuell von der Mehrzahl von Knoten beibehalten
wird.
-
Die
vierte Kopie der Ressource kann eine aktuelle Version der Ressource
sein.
-
Bei
dem computerlesbaren Medium können die
Befehle zum Veranlassen, dass der vierte Knoten die vierte Kopie
auf Platte schreibt, ferner Befehle aufweisen, die, wenn sie mittels
des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, den
Schritt auszuführen:
Bereitstellen einer zusätzlichen
Erlaubnis für
den vierten Knoten, die es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei die zusätzliche
Erlaubnis es dem vierten Knoten nicht ermöglicht, die vierte Kopie zu
verändern.
-
Die
zusätzliche
Erlaubnis, die für
den vierten Knoten bereitgestellt wird, kann eine Schreibsperre sein,
die es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei die Schreibsperre
es dem vierten Knoten nicht ermöglicht,
die vierte Kopie zu verändern.
-
Die
zusätzliche
Erlaubnis, die für
den vierten Knoten bereitgestellt wird, kann ein Schreib-Token sein,
der es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben, wobei der Schreib-Token
es dem vierten Knoten nicht ermöglicht,
die vierte Kopie zu verändern.
-
Bei
dem computerlesbaren Medium können die
Befehle zum Veranlassen, dass der vierte Knoten die vierte Kopie
auf Platte schreibt, ferner Befehle aufweisen, die, wenn sie mittels
des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, den
Schritt auszuführen:
Zuordnen eines Zustands zu der vierten Kopie, wobei der Zustand
es dem vierten Knoten ermöglicht,
die vierte Kopie auf Platte zu schreiben.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Bereitstellen, vor dem Empfangen der Anforderung, einer ersten Erlaubnis
für den
zweiten Knoten, die es dem zweiten Knoten ermöglicht, die erste Kopie zu
verändern,
wobei die erste Erlaubnis es dem zweiten Knoten nicht ermöglicht,
die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen,
dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Bereitstellen
einer zweiten Erlaubnis für
den zweiten Knoten, die es erfordert, dass der zweite Knoten die
zweite Kopie beibehält,
und wobei die zweite Erlaubnis es dem zweiten Knoten nicht ermöglicht,
die zweite Kopie zu verändern,
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Die
erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann
eine Änderungssperre
sein, die es dem zweiten Knoten ermöglicht, die erste Kopie zu
verändern,
die Änderungssperre
ermöglicht
es dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben,
die zweite Erlaubnis kann eine Haltesperre sein, die es erfordert,
dass der zweite Knoten die zweite Kopie beibehält, und wobei die Haltesperre
es dem zweiten Knoten nicht ermöglicht,
die zweite Kopie zu verändern,
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Die
erste Erlaubnis, die dem zweiten Knoten bereitgestellt wird, kann
ein Änderungs-Token
sein, der es dem zweiten Knoten ermöglicht, die erste Kopie zu
verändern,
der Änderungs-Token
ermöglicht es
dem zweiten Knoten nicht, die erste Kopie auf Platte zu schreiben,
die zweite Erlaubnis kann ein Halte-Token sein, der es erfordert,
dass der zweite Knoten die zweite Kopie beibehält, und wobei der Halte-Token
es dem zweiten Knoten nicht ermöglicht, die
zweite Kopie zu verändern,
und es dem zweiten Knoten nicht ermöglicht, die zweite Kopie auf
Platte zu schreiben.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
vor dem Empfangen der Anforderung, Zuordnen eines ersten Zustands
zu der ersten Kopie, der es dem zweiten Knoten ermöglicht,
die erste Kopie zu verändern,
und es dem zweiten Knoten ermöglicht,
die erste Kopie auf Platte zu schreiben; und vor dem Veranlassen,
dass der zweite Knoten die zweite Kopie an den ersten Zwischenspeicher überträgt, Zuordnen
eines zweiten Zustands zu der ersten Kopie, der es dem zweiten Knoten
ermöglicht,
die erste Kopie auf Platte zu schreiben, wobei der zweite Zustand
es dem zweiten Knoten nicht ermöglicht,
die erste Kopie zu verändern
oder zu überschreiben.
-
Der
erste Zustand kann ein aktueller Zustand sein, der es dem zweiten
Knoten ermöglicht,
die erste Kopie zu verändern,
und es dem zweiten Knoten ermöglicht,
die erste Kopie auf Platte zu schreiben, und der zweite Zustand
kann ein schreibbarer Früheres-Abbild-Zustand
sein, der es dem zweiten Knoten ermöglicht, die erste Kopie auf
Platte zu schreiben, wobei der schreibbare Früheres-Abbild-Zustand es nicht
ermöglicht,
dass der zweite Knoten die erste Kopie verändert oder überschreibt.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Veranlassen, dass der zweite Knoten eine Änderungs-Erlaubnis von dem
zweiten Knoten an den ersten Knoten überträgt.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Empfangen einer Nachricht von dem zweiten Knoten, dass der zweite
Knoten die Änderungs-Erlaubnis
an den ersten Knoten übertragen
hat.
-
Die
Nachricht, dass der zweite Knoten die Änderungs-Erlaubnis an den ersten
Knoten übertragen
hat, kann empfangen werden, nachdem der zweite Knoten die Änderungs-Erlaubnis
an den ersten Knoten überträgt.
-
Das
computerlesbare Medium kann ferner Befehle aufweisen, die, wenn
sie mittels des Prozessors oder der mehreren Prozessoren ausgeführt werden,
den einen Prozessor oder die mehreren Prozessoren veranlassen, die
Schritte auszuführen:
Speichern von Daten, die anzeigen, dass der erste Knoten die Änderungs-Erlaubnis
enthält.
-
Während Techniken
zum Handhaben von Pings hierin in Bezug auf Pings beschrieben wurden, welche
auftreten, wenn Mehrfach-Datenbankserver auf
eine gemeinsame, dauerhafte Speichervorrichtung Zugriff haben, sind
diese Techniken nicht auf diesen Kontext beschränkt. Insbesondere können diese
Techniken in jedem Umfeld angewandt werden, in welchem ein Prozess,
welcher mit einem Zwischenspeicher assoziiert ist, eine Ressource
anfordert, deren aktuelle Version sich in einem anderen Zwischenspeicher
befindet. Solche Umfelder schließen zum Beispiel Umfelder,
in welchen Textserver an verschiedenen Knoten zu dem selben Textmaterial Zugriff
haben, Umfelder, in welchen Medienserver an verschiedenen Knoten
Zugriff zu den selben Videodaten usw. haben, ein.
-
Handhaben
von Pings mittels der hierin beschriebenen Techniken, stellt effektives
Zwischen-Datenbankserver-Übertragen
von Ressourcen bereit, so dass die Betriebszeit-Leistungsfähigkeit gut mit der ansteigenden
Anzahl von Datenbankservern und Benutzern je Datenbankserver skaliert. Zusätzlich laufen
die Techniken auf eine effiziente Wiederherstellung von Einzel-Datenbankserver-Abstürzen (dem
häufigsten
Typ von Abstürzen)
heraus, welches gut mit der anwachsenden Zahl von Datenbankservern
skaliert.
-
Signifikanterweise
handhaben die hierin beschriebenen Techniken Pings mittels Sendens
von Ressourcen über
den IPC Transport und nicht mittels Platten-Intervention. Folglich
sind Platten E/As für Ressourcen,
welche in einem Ping enden, im Wesentlichen beseitigt. Ein synchroner
E/A ist nur so lange involviert, wie er für das Erzwingen des Logs nötig ist.
Zusätzlich
verlangsamen solche E/A nicht das Puffer-Verschicken quer durch das Cluster,
während
durch Setzen von Prüfpunkten
und Setzen von Puffer-Zwischenspeichern Platten E/A auftritt.
-
Die
direkten Versendungstechniken, welche hierin beschrieben wurden
tendieren auch dazu die Anzahl von Kontext-Umschaltungen, welche durch ein Ping
auftreten, zu reduzieren. Insbesondere wird die Sequenz von Schleifen-Nachrichten zwischen den
Teilnehmern des Protokolls (Anforderer und Halter) und dem Hauptserver
mittels des Kommunikationsdreiecks ersetzt: Anforderer, Hauptserver,
Halter, Anforderer.
-
In
der vorangegangenen Ausführung
wurde die Erfindung mit Bezug auf spezifische Ausführungsbeispiele
hiervon beschrieben. Es wird jedoch klar sein, dass dazu verschiedenartige
Modifikationen und Änderungen
gemacht werden können.
Die Ausführung
und Figuren sind gemäß mehr in
einem erklärenden
als in einem einschränkenden
Sinne zu beachten.