DE102013101863A1 - Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen - Google Patents

Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen Download PDF

Info

Publication number
DE102013101863A1
DE102013101863A1 DE102013101863.7A DE102013101863A DE102013101863A1 DE 102013101863 A1 DE102013101863 A1 DE 102013101863A1 DE 102013101863 A DE102013101863 A DE 102013101863A DE 102013101863 A1 DE102013101863 A1 DE 102013101863A1
Authority
DE
Germany
Prior art keywords
database
computer node
computer
main memory
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102013101863.7A
Other languages
English (en)
Inventor
Bernd Winkelsträter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Technology Solutions Intellectual Property GmbH
Original Assignee
Fujitsu Technology Solutions Intellectual Property GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Technology Solutions Intellectual Property GmbH filed Critical Fujitsu Technology Solutions Intellectual Property GmbH
Priority to DE102013101863.7A priority Critical patent/DE102013101863A1/de
Priority to US14/190,409 priority patent/US20140244578A1/en
Publication of DE102013101863A1 publication Critical patent/DE102013101863A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2005—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/1827—Management specifically adapted to NAS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

Die Erfindung betrifft ein hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700), umfassend eine Mehrzahl von Rechnerknoten (110, 310, 510, 710), umfassend wenigstens einen Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung einer Redundanz des Datenbanksystems. Das hochverfügbare Hauptspeicher-Datenbanksystem (100, 300, 500, 700) umfasst des Weiteren wenigstens eine Verbindungsstruktur zur datentechnischen Kopplung der Mehrzahl Rechnerknoten (110, 310, 510, 710) untereinander. Dabei weist jeder Rechnerknoten (110, 310, 510, 710) eine Synchronisationskomponente auf, die dazu eingerichtet ist, eine Kopie der Daten eines dem jeweiligen Rechnerknoten (110, 310, 510, 710) zugeordneten Datenbanksegments in wenigstens einem nichtflüchtigen Speicher wenigstens eines anderen Rechnerknotens (110b, 310d, 510d, 710d) redundant zu speichern. Die Erfindung betrifft des Weiteren Arbeitsverfahren (200, 400, 600) sowie Verwendungen eines hochverfügbaren Datenbanksystems und eines nichtflüchtigen Massenspeichers eines Rechnerknotens (110, 310, 510, 710).

Description

  • Die Erfindung betrifft ein hochverfügbares Hauptspeicher-Datenbanksystem, umfassend eine Mehrzahl von Rechnerknoten mit wenigstens einem Rechnerknoten zur Herstellung einer Redundanz des Datenbanksystems. Die Erfindung betrifft des Weiteren ein Arbeitsverfahren für ein hochverfügbares Hauptspeicher-Datenbanksystem und eine Verwendung eines hochverfügbaren Hauptspeicher-Datenbanksystems sowie eines nichtflüchtigen Massenspeichers eines Rechnerknotens eines Hauptspeicher-Datenbanksystems.
  • Datenbanksysteme sind aus dem Bereich der elektronischen Datenverarbeitung allgemein bekannt. Sie dienen zur Speicherung verhältnismäßig großer Mengen von Daten für verschiedene Anwendungszwecke. Typischerweise sind die Daten wegen ihres Umfangs in einem oder mehreren nichtflüchtigen sekundären Speichermedium, beispielsweise einem Festplattenlaufwerk, gespeichert und werden zur Abfrage auszugsweise in einen flüchtigen primären Hauptspeicher eines Datenbanksystems eingelesen. Zur Auswahl der einzulesenden Daten werden hierzu insbesondere bei relationalen Datenbanksystemen in der Regel Indexstrukturen verwendet, über die zur Beantwortung einer Abfrage relevante Datensätze ausgewählt werden können.
  • Insbesondere bei besonders leistungsfähigen Datenbankanwendungen ist es darüber hinaus auch bekannt, die gesamten oder zumindest wesentliche Teile der abzufragenden Daten in einem Haupt- oder Arbeitsspeicher des Datenbanksystems vorzuhalten. So genannte Hauptspeicher-Datenbanken eignen sich insbesondere zur Beantwortung besonders zeitkritischer Anwendungen. Die dabei eingesetzten Datenstrukturen unterscheiden sich von denen von Datenbanksystemen mit sekundären Massenspeichern, da beim Zugriff auf den Hauptspeicher wegen des wahlfreien Zugriffs auf einzelne Speicherzellen anderes als beim Zugriff auf Blöcke eines sekundären Massenspeicher eine wesentlich geringere Latenzzeit entsteht. Beispiele solcher Anwendungen sind unter anderem die Beantwortung einer Vielzahl von parallelen, verhältnismäßig einfachen Anfragen im Bereich elektronischer Datenübertragungsnetzwerke, etwa beim Betrieb eines Routers oder einer Suchmaschine. Ebenso finden Hauptspeicher-Datenbanksysteme Anwendung bei der Beantwortung sehr komplexer Fragestellungen, für die ein wesentlicher Teil der gesamten Daten des Datenbanksystems berücksichtigt werden müssen. Beispiele solcher komplexer Anwendungen sind beispielsweise das so genannte Data Mining, das so genannte On-Line Transaction Processing (OLTP) und das so genannte Online Analytical Processing (OLAP).
  • Trotz immer weiter wachsender Hauptspeichergrößen ist es teilweise praktisch nicht möglich oder zumindest wirtschaftlich nicht sinnvoll, sämtliche Daten eines großen Datenbestands in einem Hauptspeicher eines einzelnen Rechnerknotens zur Beantwortung von Abfragen vorzuhalten. Zudem würde die Vorhaltung sämtlicher Daten in einem einzigen Rechnerknoten einen zentralen Fehlerpunkt und Flaschenhals darstellen und somit zu einem erhöhten Ausfallrisiko bzw. einem verringerten Datendurchsatz führen.
  • Zur Lösung dieser und anderer Probleme ist es bekannt, die Daten einer Hauptspeicher-Datenbank in einzelne Datenbanksegmente aufzuteilen und auf einer Mehrzahl von Rechnerknoten eines gekoppelten Rechnerverbunds zu speichern und abzufragen. Ein Beispiel eines derartigen Rechnerverbunds, der bevorzugt aus einer Kombination von Hard- und Software besteht, ist unter der Bezeichnung HANA (High-Performance Analytic Appliance) der SAP AG bekannt. Grundsätzlich bietet das von der Firma SAP AG vertriebene Produkt eine besonders gute Leistungsfähigkeit bei der Abfrage großer Mengen von Daten.
  • Wegen der Größe der in einem solchen Datenbanksystem gespeicherten Daten kommt es insbesondere beim Ausfall und nachfolgendem Neustart einzelner Rechnerknoten sowie auch beim ersten Einschalten des Datenbanksystems zu erheblichen Verzögerungen beim Laden der Daten in einen Hauptspeicher des bzw. der Rechnerknoten.
  • Aufgabe der vorliegenden Anmeldung ist es, ein weiter verbessertes, hochverfügbares Hauptspeicher-Datenbanksystem zu beschreiben. Bevorzugt soll das beschriebene Hauptspeicher-Datenbanksystem eine verringerte Latenzzeit beim Laden von Daten in einen Hauptspeicher von einzelnen oder mehreren Rechnerknoten des Hauptspeicher-Datenbanksystems ermöglichen. Insbesondere soll die sogenannte Failover-Zeit, also die Latenzzeit zwischen dem Ausfall eines Rechnerknotens und dessen Ersatz durch einen anderen Rechnerknoten, verkürzt werden.
  • Gemäß einem ersten Aspekt der vorliegenden Anmeldung wird ein hochverfügbares Hauptspeicher-Datenbanksystem offenbart. Das System umfasst eine Mehrzahl von Rechnerknoten, die wenigstens einen Rechnerknoten zur Herstellung einer Redundanz des Datenbanksystems umfassen. Das System umfasst des Weiteren wenigstens eine Verbindungsstruktur zur datentechnischen Kopplung der Mehrzahl von Rechnerknoten untereinander. Dabei weist jeder der Rechnerknoten wenigstens einen lokalen nichtflüchtigen Speicher zum Speichern eines dem jeweiligen Rechnerknoten zugeordneten Datenbanksegments und mindestens eine Datenverarbeitungskomponente zum Ausführen einer Datenbanksoftware zur Abfrage des dem Rechnerknoten zugeordneten Datenbanksegments auf. Des Weiteren weist jeder der Rechnerknoten eine Synchronisationskomponente auf, die dazu eingerichtet ist, eine Kopie der Daten eines dem jeweiligen Rechnerknoten zugeordneten Datenbanksegments in wenigstens einem nichtflüchtigen Speicher wenigstens eines anderen Rechnerknotens redundant zu speichern. Zumindest der wenigstens eine Rechnerknoten zur Herstellung der Redundanz ist dazu eingerichtet, beim Ausfall wenigstens eines der Mehrzahl von Rechnerknoten die Datenbanksoftware zur Abfrage wenigstens eines Teils des dem ausgefallenen Rechnerknoten zugeordneten Datenbanksegments basierend auf einer Kopie der zugehörigen Daten in dem lokalen nichtflüchtigen Speicher auszuführen, um die Latenzzeit beim Ausfall des Rechnerknotens zu reduzieren.
  • In dem beschriebenen Hauptspeicher-Datenbanksystem werden, abweichend von bisher bekannten Systemen, jeweils ein Datenbanksegment in einem lokalen nichtflüchtigen Speicher des Rechnerknotens gespeichert, der auch zur Abfrage des entsprechenden Datenbanksegments dient. Durch die lokale Speicherung kann eine maximale Bandbreite, beispielsweise eine Systembusbandbreite oder eine Bandbreite eines I/O-Busses eines Rechnerknotens, beim Übertragen der Daten aus dem lokalen nichtflüchtigen Speicher in den Hauptspeicher des Hauptspeicher-Datenbanksystems erzielt werden. Um trotz der lokalen Speicherung eine Redundanz des gespeicherten Datenbanksegments herzustellen, wird über die Synchronisationskomponente zusätzlich eine Kopie der Daten in wenigstens einem nichtflüchtigen Speicher wenigstens eines anderen Rechnerknotens redundant gespeichert. Das Datenbanksegment kann neben den eigentlichen Daten der Datenbank selbst auch weitere Informationen, insbesondere Transaktionsdaten und zugehörige Logdaten umfassen.
  • Beim Ausfall eines der Rechnerknoten kann daher das in dem ausgefallenen Rechnerknoten lokal gespeicherte Datenbanksegment basierend auf der Kopie der Daten in einem anderen Rechnerknoten wiederhergestellt werden, ohne dass es eines zentralen Speichersystems, wie beispielsweise eines zentralen Netzwerkspeichers, bedarf. Dabei dienen die Rechnerknoten des Datenbanksystems sowohl als Synchronisationsquelle als auch Synchronisationsziel. Durch die Wiederherstellung des ausgefallenen Datenbanksegments aus einem oder einer Mehrzahl von Rechnerknoten kann eine besonders hohe Bandbreite beim Laden des Datenbanksegments in den Rechnerknoten zur Herstellung der Redundanz erzielt werden.
  • Durch Ausnutzung einer lokalen Speicherung und einer hohen Datenübertragungsbandbreite zwischen den einzelnen Rechnerknoten wird die so genannte Failover-Zeit, also die Latenzzeit, die durch den Ausfall eines Rechnerknotens entsteht, minimiert. Mit anderen Worten kombiniert die Erfindung die Geschwindigkeitsvorteile einer möglichst lokalen Speicherung der benötigten Daten mit der Herstellung einer Redundanz durch die Verteilung der Daten auf mehrere Rechnerknoten, um bei Beibehaltung einer hohen Ausfallsicherheit eine Verringerung der Failover-Zeit zu erreichen.
  • Basierend auf der derzeit vorherrschenden Rechnerarchitektur wird das Datenbanksegment beispielsweise in einem nichtflüchtigen, sekundären Massenspeicher der Rechnerknoten dauerhaft gespeichert und zum Bearbeiten von Abfragen in einen flüchtigen, primären Hauptspeicher des jeweiligen Rechnerknotens geladen. Beim Ausfall wenigstens eines Rechnerknotens lädt der Rechnerknoten zur Herstellung der Redundanz wenigstens einen Teil des dem ausgefallenen Rechnerknoten zugeordneten Datenbanksegments aus einer Kopie in dem nichtflüchtigen Massenspeicher über ein lokales Bussystem zur Abfrage in den flüchtigen Hauptspeicher. Durch das Laden von Daten über ein lokales Bussystem kann eine lokal zur Verfügung stehende, hohe Bandbreite zur Minimierung der Failover-Zeit verwendet werden.
  • In einer vorteilhaften Ausgestaltung ist die wenigstens eine Datenverarbeitungskomponente eines Rechnerknotens hierfür über wenigstens eine Direct Attach Storage (DAS) Verbindung mit dem nichtflüchtigen Massenspeicher des Rechnerknotens verbunden. Neben bekannten Verbindungen, beispielsweise basierend auf dem Small Computer System Interface (SCSI) oder dem Peripheral Connect Interface Express (PCIe), bieten sich zur weiteren Erhöhung der Übertragungsbandbreite auch neuartige nichtflüchtige Massenspeicher und deren Schnittstellen, beispielsweise so genannte DIMM-SSD-Speichermodule an, die direkt in einen Steckplatz zur Aufnahme eines Speichermoduls auf einer Systemplatine eines Rechnerknotens eingesteckt werden können.
  • Des Weiteren ist es auch möglich, einen nichtflüchtigen Speicher selbst als Hauptspeicher des jeweiligen Rechnerknotens zu nutzen. In diesem Fall befindet sich in dem nichtflüchtigen Hauptspeicher jeweils wenigstens ein Teil des oder das gesamte, dem jeweiligen Rechnerknoten zugeordnete Datenbanksegment sowie optional ein Teil einer Kopie eines Datenbanksegments eines anderen Rechnerknotens. Dieses Konzept eignet sich insbesondere für neuartige und zukünftige Rechnerstrukturen, bei denen nicht mehr zwischen primärem und sekundärem Speicher unterschieden wird.
  • Die beteiligten Rechnerknoten können über unterschiedliche Verbindungstechniken miteinander gekoppelt werden. Für eine besonders hochleistungsfähigen Kopplung der einzelnen Rechnerknoten eignet sich beispielsweise die Vorsehung einer Mehrzahl von parallelen Verbindungspfaden, insbesondere einer Mehrzahl von so genannten PCIe-Datenleitungen. Alternativ oder zusätzlich können auch ein oder mehrere serielle Hochgeschwindigkeitsleitungen, beispielsweise gemäß dem InfiniBand (IB) Standard, vorgesehen werden. Bevorzugt sind die Rechnerknoten über die Verbindungsstrukturen derart miteinander gekoppelt, dass der Rechnerknoten zur Herstellung der Redundanz gemäß einem Remote Direct Memory Access (RDMA) Protokoll direkt auf den Inhalt eines Speichers wenigstens eines anderen Rechnerknotens, beispielsweise dessen Hauptspeicher oder einen lokal an den anderen Knoten angeschlossenen nichtflüchtigen Massenspeicher, zugreifen kann.
  • Die beschriebene Architektur kann je nach Größe und Anforderungen des Hauptspeicher-Datenbanksystems in verschiedenen Konfigurationen ausgestaltet werden. In einer so genannten Single-Node-Failover-Konfiguration umfasst die Mehrzahl von Rechnerknoten wenigstens einen ersten und einen zweiten Rechnerknoten, wobei eine gesamte abzufragende Datenbank dem ersten Rechner zugeordnet und in dem nichtflüchtigen lokalen Speicher des ersten Rechnerknotens gespeichert ist. Eine Kopie der gesamten Datenbank ist des Weiteren in dem nichtflüchtigen lokalen Speicher des zweiten Rechnerknotens redundant gespeichert, wobei in einem normalen Betriebszustand die Datenbanksoftware des ersten Rechnerknotens Anfragen an die Datenbank beantwortet und durch die Anfrage verursachte Datenbankänderungen mit der in dem nichtflüchtigen Speicher des zweiten Rechnerknotens gespeicherten Kopie der Datenbank synchronisiert werden. Die Datenbanksoftware des zweiten Rechnerknotens beantwortet zumindest bei einem Ausfall des ersten Rechnerknotens Anfragen an die Datenbank. Durch die redundante Vorhaltung von Daten der gesamten Datenbank in zwei Rechnerknoten kann beim Ausfall des ersten Rechnerknotens die Beantwortung von Abfragen durch den zweiten Rechnerknoten ohne signifikante Verzögerung fortgesetzt werden.
  • In einer weiteren, insbesondere zum Einsatz von besonders umfangreicher Datenbanken geeigneten, so genannten Multi-Node-Failover-Konfiguration umfasst die Mehrzahl von Rechnerknoten eine erste Anzahl n, n > 1, von aktiven Rechnerknoten. Jeder der aktiven Rechnerknoten ist dazu eingerichtet, ein anderes von insgesamt n voneinander unabhängig abfragbaren Datenbanksegmenten sowie wenigstens eine Kopie der Daten wenigstens eines Teils eines einem anderen aktiven Rechnerknoten zugeordneten Datenbanksegments in seinem nichtflüchtigen lokalen Speicher zu speichern. Durch die Verteilung der Datenbank auf insgesamt n voneinander unabhängig abfragbare Datenbanksegmente, die einer entsprechenden Anzahl von Rechnerknoten zugeordnet sind, können auch besonders umfangreiche Daten parallel und damit schnell abgefragt werden. Durch die zusätzliche Speicherung wenigstens eines Teil jeweils eines einem anderen Rechnerknoten zugeordneten Datenbanksegments in einem nichtflüchtigen lokalen Speicher bleibt die Redundanz der gespeicherten Daten beim Ausfall eines beliebigen aktiven Rechnerknotens gewahrt.
  • Gemäß einer möglichen Ausgestaltung umfasst die Mehrzahl von Rechnerknoten zusätzlich eine zweite Anzahl m, m ≥ 1, von passiven Rechnerknoten zur Herstellung der Redundanz, denen in einem normalen Betriebszustand kein Datenbanksegment zugeordnet ist. Bei einer derartigen Anordnung steht jeweils mindestens ein redundanter, im Normalbetrieb passiver Rechnerknoten zur Übernahme des Datenbanksegments eines ausgefallenen Rechnerknotens zur Verfügung.
  • Gemäß einer weiteren vorteilhaften Ausgestaltung ist jeder der aktiven Rechnerknoten dazu eingerichtet, bei einem Ausfall eines anderen aktiven Rechnerknotens zusätzlich zu Anfragen betreffend das dem jeweiligen Rechnerknoten zugeordneten Datenbanksegments wenigstens einen Teil von Anfragen betreffend das dem ausgefallenen Rechnerknoten zugeordneten Datenbanksegments basierend auf der in dem lokalen Speicher des jeweiligen Rechnerknotens gespeicherten Kopie der Daten des entsprechenden Datenbanksegments zu beantworten. Auf diese Weise kann das Laden eines Datenbanksegments eines ausgefallenen Rechnerknotens von einem anderen Rechnerknoten zumindest vorübergehend vermieden werden, sodass es zu keiner signifikanten Verzögerung bei der Beantwortung von Anfragen an das hochverfügbare Hauptspeicher-Datenbanksystem kommt.
  • Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Arbeitsverfahren für ein hochverfügbares Hauptspeicher-Datenbanksystem mit einer Mehrzahl von Rechnerknoten beschrieben. Das Arbeitsverfahren weist die folgenden Schritte auf:
    • – Speichern wenigstens eines ersten Datenbanksegments in einem nichtflüchtigen, lokalen Speicher eines ersten Rechnerknotens;
    • – Speichern einer Kopie des wenigstens einen ersten Datenbanksegments in wenigstens einem nichtflüchtigen lokalen Speicher wenigstens eines zweiten Rechnerknotens;
    • – Ausführen von Datenbankabfragen bezüglich des ersten Datenbanksegments durch den ersten Rechnerknoten;
    • – Speichern von Datenbankänderungen bezüglich des ersten Datenbanksegments in dem nichtflüchtigen lokalen Speicher des ersten Rechnerknotens;
    • – Speichern einer Kopie der Datenbankänderungen bezüglich des ersten Datenbanksegments in dem nichtflüchtigen lokalen Speicher des wenigstens einen zweiten Rechnerknotens; und
    • – Ausführen von Datenbankabfragen bezüglich des ersten Datenbanksegments durch einen redundanten Rechnerknoten basierend auf der gespeicherten Kopie des ersten Datenbanksegments und/oder der gespeicherten Kopie der Datenbankänderungen, falls der erste Rechnerknoten ausfällt.
  • Durch die beschriebenen Schritte wird die lokale Speicherung von Datenbanksegmenten in einer Mehrzahl von Rechnerknoten ermöglicht, wobei gleichzeitig die Redundanz der abzufragenden Datenbanksegmente gewahrt bleibt, so dass entsprechende Datenbankabfragen beim Ausfall des ersten Rechnerknotens weiterhin beantwortet werden können. Durch die Speicherung der dazu benötigten Daten in einem lokalen Speicher eines zweiten Rechnerknotens kann die so genannte Failover-Zeit verringert werden.
  • Gemäß einer vorteilhaften Ausgestaltung umfasst das Verfahren den Schritt des Wiederherstellens des ersten Datenbanksegments in einem nichtflüchtigen lokalen Speicher des redundanten und/oder ausgefallenen Rechnerknotens basierend auf den in dem wenigstens einen nichtflüchtigen Speicher des wenigstens einen zweiten Rechnerknotens gespeicherten Kopie des ersten Datenbanksegments und/oder der Kopie der Datenbankänderungen des ersten Datenbanksegments. Durch das Laden des Datenbanksegments sowie zugehöriger Datenbankänderungen aus einem lokalen nichtflüchtigen Speicher eines anderen Rechnerknotens kann eine besonders hohe Bandbreite beim Wiederherstellen des ausgefallenen Datenbanksegments erzielt werden.
  • Gemäß einer weiteren vorteilhaften Ausgestaltung wird wenigstens ein Teil wenigstens eines anderes Datenbanksegments, der in dem ausgefallen Rechnerknoten redundant gespeichert war, von wenigstens einem dritten Rechnerknoten in den nichtflüchtigen Speicher des redundanten und/oder ausgefallenen Rechnerknotens kopiert, um eine Redundanz des anderen Datenbanksegments wiederherzustellen.
  • Das Hauptspeicher-Datenbanksystem gemäß dem ersten Aspekt und das Arbeitsverfahren gemäß dem zweiten Aspekt eignen sich insbesondere für eine Verwendung in einer Datenbankvorrichtung, insbesondere einer On-Line Analytical Processing (OLAP) oder On-Line Transaction Processing (OLTP) Datenbank-Appliance.
  • Gemäß einem weiteren Aspekt der Erfindung wird die Verwendung eines nichtflüchtigen Massenspeichers eines Rechnerknotens eines Hauptspeicher-Datenbanksystems zum Wiederherstellen eines abzufragenden Datenbanksegments in einem Hauptspeicher des Rechnerknotens über ein lokales, beispielsweise knoteninternes Bussystem beschrieben. Die Verwendung des nichtflüchtigen Massenspeichers dient unter anderem dazu, durch Einsatz einer hohen lokalen Busbandbreite die Latenzzeit beim Starten oder Übernehmen eines Datenbanksegments zu verringern. Dies führt unter anderem gegenüber dem Abruf eines wiederherzustellenden Datenbanksegments aus einem zentralen Speicherserver zu einer verringerter Failover-Zeit nach dem Ausfall eines anderen Rechnerknotens des Hauptspeicher-Datenbanksystems.
  • Weitere vorteilhafte Ausgestaltungen der Erfindung sind in den angehängten Patentansprüchen sowie der nachfolgenden Beschreibung von Ausführungsbeispielen angegeben.
  • Die Erfindung wird nachfolgend anhand von unterschiedlichen Ausführungsbeispielen unter Bezugnahme auf die angehängten Figuren im Detail beschrieben. Darin werden gleichartige Komponenten durch Anhängen eines Suffixes voneinander unterschieden. Wird der Suffix weggelassen, gelten die jeweiligen Ausführungen für alle Instanzen der jeweiligen Komponente. In den Figuren zeigen:
  • 1A bis 1C eine Konfiguration eines Hauptspeicher-Datenbanksystems gemäß einer ersten Ausgestaltung,
  • 2 ein Ablaufdiagramm eines Verfahrens zum Betrieb des Datenbanksystems gemäß der ersten Ausgestaltung,
  • 3A bis 3D eine Konfiguration eines Hauptspeicher-Datenbanksystems gemäß einer zweiten Ausgestaltung,
  • 4 ein Ablaufdiagramm eines Verfahrens zum Betrieb des Datenbanksystems gemäß der zweiten Ausgestaltung,
  • 5A bis 5E eine Konfiguration eines Hauptspeicher-Datenbanksystems gemäß einer dritten Ausgestaltung,
  • 6 ein Ablaufdiagramm eines Verfahrens zum Betrieb des Datenbanksystems gemäß der dritten Ausgestaltung,
  • 7A bis 7D eine Konfiguration eines Hauptspeicher-Datenbanksystems gemäß einer vierten Ausgestaltung und
  • 8A und 8B eine Konfiguration eines konventionellen Hauptspeicher-Datenbanksystems.
  • Zum besseren Verständnis der Erfindung wird zunächst unter Bezugnahme auf die 8A und 8B eine konventionelle Architektur eines Hauptspeicher-Datenbanksystems mit einer Mehrzahl von Rechnerknoten und dessen Betrieb beschrieben.
  • 8A zeigt ein Hauptspeicher-Datenbanksystem 800, umfassend insgesamt acht Rechnerknoten 810a bis 810h, die in der 8A als "Node 0" bis "Node 7" bezeichnet sind. Darüber hinaus umfasst das Hauptspeicher-Datenbanksystem 800 im dargestellten Beispiel zwei Netzwerkspeicher 820a und 820b zum nichtflüchtigen Speichern sämtlicher Daten des Hauptspeicher-Datenbanksystems 800. Beispielsweise kann es sich um datei- oder blockbasierte Network Attached Storage (NAS) oder Storage Area Network (SAN) Komponenten handeln. Jeder der Rechnerknoten 810 ist über jeweils eine Datenverbindung 830, beispielsweise eine LAN- oder SAN-Verbindung, mit dem ersten und zweiten Netzwerkspeicher 820a bzw. 820b verbunden. Darüber hinaus sind die zwei Netzwerkspeicher 820a und 820b über eine Synchronisationskomponente 840 miteinander verbunden, um einen Abgleich darauf redundant gespeicherter Daten zu ermöglichen. Das Hauptspeicher-Datenbanksystem 800 ist als so genanntes hochverfügbares Clustersystem ausgestattet. Im Kontext der dargestellten Hauptspeicher-Datenbank heißt dies insbesondere, dass das System 800 gegen den Ausfall einzelner Rechnerknoten 810, Netzwerkspeicher 820 und Verbindungen 830 abgesichert werden muss. Zu diesem Zweck wird im dargestellten Ausführungsbeispiel der achte Rechnerknoten 810h als redundanter Rechnerknoten vorgehalten, während die verbleibenden sieben Rechnerknoten 810a bis 810g als aktive Rechnerknoten genutzt werden. Somit stehen von den insgesamt acht Rechnerknoten 810 nur sieben für die Abarbeitung von Anfragen zur Verfügung.
  • Auf Seiten der Netzwerkspeicher 820 wird durch die redundante Speicherung der gesamten Datenbank auf zwei unterschiedlichen Netzwerkspeichern 820a und 820b sowie deren Synchronisierung über die Synchronisationskomponente 840 sichergestellt, dass jeweils die gesamte Datenbank auch bei Ausfall eines der beiden Netzwerkspeicher 820a oder 820b zur Verfügung steht. Wegen der ebenfalls redundanten Datenverbindungen 830 kann jeder der Rechnerknoten 810 stets auf wenigstens einen Netzwerkspeicher 820 zugreifen.
  • Problematisch an der Architektur gemäß 8A ist es, dass beim Ausfall eines einzelnen Rechnerknotens 810, beispielsweise des dritten Rechnerknotens 810c, der bisher als redundanter Rechnerknoten bereitgehaltene Rechnerknoten 810h das gesamten zuvor dem Rechnerknoten 810c zugeordneten Datenbanksegment aus einem der Netzwerkspeicher 820a und 820b laden muss. Diese Situation ist in 8B dargestellt.
  • Zwar ist das Laden des Speicherinhalts des ausgefallenen Rechnerknotens 810c der in 8B dargestellten Architektur über die Verbindungen 830 grundsätzlich möglich, wegen der zentralen Natur der Netzwerkspeicher 820 und der zu ihrer Anbindung an die einzelnen Rechnerknoten 810 der in der Praxis typischerweise eingesetzten Netzwerktechnologien, wie beispielsweise Ethernet, ist die erzielbare Datenübertragungsrate jedoch begrenzt. Zusätzlich muss sich der Rechnerknoten 810h die zur Verfügung stehende Bandbreite der Netzwerkspeicher 820 mit den verbleibenden aktiven Rechnerknoten 810a, 810b sowie 810d bis 810g teilen. Diese Nutzen die Netzwerkseicher 820 unter anderem zum Ablegen von Transaktionsdaten und zugehörigen Logdaten. Insbesondere bei der Wiederherstellung eines Rechnerknotens 810 eines Hochleistungs-Hauptspeicher-Datenbanksystems, wie beispielsweise Datenbanksystemen mit Rechnerknoten mit mehreren Terabyte Hauptspeicher, kann es daher zu erheblichen Verzögerungen kommen. Basierend auf einem Rechnerknoten 810 mit beispielsweise acht Prozessoren und 12 TB Hauptspeicher ergibt sich bei Annahme von 6 TB wiederherzustellenden Daten eines Datenbanksegments aus dem Netzwerkspeicher 820 und dem Auswerten von 4 TB zugehörigen Logdaten eine beim Ausfall eines Rechnerknotens zu ladende Datenmenge von 10 TB. Mit einer angenommenen Datenübertragungsrate von 40 GBit/s der Datenverbindung 830, beispielsweise basierend auf dem 40-GBit Ethernet-Standard, ergibt sich somit eine Wiederherstellungszeit von etwa 33 Minuten, die insbesondere beim Betrieb von Echtzeitsystemen oftmals inakzeptabel ist.
  • 1A zeigt ein erstes Ausführungsbeispiel eines Hauptspeicher-Datenbanksystems 100 gemäß einer Ausgestaltung der Erfindung. Das Hauptspeicher-Datenbanksystem 100 umfasst im Ausführungsbeispiel zwei Rechnerknoten 110a und 110b. Jeder der Rechnerknoten 110a und 110b umfasst jeweils einen ersten nichtflüchtigen Massenspeicher 120a bzw. 120b sowie einen zweiten nichtflüchtigen Massenspeicher 130a bzw. 130b. Auf dem ersten nichtflüchtigen Massenspeicher 120a bzw. 120b sind jeweils die Daten der abzufragenden Datenbank abgelegt. In dem zweiten nichtflüchtigen Massenspeicher 130a bzw. 130b sind zugehörige Logdaten und/oder andere Transaktionsdaten bezüglich der an den Daten des ersten nichtflüchtigen Massenspeichers 120a bzw. 120b vorgenommenen Änderungen gespeichert. Im Ausführungsbeispiel handelt es sich um interne, über PCIe an eine Systemkomponente des jeweiligen Rechnerknotens 110 angeschlossene Massenspeicher. Insbesondere bei dem zweiten Massenspeicher 130 handelt es sich bevorzugt um einen besonderes schnelles PCIe-SSD-Laufwerk oder eine sogenannte DIMM-SSD.
  • Die beiden Rechnerknoten 110a und 110b sind im Ausführungsbeispiel gemäß 1A über zwei zueinander redundante, serielle Hochgeschwindigkeitsleitungen 140a, 140b miteinander verbunden. Bei den seriellen Hochgeschwindigkeitsleitungen 140a bzw. 140b handelt es sich im Ausführungsbeispiel beispielsweise um so genannte InfiniBand-Verbindungen.
  • Im Hauptspeicher-Datenbanksystem 100 gemäß 1A ist jeweils nur ein Rechnerknoten, in der 1A der erste Rechnerknoten 110a, aktiv. Hierzu sind in einen ersten Teil 160a eines Hauptspeichers 150a ein Betriebssystem sowie andere Systemsoftwarekomponenten und die zur Abfrage von Datenbankanfragen erforderliche Datenbanksoftware geladen. Zusätzlich ist auf diesem Rechnerknoten 110a auch der komplette, aktuelle Inhalt der Datenbank aus dem ersten nichtflüchtigen Speicher 120a in einen zweiten Teil 170a des Hauptspeichers 150a geladen. Während der Durchführung von Abfragen können Veränderungen an den in dem Hauptspeicher vorliegenden Daten anfallen. Diese werden durch die geladene Datenbanksoftware in der Form von Transaktionsdaten und zugehörigen Logdaten auf dem zweiten nichtflüchtigen Massenspeicher 130a protokolliert. Nach Protokollierung der Transaktionsdaten oder parallel dazu werden auch die in dem ersten nichtflüchtigen Massenspeicher 120a gespeicherten Daten der Datenbank geändert.
  • Alternativ kann das Hauptspeicher-Datenbanksystem 100 auch in einer so genannten "Aktiv/Aktiv-Konfiguration" betrieben werden. In diesem Fall sind in beiden Rechnerknoten jeweils ein Datenbanksegment geladen und durch die Datenbanksoftware abfragbar. Dabei kann es sich entweder um zwei unterschiedliche Datenbanken oder um ein und dieselbe Datenbank handeln, die parallel durch beide Rechnerknoten 110 abgefragt wird. Beispielsweise kann der erste Rechnerknoten 110a Anfragen ausführen, die zu Änderungen an dem Datenbanksegment führen und der zweite Rechnerknoten 110b parallel dazu in einer Nurlese-Betriebsart weitere Anfragen durchführen, die zu keinen Datenbankänderungen führen.
  • Um das Hauptspeicher-Datenbanksystem 100 gegen einen unerwarteten Ausfall des ersten Rechnerknotens 110a abzusichern, werden beim Betrieb des ersten Rechnerknotens 110a sämtliche anfallenden Änderungen an den Logdaten oder den eigentlichen Daten durch eine lokalen Synchronisationskomponente, insbesondere eine Software zum Synchronisieren von Netzwerkressourcen, über die seriellen Hochgeschwindigkeitsleitungen 140a und/oder 140b auch an den zweiten, passiven Rechnerknoten 110b übertragen. In dessen Hauptspeicher 150b ist im in der 1A dargestellten Zustand in einem ersten Teil 160b ebenfalls ein Betriebssystem mit einer darauf ablaufenden Synchronisationssoftware geladen. Die Synchronisationssoftware nimmt die von dem ersten Rechnerknoten 110a übertragenen Daten entgegen und synchronisiert diese mit den auf dem ersten bzw. zweiten nichtflüchtigen Massenspeicher 120b bzw. 130b gespeicherten Daten. Des Weiteren kann eine zur Abfrage eingesetzte Datenbanksoftware in den ersten Teil 160b des Hauptspeichers 150b geladen sein.
  • Zum Austausch und Synchronisieren der Daten zwischen den Rechnerknoten 110a und 110b können aus dem Stand der Technik bekannte Protokolle und Softwarekomponenten zum Synchronisieren von Daten verwendet werden. Im Ausführungsbeispiel erfolgt die Synchronisation über das so genannte SCSI RDMA Protocol (SRP), über das der erste Rechnerknoten 110a Änderungen über ein Kernelmodul seines Betriebssystems in den Hauptspeicher des 150b des zweiten Rechnerknotens 110b überträgt. Eine weitere Softwarekomponente des zweiten Rechnerknotens 110b sorgt für das Schreiben der Änderungen in die nichtflüchtigen Massenspeicher 120b und 130b. Mit anderen Worten dient der erste Rechnerknoten 110a als Sychronisationsquelle- oder initiator und der zweite Rechnerknoten 110b als Synchronisationsziel oder -target.
  • In der beschriebenen Ausgestaltung werden Datenbankänderungen erst dann als erfolgreich abgeschlossen (englisch: committed) in den Logdaten markiert, wenn die zur Synchronisation eingesetzte Treibersoftware dann ein erfolgreiches Übertragen an entweder den Hauptspeicher 150b oder die nichtflüchtigen Speicher 120b bzw. 130b des entfernten Rechnerknoten 110b bestätigt hat. Komponenten des zweiten Rechnerknotens 110b, die für die Synchronisation der Daten nicht benötigt werden, wie zusätzliche Prozessoren, können gegebenenfalls abgeschaltet oder mit reduzierter Leistung betrieben werden, um dessen Energieaufnahme zu reduzieren.
  • Im Ausführungsbeispiel läuft auf dem zweiten Rechnerknoten 110b des Weiteren eine Überwachungssoftware ab, die den Betrieb des ersten, aktiven Rechnerknotens 110a fortwährend überwacht. Fällt der erste Rechnerknoten 110a unerwartet aus, wie dies in der 1B dargestellt ist, können die zum weiteren Betrieb des Hauptspeicher-Datenbanksystems 100 erforderlichen Daten des Datenbanksegments aus dem ersten nichtflüchtigen Massenspeicher 120b und die zugehörigen Logdaten aus dem zweiten nichtflüchtigen Massenspeicher 130b in einen zweiten Teil 160b des Hauptspeichers 150b des zweiten Rechnerknotens 110b geladen werden, um eine konsistente Datenbank in dem Hauptspeicher 150b wiederherzustellen. Die dabei erzielbare Datenübertragungsrate liegt deutlich über einer Datenübertragungsrate, wie sie bei gängigen Netzwerkverbindungen erzielt werden kann. Beispielsweise lässt sich bei der Verwendung von mehreren parallel zueinander über eine PCIe-Schnittstelle angeschlossene, so genannte Solid State Discs (SSD) eine Datenübertragungsrate von derzeit 50 bis 100 GB/s erzielen. Ausgehend von einer wiederherzustellenden Datenmenge von ca. 10 TB ergibt sich damit eine Failover-Zeit von etwa 100 bis 200 Sekunden. Diese Zeit kann weiter reduziert werden, wenn die Daten nicht nur in den Massenspeichern 120b und 130b aktuell gehalten werden, sondern ganz oder teilweise bereits im passiven Betrieb in dem zweiten Teil 170b des Hauptspeichers 150b des zweiten Rechnerknotens 110b geladen und/oder mit dem zweiten Teil 170a des Hauptspeichers 150a synchronisiert werden. Die Datenbanksoftware des zweiten Rechenknotens 110b übernimmt dann die Ausführung von eingehenden Abfragen.
  • Sobald der erste Rechnerknoten 110a wieder zur Verfügung steht, beispielsweise nach einem Neustart des ersten Rechnerknotens 110a, übernimmt dieser die Rolle des passiven Ersatzknotens. Dies ist in der 1C dargestellt. Nachfolgend übernimmt der erste Rechnerknoten 110a die zwischenzeitlich von dem zweiten Rechnerknoten 110b verursachten Daten- und Logänderungen, sodass bei Ausfall des zweiten Rechnerknotens 110b erneut ein redundanter Rechnerknoten 110a zur Verfügung steht.
  • In der 2 ist ein Betriebsverfahren zum Betrieb des Hauptspeicher-Datenbanksystems 100 dargestellt. Die von dem ersten Rechnerknoten 110a ausgeführten Schritte sind links, die von dem zweiten Rechnerknoten 110b ausgeführten Schritte sind rechts dargestellt. Dabei sind die Verfahrensschritte des jeweils aktiven Rechnerknotens 110 fett hervorgehoben.
  • In einem ersten Schritt 205 lädt der erste Rechnerknoten 110 die zum Betrieb erforderlichen Programme und Daten. Beispielsweise wird ein Betriebssystem, eine darauf ablaufende Datenbanksoftware sowie die eigentlichen Daten der Datenbank aus dem ersten nichtflüchtigen Massenspeicher 120a geladen. Parallel dazu lädt der zweite Rechnerknoten in Schritt 210 ebenfalls die zum Betrieb erforderlichen Programme und gegebenenfalls zugehörige Daten. Beispielsweise lädt der Rechnerknoten 110b zunächst nur das Betriebssystem sowie darauf ablaufende Überwachungs- und Synchronisationssoftware in den ersten Teil 160b des Hauptspeichers 150b. Optional kann auch die Datenbank selbst aus dem Massenspeicher 120b in den zweiten Teil 170b des Arbeitsspeichers des zweiten Rechnerknotens 110b geladen werden. Das Hauptspeicher-Datenbanksystem ist nun betriebsbereit.
  • Nachfolgend führt der erste Rechnerknoten 110a in Schritt 215 eine erste Datenbankänderung an den geladenen Daten durch. Parallel dazu überwacht der zweite Rechnerknoten 110b fortlaufend den Betrieb des ersten Rechnerknotens 110b in Schritt 220. Bei der Ausführung der ersten Abfrage anfallende Datenänderungen werden in den nachfolgenden Schritten 225 und 230 von dem ersten Rechnerknoten 110a auf den zweiten Rechnerknoten 110b übertragen und jeweils in den lokalen nichtflüchtigen Massenspeichern 120a und 120b bzw. 120b und 130b abgelegt. Alternativ oder zusätzlich ist auch ein Abgleich der entsprechenden Hauptspeicherinhalte möglich. Die Schritte 215 bis 230 werden solange ausgeführt, wie der erste Rechnerknoten 110a normal läuft.
  • Fällt in einem nachfolgenden Schritt 235 der erste Rechnerknoten 110a aus, wird dies im Schritt 240 durch den zweiten Rechnerknoten 110b erkannt. Je nachdem, ob die Datenbank bereits im Schritt 210 geladen wurde oder nicht, lädt der zweite Rechnerknoten nun die abzufragende Datenbank aus seinem lokalen nichtflüchtigen Massenspeicher 120b und führt gegebenenfalls noch nicht abgeschlossene Transaktionen gemäß dem Transaktionsdaten des Massenspeichers 130b durch. Daraufhin übernimmt der zweite Rechnerknoten in Schritt 250 die Beantwortung weiterer Abfragen, beispielsweise einer zweiten Datenbankänderung. Parallel dazu wird der erste Rechnerknoten 110a in Schritt 245 neu gestartet.
  • Nach erfolgreichem Neustart werden die durch den zweiten Rechnerknoten 110b sowie der darauf ablaufenden Abfragen vorgenommen Datenbankänderungen in den Schritten 255 und 260 wie oben beschrieben jedoch in der umgekehrten Datenflussrichtung miteinander synchronisiert. Zusätzlich übernimmt der erste Rechnerknoten 110a in Schritt 265 die Überwachung des zweiten Rechnerknotens 110b. Der zweite Rechnerknoten bleibt nun solange zur Ausführung weitere Abfragen, beispielsweise einer dritten Änderung in Schritt 270, aktiv, bis erneut ein Knotenausfall erkannt wird und sich das Verfahren in umgekehrter Richtung wiederholt.
  • Wie in der 2 dargestellt, befindet sich das Hauptspeicher-Datenbanksystem 100 in einer ersten Phase 280 und einer dritten Phase 290 in einem hochverfügbaren Betriebszustand, in dem der Ausfall eines beliebigen Rechnerknotens 110 keine Datenverluste nach sich zieht. Lediglich in einer vorübergehenden zweiten Phase 285 befindet sich das Hauptspeicher-Datenbanksystem 100 in einem nicht-hochverfügbaren Betriebszustand.
  • In den 3A bis 3D sind unterschiedliche Zustände eines Hauptspeicher-Datenbanksystems 300 in einer so genannten n + 1-Konfiguration gemäß einem weiteren Ausführungsbeispiel dargestellt. Der Betrieb des Hauptspeicher-Datenbanksystems 300 gemäß den 3A bis 3D wird anhand des Ablaufdiagramms gemäß 4 erläutert.
  • In der 3A ist die Grundkonfiguration des Hauptspeicher-Datenbanksystems 300 dargestellt. Im normalen Betriebszustand umfasst das Hauptspeicher-Datenbanksystem 300 acht aktive Rechnerknoten 310a bis 310h sowie einen passiven Rechnerknoten 310i, der als redundanter Rechnerknoten für das Hauptspeicher-Datenbanksystem 300 zur Verfügung steht. Sämtliche Rechnerknoten 310a bis 310i sind über serielle Hochgeschwindigkeitsleitungen 320 und zwei zueinander redundanten Switching-Vorrichtungen 330a und 330b miteinander verbunden.
  • In dem in 3A dargestellten Normalbetriebszustand dient jeder der aktiven Knoten 310a bis 310h zur Abfrage eines von insgesamt acht Datenbanksegmenten. Diese sind jeweils in einen ersten Speicherbereich 340a bis 340h der aktiven Rechnerknoten 310a bis 310h geladen. Wie sich aus der 3A ergibt, füllen die entsprechenden Datenbanksegmente den jeweils zur Verfügung stehenden Speicherbereich eines jeden Rechnerknotens 310 nur etwa zur Hälfte aus. Bei einer aktuell üblichen Rechnerarchitektur kann es sich bei den dargestellten Speicherbereichen um Speicherbereiche eines sekundären, nichtflüchtigen, lokalen Massenspeichers, beispielsweise eines SSD-Speicherlaufwerks oder eines DIMM-SSD-Speichermoduls, handeln. In diesem Fall werden zumindest die Daten des dem jeweiligen Rechnerknoten zugeordneten Datenbanksegments für die Abfrage durch die Datenbanksoftware zusätzlich in einem primären, flüchtigen Hauptspeicher, in der Regel gebildet durch DRAM-Speichermodule, vorgehalten. Alternativ ist aber auch die Speicherung in einem nichtflüchtigen Arbeitsspeicher vorstellbar, beispielsweise batteriegepufferten DRAM-Speichermodulen oder neuartige NVRAM-Speichermodule. In diesem Fall kann eine Abfrage und Aktualisierung der Daten direkt aus bzw. in dem nichtflüchtigen Speicher erfolgen.
  • In einem zweiten Speicherbereich 350a bis 350h eines jeden aktiven Rechnerknotens 310a bis 310h sind jeweils unterschiedliche Teile der Daten der Datenbanksegmente der jeweils anderen aktiven Rechnerknoten 310 gespeichert. Im in 3A dargestellten Zustand umfasst der erste Rechnerknoten 310a beispielsweise jeweils ein Siebtel der Datenbanksegmente der verbleibenden aktiven Rechnerknoten 310b bis 310h. Die verbleibenden aktiven Rechnerknoten sind in äquivalenter Weise konfiguriert, sodass ein jedes Datenbanksegment einmal vollständig in einem aktiven Rechnerknoten 310 und redundant verteilt über die verbleibenden sieben Rechnerknoten 310 gespeichert ist. Bei symmetrischer Aufteilung einer Konfiguration mit n aktiven Rechnerknoten 310 im Allgemeinen ist jeweils ein Teil im Umfang von 1/(n – 1) eines jedes anderen Datenbanksegments in jedem Rechnerknoten 310 gespeichert. Nachfolgend wird anhand des Ablaufdiagramms gemäß 4 als Beispiel der Ausfall und anschließende Ersatz des Rechnerknotens 310c beschrieben. Die darin dargestellten Verfahrensschritte werden im beschriebenen Beispiel durch den redundanten Rechnerknoten 310i ausgeführt.
  • In einem ersten Schritt 410 wird das Auftreten eines Knotenausfalls in dem aktiven Knoten 310c erkannt. Beispielsweise läuft auf dem redundanten Rechnerknoten 310i oder einer externen Überwachungskomponente eine Überwachungssoftware, die den ordnungsgemäßen Betrieb der aktiven Knoten 310a bis 310h überwacht. Sobald der Knotenausfall erkannt wurde, werden die redundant gespeicherten Teile des dem Rechnerknoten 310c zugeordneten Datenbanksegments aus den verschiedenen verbleibenden aktiven Rechnerknoten 310a und 310b sowie 310d bis 310h in den Schritten 420 bis 428 in den ersten Speicherbereich 340i des redundanten Rechnerknotens 310i übertragen und dort gesammelt. Dies ist in der 3B dargestellt.
  • Im Ausführungsbeispiel erfolgt das Laden aus jeweils lokalen nichtflüchtigen Speichervorrichtungen, insbesondere so genannten SSD-Laufwerken, der einzelnen Rechnerknoten 310a, 310b sowie 310d bis 310h. Die aus der internen Speichervorrichtung geladenen Daten werden über die seriellen Hochgeschwindigkeitsleitungen 320 und die Switching-Vorrichtung 330, im Ausführungsbeispiel redundante Vierkanal-InfiniBand-Verbindungen und zugehörige InfiniBand-Switches, an den redundanten Rechnerknoten 310i übertragen und in dessen lokalen nichtflüchtigen Speicher abgelegt und in den Hauptspeicher geladen. Wie in der 3B dargestellt, ergibt sich durch die voneinander unabhängige Übertragung der einzelnen Teile des wiederherzustellenden Datenbanksegments ein hoher Grad an Parallelität, sodass eine um die Anzahl der parallelen Knoten oder Kanäle höhere Datenübertragungsrate als bei dem Abruf des entsprechenden Datenbanksegments aus einem einzelnen Rechnerknoten 310 oder einer zentralen Speichervorrichtung erreicht werden kann. Bevorzugt wird hierzu, wie später beschrieben, eine asymmetrische Verbindungstopologie eingesetzt.
  • Ist das entsprechende Datenbanksegment des Hauptspeicher-Datenbanksystems 300 erfolgreich in dem zuvor redundanten Rechnerknoten 310i wiederhergestellt, übernimmt dieser die Funktion des Rechnerknotens 310c und wird zu einem aktiven Rechnerknoten 310. Dies ist in 3C durch Vertauschen der entsprechenden Bezeichnungen "Node 2" und "Node 8" dargestellt. Hierzu wird das wiederhergestellte Datenbanksegment gegebenenfalls aus dem lokalen nichtflüchtigen Speicher in einen flüchtigen Arbeitsspeicher des Rechnerknotens 310i geladen. Bereits in diesem Zustand können weitere Datenbankabfragen und/oder -änderungen in einem Schritt 430 erfolgreich durch das Hauptspeicher-Datenbanksystem 300 bearbeitet werden.
  • In den nachfolgenden Schritten 440 bis 448 wird zusätzlich die Redundanz der gespeicherten Daten wiederhergestellt. Dies ist in 3D dargestellt. Zu diesem Zweck überträgt jeder der anderen aktiven Rechnerknoten 310a, 310b sowie 310d bis 310h jeweils einen Teil seines Datenbanksegments an den Rechnerknoten 310i, der die Aufgaben des ausgefallenen Rechnerknotens 310c übernommen hat und die übertragenen Kopien in einem zweiten Speicherbereich 350i eines lokalen nichtflüchtigen Speichers ablegt. Im Ergebnis wird somit der Inhalt des zweiten Speicherbereichs 350c zuzüglich zwischenzeitlich erfolgter Änderungen in dem zweiten Speicherbereich 350i wiederhergestellt. Auch das Wiederherstellen der redundanten Datenspeicherung der anderen Datenbanksegmente kann mit einem hohen Grad an Parallelität von verschiedenen, jeweils lokalen Massenspeichern verschiedener Netzwerkknoten 310 vorgenommen werden, sodass bereits kurze Zeit nach dem Ausfall des Rechnerknotens 310c die Redundanz der gespeicherten Daten wieder hergestellt ist. Das Hauptspeicher-Datenbanksystem 300 befindet sich dann wieder in einer hochverfügbaren Betriebsart, wie vor dem Knotenausfall im Schritt 410.
  • Nach Abschluss des Verfahrens 400 kann der ausgefallene Rechnerknoten 310c neu gestartet oder anderweitig wieder in einen funktionsfähigen Betriebszustand gebracht werden. Der Rechnerknoten 310c wird wieder in das Hauptspeicher-Datenbanksystem 300 integriert und übernimmt nachfolgend die Funktion eines redundanten Rechnerknotens 310 mit der Bezeichnung "Node 8".
  • Im Falle der in den 3A bis 3D dargestellten Rechnerkonfiguration mit einem dedizierten redundanten Rechnerknoten 310i kann die Datenübertragungsrate und damit die so genannte Failover-Zeit verbessert werden, wenn die Verbindungen über die Hochgeschwindigkeitsleitungen 320 asymmetrisch ausgestaltet sind. Beispielsweise ist es möglich, zwischen den Switching-Vorrichtungen 330 und dem ausgezeichneten, redundanten Rechnerknoten 310i eine höhere Datenübertragungsbandbreite vorzusehen als zwischen den Switching-Vorrichtungen 330 und den üblicherweise aktiven Knoten 310a bis 310h. Dies kann beispielsweise durch einen höheren Grad von zueinander parallel geschalteten Verbindungsleitungen erreicht werden.
  • Optional ist es möglich, nach einem Neustart des ausgefallenen Knotens 310c den Inhalt des redundanten Rechnerknotens 310i vorausschauend zurück auf den neu gestarteten Rechnerknoten 310c zu übertragen. Beispielsweise kann eine Rückübertragung in einem Betriebszustand mit niedriger Arbeitsauslastung erfolgen, in dem alle Rechnerknoten 310 voll einsatzbereit sind. Dies ist insbesondere bei der oben beschriebenen Ausgestaltung mit dediziertem redundanten Rechnerknoten 310i von Vorteil, um auch beim nächsten Knotenausfall auf die höhere Datenübertragungsbandbreite des asymmetrischen Verbindungsstruktur zurückgreifen zu können.
  • Anhand der 5A bis 5F sowie des Ablaufdiagramms gemäß 6 wird nachfolgend ein weiteres Hauptspeicher-Datenbanksystem 500 mit acht Rechnerknoten 510 beschrieben. Aus Gründen der Übersichtlichkeit sind in der 6 nur die Schritte von zwei Rechnerknoten 510c und 510d dargestellt.
  • Das Hauptspeicher-Datenbanksystem 500 gemäß den 5A bis 5F unterscheidet sich von den zuvor beschriebenen Hauptspeicher-Datenbanksystemen 100 und 300 unter anderem dadurch, dass die einzelnen Datenbanksegmente und die zu ihrer Abfrage verwendeten Datenbanksoftware weitere Untergliederungen der einzelnen Datenbanksegmente zulassen. Beispielsweise können die Datenbanksegmente in kleinere Datenbankteile oder Container aufgeteilt werden, wobei alle zugehörigen Daten, insbesondere Log- und Transaktionsdaten, jeweils für einen Datenbankteil bzw. Container isoliert und unabhängig voneinander verarbeitet werden können. Auf diese Weise ist es möglich, einzelne Datenbankteile oder Container eines Datenbanksegments unabhängig von den verbleibenden Datenbankteilen oder Containern desselben Datenbanksegments abzufragen, zu ändern und/oder zu restaurieren.
  • Gegenüber dem Hauptspeicher-Datenbanksystem 300 gemäß den 3A bis 3D unterscheidet sich das Hauptspeicher-Datenbanksystem 500 gemäß den 5A bis 5E zudem dadurch, dass kein zusätzlicher, dedizierter Rechnerknoten zur Herstellung der Redundanz vorgesehen ist. Statt dessen trägt in dem Datenbanksystem 500 gemäß den 5A bis 5E jeder der aktiven Rechnerknoten 510 einen Teil zur Herstellung der Redundanz des Hauptspeicher-Datenbanksystems 500 bei. Dies ermöglicht unter anderem die Verwendung einfacher, symmetrischer Systemarchitekturen und vermeidet den Einsatz asymmetrische Verbindungsstrukturen.
  • Wie in 5A dargestellt, umfasst das Hauptspeicher-Datenbanksystem 500 insgesamt acht Rechnerknoten 510a bis 510h, die in 5A mit den Bezeichnungen "Node 0" bis "Node 7" bezeichnet sind. Die einzelnen Rechnerknoten 510a bis 510h sind über Netzwerkleitungen 520 und Netzwerk-Switches 530 miteinander verbunden. Im Ausführungsbeispiel dienen dafür je Rechnerknoten 510 jeweils zwei zueinander redundante 10-Gbit-Ethernet-Netzwerkleitungen, die mit jeweils einem Acht-Port 10-Gbit Ethernet-Switch verbunden sind. Jeder der Rechnerknoten 510a bis 510h weist einen ersten Speicherbereich 540a bis 540h sowie einen zweiten Speicherbereich 550a bis 550h auf, die in einem nichtflüchtigen Speicher des jeweiligen Rechnerknotens 510a bis 510h gespeichert sind. Im Ausführungsbeispiel kann es sich dabei beispielsweise um Speicherbereiche eines lokalen nichtflüchtigen Halbleiterspeichers, beispielsweise einer SSD oder eines nichtflüchtigen Hauptspeichers, handeln.
  • Die Datenbank des Hauptspeicher-Datenbanksystems 500 ist in der in 5A dargestellten Konfiguration erneut auf acht Datenbanksegmente aufgeteilt, die in den ersten Speicherbereichen 540a bis 540h gespeichert sind und von den acht Rechnerknoten 510a bis 510h unabhängig voneinander abgefragt und aktiv geändert werden können. Die aktiv abfragbaren Speicherbereiche sind in den 5A bis 5E jeweils dreidimensional hervorgehoben. In den zweiten Speicherbereichen 550a bis 550h eines jeden Rechnerknotens 510a bis 510h ist jeweils ein Siebtel eines Datenbanksegments eines der anderen Rechnerknoten 510 als passive Kopie gespeichert. Die Speicherstruktur des zweiten Speicherbereichs 550 entspricht dabei im Wesentlichen der bereits bezüglich der 3A bis 3D beschriebenen Speicherstruktur der zweiten Speicherbereiche 350.
  • Im in der 5B dargestellten Zustand fällt der Rechnerknoten 510c mit der Bezeichnung "Node 2" aus. Dies ist im zugehörigen Ablaufdiagramm gemäß 6 als Schritt 605 dargestellt. Dieser Ausfall wird durch einen, mehrere oder alle der verbleibenden aktiven Rechnerknoten 510a und 510b sowie 510d bis 510h oder eine externe Überwachungskomponente, beispielsweise in Form eines Schedulers des Hauptspeicher-Datenbanksystem 500, in Schritt 610 erkannt. Zur Behebung des Fehlerzustands wird in Schritt 615 der ausgefallene Rechnerknoten 510c neu gestartet. Parallel dazu übernehmen die verbleibenden aktiven Rechnerknoten neben der Beantwortung von Anfragen betreffend ihres eigenen Datenbanksegments (Schritt 620) jeweils einen Teil der Abfragelast bezüglich des Datenbanksegments des ausgefallenen Rechnerknotens 510c (Schritt 625). Neben der Bearbeitung seiner eigenen Abfragen des Segments des "Node 3" in Schritt 620 übernimmt der aktive Rechnerknoten 510d somit eine Abfrage des lokal in den Speicherbereich 550d gespeicherten Teil des Datenbanksegments des "Node 2". In 5B ist dies bildlich durch Hervorhebung der entsprechend redundant im zweiten Speicherbereich 550 gespeicherten Teile des Datenbanksegments des ausgefallenen Knotens 510c dargestellt. Mit anderen Worten werden Teile der Speicherbereiche mit darin enthaltenen zuvor passiven Datenbankteilen in abfragbare Speicherbereiche bzw. aktive Datenbankteile überführt. Beispielsweise kann einer zur Abfrage eingesetzten Datenbanksoftware mitgeteilt werden, welche Speicherbereiche sie aktiv als Master kontrolliert bzw. passiv als Slave gemäß Änderungen eines anderen Masters nachführt.
  • Nach Abschluss des Neustarts des ausgefallenen Rechnerknotens 510c lädt dieser im Schritte 630 Teile des ihm zugeordneten Datenbanksegments aus einem der nichtflüchtigen Speicher der anderen aktiven Rechnerknoten 510a, 510b sowie 510d bis 510h. Dabei kann beispielweise der gesamte Teil der Datenbank von dem anderen Rechnerknoten 510 geladen werden. Sobald das Laden und gegebenenfalls das Synchronisieren des Teils des Datenbanksegments abgeschlossen ist, übernimmt der neu gestartete Rechnerknoten 510c, gegebenenfalls nach Übertragen der Daten in den Hauptspeicher, auch die Bearbeitung der dem Datenbankteil zugehörigen Abfragen. Zu diesem Zweck wird der entsprechende Teil der Datenbank in dem zweiten Speicherbereich 550d deaktiviert und in dem ersten Speicherbereich 540c des Rechnerknoten 510c aktiviert. Die Schritte 630 und 635 werden parallel oder sukzessiv für alle Datenbankteile in den Rechnerknoten 510a, 510b sowie 510d bis 510h wiederholt. In der in der 5C dargestellten Situation wurde die erste sechs Teile des dem Rechnerknoten 510c zugeordneten Datenbanksegments bereits wieder aus den Rechnerknoten 510b, 510a, 510h, 510g, 510f und 510e wiederhergestellt. In der 5C ist die Durchführung der Schritte 630 und 635 für die Wiederherstellung des letzen Teils des Datenbanksegments des Rechnerknotens 510c dargestellt, das auf dem Rechnerknoten 510d redundant gespeichert ist.
  • Danach befindet sich das Hauptspeicher-Datenbanksystem 500 im in 5D dargestellten Zustand, in dem jeder Rechnerknoten 510a bis 510h jeweils sein eigenes Datenbanksegment in seinem ersten Speicherbereich 340a bis 340h enthält und dieses aktiv abfragt. In diesem Zustand können Änderungen an das Hauptspeicher-Datenbanksystem 50 wie gewohnt durch parallele Abfrage der den jeweiligen Rechnerknoten 510a bis 510h zugeordneten Datenbanksegmenten in den Schritten 640 sowie 645 abgefragt werden. Gegenüber der Ausgangssituation gemäß 5A unterscheidet sich der Zustand gemäß 5D noch dadurch, dass in dem zweiten Speicherbereich 550c des zuvor ausgefallenen Rechnerknotens 510c keine aktuellen Daten der verbleibenden Rechnerknoten 510a, 510b sowie 510d bis 510h enthalten sind. Somit sind die Datenbanksegmente der Rechnerknoten 510a, 510b sowie 510d bis 510h in diesem Zustand nicht vollumfänglich vor Knotenausfällen geschützt and das Hauptspeicher-Datenbanksystem 500 insgesamt befindet sich nicht in einer hochverfügbaren Betriebsart.
  • Zur Wiederherstellung der Redundanz des Datenbanksystems 500 werden in den Schritten 650 und 655, wie oben bezüglich der Schritte 630 und 635 beschrieben, jeweils ein Teil des Datenbanksegments eines anderen Rechnerknotens 510a, 510b, 510d bis 510h in dem zweiten Speicherbereich 550c des Rechnerknotens 510c wiederhergestellt. Dies ist in 5E beispielhaft für das Kopieren eines Teils des Datenbanksegments des Knotens 510d in den zweiten Speicherbereich 550c des Rechnerknotens 510c dargestellt. Auch die Schritte 630 und 635 werden parallel oder sukzessiv für alle Rechnerknoten 510a, 510b sowie 510d bis 510h wiederholt.
  • Wurden die Schritte 650 und 655 für jeden der Rechnerknoten 510a, 510b sowie 510d bis 510h durchgeführt, befindet sich das Hauptspeicher-Datenbanksystem 500 wieder im hochverfügbaren Grundzustand gemäß 5. In diesem Zustand überwachen sich die einzelnen Rechnerknoten 510a bis 510h gegenseitig auf einen Ausfall, wie dies beispielhaft in den Schritten 660 und 665 für die Rechnerknoten 510c und 510d dargestellt ist.
  • Die in den 5A bis 5E dargestellte Konfiguration des Hauptspeicher-Datenbanksystems 500 weist unter anderem den Vorteil auf, dass kein zusätzlicher Rechnerknoten zur Herstellung der Redundanz benötigt wird. Zur Sicherstellung der beschriebenen Verkürzung der Failover-Zeit ist es vorteilhaft, wenn einzelne Teile eines Datenbanksegments eines ausgefallenen Rechnerknotens 510c unabhängig voneinander durch verschiedene Rechnerknoten 510a, 510b sowie 510d bis 510h abgefragt werden können. Die Größe der einzeln abfragbaren Teile oder Container kann dabei beispielsweise der Größe eines einem Prozessorkern eines Multiprozessor-Rechenknotens zugeordneten lokalen Speicher entsprechen (so genannte "ccNUMA Awareness"). Da in der Übergangszeit, wie sie beispielsweise in den 5B und 5C dargestellt ist, Abfragen betreffend das Datenbanksegment des ausgefallenen Rechnerknotens 510c weiter, wenn auch mit geringfügig verminderter Performance, beantwortet werden können, kann der Kommunikationsaufwand bis zur Wiederherstellung der Abfragefähigkeit erheblich reduziert werden. Als eine Folge kann die Verbindungsstruktur, umfassend die Netzwerkverbindungen 520 und die Netzwerk-Switches 530, mit vergleichsweise günstigen Hardware-Komponenten implementiert werden, ohne dass es zu einer Erhöhung der Failover-Zeit kommt.
  • Basierend auf den 7A bis 7D wird nachfolgend eine Kombination der Techniken gemäß den 3A bis 6 gemäß einem weiteren Ausführungsbeispiel beschrieben.
  • 7A zeigt ein Hauptspeicher-Datenbanksystem 700 mit insgesamt neun Rechnerknoten 710 in einer so genannten 8 + 1-Konfiguration. Die Rechnerknoten 710a bis 710i besitzen eine Speicheraufteilung, die der Speicheraufteilung des Hauptspeicher-Datenbanksystems 300 gemäß 3A entspricht. Das heißt insbesondere, dass das Hauptspeicher-Datenbanksystem 700 acht aktive Rechnerknoten 710a bis 710h sowie einen redundanten Rechnerknoten 710i umfasst. In jedem der aktiven Rechnerknoten 710a bis 710h ist jeweils ein komplettes Datenbanksegment, das dem jeweiligen Rechnerknoten 710a bis 710h zugeordnet ist, in einem ersten Speicherbereich 740a bis 740h gespeichert, das von einer zugehörigen Datenbank-Software abgefragt werden kann. Darüber hinaus ist in einem zweiten Speicherbereich 750a bis 750h jeweils ein Siebtel eines Datenbanksegments jeweils eines der anderen aktiven Rechnerknoten 710 gespeichert. Die Rechnerknoten 710a bis 710i sind, wie unter Bezugnahme auf 5A beschrieben, durch eine Verbindungsstruktur, umfassend Netzwerkleitungen 720 und Netzwerk-Switches 730, miteinander verbunden. Im Ausführungsbeispiel handelt es sich hierbei wiederum um Verbindungen gemäß dem so genanntes 10-Gbit-Ethernet-Standard.
  • Das Verhalten des Hauptspeicher-Datenbanksystems 700 beim Ausfall eines Knotens, beispielsweise des Rechnerknotens 710c, entspricht im Wesentlichen einer Kombination des Verhaltens der zuvor beschriebenen Ausführungsbeispiele. Fällt, wie in der 7B dargestellt, der Rechnerknoten 710c aus, übernehmen zunächst in einer Übergangsphase die verbleibenden aktiven Knoten 710a, 710b sowie 710d bis 710h die Abfrage jeweils eines separat abfragbaren Teils eines dem ausgefallen Datenbank-Knoten 710c zugeordneten Datenbanksegments. Somit kann die Beantwortung von Abfragen an das Hauptspeicher-Datenbanksystem 700 beim Ausfall des Rechnerknotens 710c ohne Unterbrechung fortgeführt werden.
  • Nachfolgend werden die einzelnen Teile, die zusammen das ausgefallene Datenbanksegment bilden, von den aktiven Knoten 710a, 710b, 710d bis 710h in den Speicherbereich 740i des redundanten Knotens 710i übertragen. Diese Situation ist in 7C dargestellt. Wie oben anhand des Verfahrens 600 gemäß 6 beschrieben, kann die Übertragung der einzelnen Teile des ausgefallenen Datenbanksegments sukzessiv erfolgen, ohne dass es zu einer Unterbrechung des Betriebs des Datenbanksystems 700 kommt. Daher kann die Übertragung über verhältnismäßig einfache, konventionelle Netzwerktechnologie wie beispielsweise 10-Gbit-Ethernet erfolgen. Um die Redundanz des Hauptspeicher-Datenbanksystems 700 wiederherzustellen, werden nachfolgend jeweils ein Teil des Datenbanksegments der verbleibenden aktiven Rechnerknoten 710a, 710b, 710d bis 710h wie in der 7D dargestellt in den zweiten Speicherbereich 750i des redundanten Rechnerknotens 710i übertragen.
  • Zudem kann der ausgefallene Rechnerknoten 710c parallel neu gestartet werden, sodass dieser Rechnerknoten nach Reintegration in das Hauptspeicher-Datenbanksystem 700 die Funktion des redundanten Rechnerknotens übernehmen kann. Dies ist ebenfalls in 7D dargestellt. Zusätzlich zu der Kombination der bezüglich der Ausführungsbeispiele gemäß den 3A bis 6 beschriebenen Vorteile weist das Hauptspeicher-Datenbanksystem 700 gemäß den 7A bis 7D den zusätzlichen Vorteil auf, dass selbst beim Ausfall von zwei Rechnerknoten 710 der Betrieb des Hauptspeicher-Datenbanksystems 700 insgesamt sichergestellt werden kann und beim dauerhaften Ausfall eines Rechnerknotens 710 nur eine kurzfristige Leistungseinbuße entsteht.
  • Die beschriebenen Betriebsverfahren und Architekturen der verschiedenen beschriebenen Hauptspeicher-Datenbanksysteme 100, 300, 500 und 700 ermöglichen wie beschrieben die Verkürzung der so genannten Failover-Zeit bei Ausfall eines einzelnen Rechnerknotens der jeweiligen Hauptspeicher-Datenbanksysteme. Dies wird zumindest teilweise dadurch erreicht, dass zur Speicherung der einem jeweiligen Rechnerknoten zugeordneten Datenbanksegmente ein knoteninterner, nichtflüchtiger Massenspeicher desselben Rechnerknotens oder eines lokalen Massenspeichers eines anderen Rechnerknotens desselben Clustersystems eingesetzt wird. Interne, nichtflüchtige Massenspeicher sind in der Regel über besonders hochleistungsfähige Bussysteme mit zugehörigen Datenverarbeitungskomponenten, insbesondere Prozessoren der jeweiligen Rechnerknoten, verbunden, sodass das Wiedereinspielen von Daten eines gegebenenfalls ausgefallenen Knotens mit einer höheren Bandbreite bewirkt werden kann, als dies beim Nachladen von einer externen Speichervorrichtung der Fall wäre.
  • Darüber hinaus bietet sich bei einigen der beschriebenen Ausgestaltungen der Vorteil, dass das Wiederherstellen von Daten aus einer Mehrzahl von Massenspeichervorrichtungen parallel durchgeführt werden kann, sodass die zur Verfügung stehende Bandbreite aufaddiert wird. Zusätzlich ermöglichen die beschriebenen Ausgestaltungen nicht nur bei einem Ausfall eines einzelnen Rechnerknotens eines Hauptspeicher-Datenbanksystems mit einer Mehrzahl von Rechnerknoten Vorteile, sondern ermöglichen auch das schnellere, ggf. parallele Erstladen der Datenbanksegmente eines Hauptspeicher-Datenbanksystems, beispielsweise nach dem ersten Booten bei einem kompletten Ausfall der gesamten Hauptspeicher-Datenbanksysteme.
  • In den beschriebenen Hauptspeicher-Datenbanksystemen 100, 300, 500 und 700 ist jeweils die gesamte Datenbank bzw. alle zugehörigen Datenbanksegmente redundant gespeichert, um eine Ausfallsicherheit der gesamten Datenbank zu erreichen. Es ist jedoch auch möglich, die hier beschriebenen Techniken nur auf einzelne, ausgewählte Datenbanksegmente anzuwenden, beispielsweise wenn nur die ausgewählten Datenbanksegmente für zeitkritische Abfragen herangezogen werden. Andere Datenbanksegmente können dann wie bisher auf konventionelle Weise, beispielsweise aus einem zentralen Netzwerkspeicher wiederhergestellt werden.
  • Bezugszeichenliste
    • 100
    Hauptspeicher-Datenbanksystem
    110
    Rechnerknoten
    120
    erster nichtflüchtiger Massenspeicher
    130
    zweiter nichtflüchtiger Massenspeicher
    140
    serielle Hochgeschwindigkeitsleitung
    150
    Hauptspeicher
    160
    erster Teil des Hauptspeichers
    170
    zweiter Teil des Hauptspeichers
    200
    Verfahren
    205–270
    Verfahrensschritte
    280
    erste Phase
    285
    zweite Phase
    290
    dritte Phase
    300
    Hauptspeicher-Datenbanksystem
    310
    Rechnerknoten
    320
    serielle Hochgeschwindigkeitsleitung
    330
    Switching-Vorrichtung
    340
    erster Speicherbereich
    350
    zweiter Speicherbereich
    400
    Verfahren
    410–448
    Verfahrensschritte
    500
    Hauptspeicher-Datenbanksystem
    510
    Rechnerknoten
    520
    Netzwerkleitung
    530
    Netzwerk-Switch
    540
    erster Speicherbereich
    550
    zweiter Speicherbereich
    600
    Verfahren
    605–665
    Verfahrensschritte
    700
    Hauptspeicher-Datenbanksystem
    710
    Rechnerknoten
    720
    Netzwerkleitung
    730
    Netzwerk-Switch
    740
    erster Speicherbereich
    750
    zweiter Speicherbereich
    800
    Hauptspeicher-Datenbanksystem
    810
    Rechnerknoten
    820
    Netzwerkspeicher
    830
    Datenverbindung
    840
    Synchronisationskomponente

Claims (18)

  1. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700), umfassend – eine Mehrzahl von Rechnerknoten (110, 310, 510, 710), umfassend wenigstens einen Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung einer Redundanz des Datenbanksystems; und – wenigstens eine Verbindungsstruktur zur datentechnischen Kopplung der Mehrzahl von Rechnerknoten (110, 310, 510, 710) untereinander; wobei – jeder der Rechnerknoten (110, 310, 510, 710) mindestens einen lokalen nichtflüchtigen Speicher zum Speichern eines dem jeweiligen Rechnerknoten (110, 310, 510, 710) zugeordneten Datenbanksegments, mindestens eine Datenverarbeitungskomponente zum Ausführen einer Datenbanksoftware zur Abfrage des dem Rechnerknoten (110, 310, 510, 710) zugeordneten Datenbanksegments und eine Synchronisationskomponente aufweist, die dazu eingerichtet ist, eine Kopie der Daten eines dem jeweiligen Rechnerknoten (110, 310, 510, 710) zugeordneten Datenbanksegments in wenigstens einem nichtflüchtigen Speicher wenigstens eines anderen Rechnerknotens (110b, 310d, 510d, 710d) redundant zu speichern; und – zumindest der wenigstens eine Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung der Redundanz dazu eingerichtet ist, beim Ausfall wenigstens eines der Mehrzahl von Rechnerknoten (110, 310, 510, 710) die Datenbanksoftware zur Abfrage wenigstens eines Teils des dem ausgefallenen Rechnerknoten (110a, 310c, 510c, 710c) zugeordneten Datenbanksegments, basierend auf einer Kopie der zugehörigen Daten in dem lokalen nichtflüchtigen Speicher auszuführen, um die Latenzzeit beim Ausfall des Rechnerknotens (110a, 310c, 510c, 710c) zu reduzieren.
  2. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach Anspruch 1, bei dem jeder Rechnerknoten (110, 310, 510, 710) wenigstens einen flüchtigen Hauptspeicher zum Speichern einer Arbeitskopie des zugehörigen Datenbanksegments und einen nichtflüchtigen Massenspeicher zum Speichern des dem Rechnerknoten (110, 310, 510, 710) zugehörigen Datenbanksegments und einer Kopie der Daten wenigstens eines Teils eines einem anderen Rechnerknoten (110, 310, 510, 710) zugeordneten Datenbanksegments aufweist, wobei der Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung der Redundanz dazu eingerichtet ist, beim Ausfall wenigstens eines der Mehrzahl von Rechnerknoten (110, 310, 510, 710) wenigstens einen Teil des dem ausgefallen Rechnerknoten (110a, 310c, 510c, 710c) zugeordneten Datenbanksegments aus einer Kopie in einem nichtflüchtigen Massenspeicher über ein lokales Bussystem in den flüchtigen Hauptspeicher zu laden.
  3. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach Anspruch 2, bei dem die wenigstens eine Datenverarbeitungskomponente eines jeden Rechnerknotens (110, 310, 510, 710) über wenigstens eine Direct Attached Storage, DAS, Verbindung, insbesondere gemäß einem Small Computer System Interface, SCSI, und/oder einem PCI Express, PCIe, Standard, insbesondere gemäß dem Serial Attached SCSI, SAS, dem SCSI over PCIe, SOP, Standard und/oder dem NVM Express, NVMe, mit dem nichtflüchtigen Massenspeicher des Rechnerknotens (110, 310, 510, 710) verbunden ist.
  4. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach Anspruch 2 oder 3, bei dem der nichtflüchtige Massenspeicher eine Halbleitermassenspeichervorrichtung, insbesondere ein SSD-Speicherlaufwerk, eine PCIe-SSD-Einsteckkarte oder ein DIMM-SSD-Speichermodul, umfasst.
  5. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach Anspruch 1, bei dem jeder Rechnerknoten (110, 310, 510, 710) wenigstens einen nichtflüchtigen Hauptspeicher mit einer Arbeitskopie wenigstens eines Teils des gesamten zugeordneten Datenbanksegments, insbesondere von Daten und zugehörigen Logdaten des gesamten zugeordneten Datenbanksegments der Datenbank, aufweist.
  6. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach einem der Ansprüche 1 bis 5, bei dem die Verbindungsstruktur wenigstens eine parallele Switching-Fabric zum Austauschen von Daten zwischen wenigstens einem ersten Rechnerknoten (110a, 310d, 510c, 710d) der Mehrzahl von Rechnerknoten und dem wenigstens einen Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung der Redundanz über eine Mehrzahl von zueinander parallelen Verbindungspfaden, insbesondere über eine Mehrzahl von PCI-Express, Datenleitungen aufweist.
  7. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach einem der Ansprüche 1 bis 6, bei dem wenigstens ein erster Rechnerknoten (110a, 310d, 510d, 710d) der Mehrzahl von Rechnerknoten und der wenigstens eine Rechnerknoten (110b, 310i, 510d, 710i) zur Herstellung der Redundanz über wenigstens eine oder mehrere serielle Hochgeschwindigkeitsleitungen (140, 320), insbesondere gemäß dem InfiniBand-Standard, miteinander verbunden ist.
  8. Hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700) nach einem der Ansprüche 1 bis 7, bei dem wenigstens ein erster Rechnerknoten (110a, 310c, 510c, 710c) und wenigstens ein zweiter Rechnerknoten (110b, 310d, 510d, 710d) über die Verbindungsstruktur derart miteinander gekoppelt sind, dass der erste Rechnerknoten (110a, 310c, 510c, 710c) gemäß einem Remote Direct Memory Access, RDMA, insbesondere gemäß dem RDMA over converged Ethernet oder dem SCSI RDMA Protokoll direkt auf den Inhalt eines Arbeitsspeichers des wenigstens einen zweiten Rechnerknotens (110b, 310d, 510d, 710d) zugreifen kann.
  9. Hochverfügbares Hauptspeicher-Datenbanksystem (100) nach einem der Ansprüche 1 bis 8, bei dem die Mehrzahl von Rechnerknoten (110) einen ersten Rechnerknoten (110a) und einen zweiten Rechnerknoten (110b) umfasst, eine gesamte Datenbank dem ersten Rechnerknoten (110a) zugeordnet und in dem nichtflüchtigen lokalen Speicher des ersten Rechnerknotens (110a) gespeichert ist, eine Kopie der gesamten Datenbank in dem nichtflüchtigen lokalen Speicher des zweiten Rechnerknotens (110b) redundant gespeichert ist, wobei in einem normalen Betriebszustand die Datenbanksoftware des ersten Rechnerknotens (110a) Anfragen an die Datenbank beantwortet, durch die Anfragen verursachte Datenbankänderungen mit der in dem nichtflüchtigen Speicher des zweiten Rechnerknotens (110b) gespeicherten Kopie der Datenbank synchronisiert werden und die Datenbanksoftware des zweiten Rechnerknotens (110b) zumindest bei einem Ausfall des ersten Rechnerknotens (110a) Anfragen an die Datenbank beantwortet.
  10. Hochverfügbares Hauptspeicher-Datenbanksystem (300, 500, 700) nach einem der Ansprüche 1 bis 8, bei dem die Mehrzahl von Rechnerknoten (310, 510, 710) eine erste Anzahl n, n > 1, von aktiven Rechnerknoten (310, 510, 710) umfasst und jeder der aktiven Rechnerknoten (310, 510, 710) dazu eingerichtet ist, ein anderes von insgesamt n voneinander unabhängig abfragbarer Datenbanksegmente sowie wenigstens eine Kopie der Daten wenigstens eines Teils eines einem anderen Rechnerknoten (310, 510, 710) zugeordneten Datenbanksegments in seinem nichtflüchtigen lokalen Speicher zu speichern.
  11. Hochverfügbares Hauptspeicher-Datenbanksystem (300, 700) nach Anspruch 10, bei dem die Mehrzahl von Rechnerknoten (310, 710) zusätzlich eine zweite Anzahl m, m > 1, von passive Rechnerknoten (310i, 710i) zur Herstellung der Redundanz umfasst, denen in einem normalen Betriebszustand kein Datenbanksegment zugeordnet ist.
  12. Hochverfügbares Hauptspeicher-Datenbanksystem (300, 700) nach Anspruch 11, bei dem der wenigstens eine passive Rechnerknoten (310i, 710i) dazu eingerichtet ist, bei einem Ausfall eines aktiven Rechnerknotens (310c, 710c), das dem ausgefallen Rechnerknoten (310c, 710c) zugeordnete Datenbanksegment in dem lokalen nichtflüchtigen Speicher des wenigstens einen passiven Rechnerknotens (310i, 710i) basierend auf Kopien der Daten des Datenbanksegments in den nichtflüchtigen lokalen Speichern der verbleibenden aktiven Rechnerknoten (310, 710) wiederherzustellen und Abfragen betreffend des dem ausgefallenen Rechnerknotens (310c, 710c) zugeordneten Datenbanksegments basierend auf dem wiederhergestellten Datenbanksegment zu beantworten.
  13. Hochverfügbares Hauptspeicher-Datenbanksystem (500, 700) nach einem der Ansprüche 10 bis 12, bei dem jeder der aktiven Rechnerknoten (510, 710) dazu eingerichtet ist, bei einem Ausfall eines anderen aktiven Rechnerknotens (510c, 710c), zusätzlich zu Anfragen betreffend des dem jeweiligen Rechnerknoten (510, 710) zugeordneten Datenbanksegments wenigstens einen Teil von Anfragen betreffend das dem ausgefallenen Rechnerknoten (510c, 710c) zugeordnete Datenbanksegment basierend auf der in dem lokalen Speicher des jeweiligen Rechnerknotens (510, 710) gespeicherten Kopie der Daten des dem ausgefallenen Rechnerknoten (510c, 710c) zugeordneten Datenbanksegments zu beantworten.
  14. Arbeitsverfahren (200, 400, 600) für ein hochverfügbares Hauptspeicher-Datenbanksystem (100, 300, 500, 700), insbesondere nach einem der Ansprüche 1 bis 13, mit einer Mehrzahl von Rechnerknoten (110, 310, 510, 710) mit den folgenden Schritten: – Speichern wenigstens eines ersten Datenbanksegments in einem nichtflüchtigen, lokalen Speicher eines ersten Rechnerknotens (110a, 310c, 510c, 710c); – Speichern einer Kopie des wenigstens einen ersten Datenbanksegments in wenigstens einem nichtflüchtigen lokalen Speicher wenigstens eines zweiten Rechnerknotens (110b, 310d, 510d, 710d); – Ausführen von Datenbankabfragen bezüglich des ersten Datenbanksegments durch den ersten Rechnerknoten (110a, 310c, 510c, 710c); – Speichern von Datenbankänderungen bezüglich des ersten Datenbanksegments in dem nichtflüchtigen lokalen Speicher des ersten Rechnerknotens (110a, 310c, 510c, 710c); – Speichern einer Kopie der Datenbankänderungen bezüglich des ersten Datenbanksegments in dem nichtflüchtigen lokalen Speicher des wenigstens einen zweiten Rechnerknotens (110b, 310d, 510d, 710d); und – Ausführen von Datenbankabfragen bezüglich des ersten Datenbanksegments durch einen redundanten Rechnerknoten (110b, 310i, 510d, 710i) basierend auf der gespeicherten Kopie des ersten Datenbanksegments und/oder der gespeicherten Kopie der Datenbankänderungen, falls der erste Rechnerknoten (110a, 310c, 510c, 710c) ausfällt.
  15. Arbeitsverfahren (200, 400, 600) nach Anspruch 14, mit dem zusätzlichen Schritt: – Wiederherstellen des ersten Datenbanksegments in einem nichtflüchtigen lokalen Speicher des redundanten und/oder des ausgefallenen Rechnerknotens (110b, 310i, 510c, 710i) basierend auf der in dem wenigstens einen nichtflüchtigen Speicher des wenigstens einen zweiten Rechnerknotens (110b, 310d, 510d, 710d) gespeicherten Kopie des ersten Datenbanksegments und/oder der Kopie der Datenbankänderungen des ersten Datenbanksegments.
  16. Arbeitsverfahren (400, 600) nach Anspruch 14 oder 15 mit dem zusätzlichen Schritt: – Kopieren wenigstens eines Teils wenigstens eines anderen Datenbanksegments, der in dem ausgefallen Rechnerknoten (310c, 510c, 710c) redundant gespeichert war, von wenigstens einem dritten Rechnerknoten (310e, 510e, 710e) in den nichtflüchtigen Speicher des redundanten und/oder ausgefallenen Rechnerknotens (310i, 510c, 710i), um eine Redundanz des anderen Datenbanksegments wiederherzustellen.
  17. Verwendung eines hochverfügbaren Hauptspeicher-Datenbanksystems (100, 300, 500, 700) nach einem der Ansprüche 1 bis 13 und/oder eines Arbeitsverfahrens nach Anspruch 14 oder 16 in einer Datenbankvorrichtung, insbesondere einer Online Analytical Processing oder einer Online Transaction Processing Datenbank-Appliance.
  18. Verwendung eines nichtflüchtigen Massenspeichers eines Rechnerknotens (110, 310, 510, 710) eines Hauptspeicher-Datenbanksystems (100, 300, 500, 700) zum Wiederherstellen eines abzufragenden Datenbanksegments in einem Hauptspeicher (150) des Rechnerknotens (110, 310, 510, 710) über ein knoteninternes Bussystem, um die Latenzzeit, insbesondere beim Ausfall eines anderen Rechnerknotens (110a, 310c, 510c, 710c) des Hauptspeicher-Datenbanksystems (100, 300, 500, 700), gegenüber einem Abruf des wiederherzustellenden Datenbanksegments aus einem zentralen Speicherserver zu reduzieren.
DE102013101863.7A 2013-02-26 2013-02-26 Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen Withdrawn DE102013101863A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102013101863.7A DE102013101863A1 (de) 2013-02-26 2013-02-26 Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen
US14/190,409 US20140244578A1 (en) 2013-02-26 2014-02-26 Highly available main memory database system, operating method and uses thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102013101863.7A DE102013101863A1 (de) 2013-02-26 2013-02-26 Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen

Publications (1)

Publication Number Publication Date
DE102013101863A1 true DE102013101863A1 (de) 2014-08-28

Family

ID=51349331

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013101863.7A Withdrawn DE102013101863A1 (de) 2013-02-26 2013-02-26 Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen

Country Status (2)

Country Link
US (1) US20140244578A1 (de)
DE (1) DE102013101863A1 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8751755B2 (en) 2007-12-27 2014-06-10 Sandisk Enterprise Ip Llc Mass storage controller volatile memory containing metadata related to flash memory storage
US9699263B1 (en) 2012-08-17 2017-07-04 Sandisk Technologies Llc. Automatic read and write acceleration of data accessed by virtual machines
US9501398B2 (en) 2012-12-26 2016-11-22 Sandisk Technologies Llc Persistent storage device with NVRAM for staging writes
US9612948B2 (en) 2012-12-27 2017-04-04 Sandisk Technologies Llc Reads and writes between a contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device
US9870830B1 (en) 2013-03-14 2018-01-16 Sandisk Technologies Llc Optimal multilevel sensing for reading data from a storage medium
US9524235B1 (en) 2013-07-25 2016-12-20 Sandisk Technologies Llc Local hash value generation in non-volatile data storage systems
US9639463B1 (en) 2013-08-26 2017-05-02 Sandisk Technologies Llc Heuristic aware garbage collection scheme in storage systems
US9442662B2 (en) 2013-10-18 2016-09-13 Sandisk Technologies Llc Device and method for managing die groups
US9703816B2 (en) 2013-11-19 2017-07-11 Sandisk Technologies Llc Method and system for forward reference logging in a persistent datastore
US9520197B2 (en) 2013-11-22 2016-12-13 Sandisk Technologies Llc Adaptive erase of a storage device
US9520162B2 (en) * 2013-11-27 2016-12-13 Sandisk Technologies Llc DIMM device controller supervisor
US9582058B2 (en) 2013-11-29 2017-02-28 Sandisk Technologies Llc Power inrush management of storage devices
US9703636B2 (en) 2014-03-01 2017-07-11 Sandisk Technologies Llc Firmware reversion trigger and control
US9448876B2 (en) 2014-03-19 2016-09-20 Sandisk Technologies Llc Fault detection and prediction in storage devices
US9454448B2 (en) 2014-03-19 2016-09-27 Sandisk Technologies Llc Fault testing in storage devices
US9626399B2 (en) 2014-03-31 2017-04-18 Sandisk Technologies Llc Conditional updates for reducing frequency of data modification operations
US9626400B2 (en) 2014-03-31 2017-04-18 Sandisk Technologies Llc Compaction of information in tiered data structure
US9697267B2 (en) 2014-04-03 2017-07-04 Sandisk Technologies Llc Methods and systems for performing efficient snapshots in tiered data structures
US10146448B2 (en) 2014-05-30 2018-12-04 Sandisk Technologies Llc Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device
US10114557B2 (en) 2014-05-30 2018-10-30 Sandisk Technologies Llc Identification of hot regions to enhance performance and endurance of a non-volatile storage device
US10162748B2 (en) 2014-05-30 2018-12-25 Sandisk Technologies Llc Prioritizing garbage collection and block allocation based on I/O history for logical address regions
US10656840B2 (en) 2014-05-30 2020-05-19 Sandisk Technologies Llc Real-time I/O pattern recognition to enhance performance and endurance of a storage device
US9703491B2 (en) 2014-05-30 2017-07-11 Sandisk Technologies Llc Using history of unaligned writes to cache data and avoid read-modify-writes in a non-volatile storage device
US10656842B2 (en) 2014-05-30 2020-05-19 Sandisk Technologies Llc Using history of I/O sizes and I/O sequences to trigger coalesced writes in a non-volatile storage device
US10372613B2 (en) 2014-05-30 2019-08-06 Sandisk Technologies Llc Using sub-region I/O history to cache repeatedly accessed sub-regions in a non-volatile storage device
US9558147B2 (en) * 2014-06-12 2017-01-31 Nxp B.V. Fine-grained stream-policing mechanism for automotive ethernet switches
US9652381B2 (en) 2014-06-19 2017-05-16 Sandisk Technologies Llc Sub-block garbage collection
US9652339B2 (en) * 2014-10-31 2017-05-16 Red Hat, Inc. Fault tolerant listener registration in the presence of node crashes in a data grid
US11308085B2 (en) * 2014-12-08 2022-04-19 Teradata Us, Inc. Map intelligence for mapping data to multiple processing units of database systems
US9448901B1 (en) * 2015-12-15 2016-09-20 International Business Machines Corporation Remote direct memory access for high availability nodes using a coherent accelerator processor interface
EP3525080A1 (de) * 2017-12-26 2019-08-14 Huawei Technologies Co., Ltd. Verfahren und vorrichtung für zugriff auf ein speichersystem

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6205449B1 (en) * 1998-03-20 2001-03-20 Lucent Technologies, Inc. System and method for providing hot spare redundancy and recovery for a very large database management system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US8892509B2 (en) * 2006-03-28 2014-11-18 Oracle America, Inc. Systems and methods for a distributed in-memory database
US8868504B2 (en) * 2007-03-07 2014-10-21 Oracle International Corporation Database system with active standby and nodes
US8229945B2 (en) * 2008-03-20 2012-07-24 Schooner Information Technology, Inc. Scalable database management software on a cluster of nodes using a shared-distributed flash memory
US9047178B2 (en) * 2010-12-13 2015-06-02 SanDisk Technologies, Inc. Auto-commit memory synchronization
US20120158650A1 (en) * 2010-12-16 2012-06-21 Sybase, Inc. Distributed data cache database architecture
WO2012085297A1 (es) * 2010-12-20 2012-06-28 Rathod Paresh Manhar Resguardo paralelo para entornos de sistemas de bases de datos distribuidas
US8775486B2 (en) * 2011-04-04 2014-07-08 Symantec Corporation Global indexing within an enterprise object store file system
US8929220B2 (en) * 2012-08-24 2015-01-06 Advanced Micro Devices, Inc. Processing system using virtual network interface controller addressing as flow control metadata

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6205449B1 (en) * 1998-03-20 2001-03-20 Lucent Technologies, Inc. System and method for providing hot spare redundancy and recovery for a very large database management system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BERNARD, M.: SAP High-Performance Analytic Appliance 1.0 (SAP HANA). Februar 2011 [recherchiert am 09.01.2014], S. 1 - 43. Im Internet: <URL: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70d16119-ad21-2e10-de8b-eaaedf86b9cd?QuickLink=events&overridelayout=true&50603304707848> *
BERNARD, M.: SAP High-Performance Analytic Appliance 1.0 (SAP HANA). Februar 2011 [recherchiert am 09.01.2014], S. 1 – 43. Im Internet: <URL: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/70d16119-ad21-2e10-de8b-eaaedf86b9cd?QuickLink=events&overridelayout=true&50603304707848>
VIEIRA, Jorge [et al.]: Redundant array of inexpensive nodes for DWS. In: Database sys-tems for advanced applications : 13th International Conference, DASFAA 2008, New Delhi, India, March 19-21, 2008 ; proceedings. Berlin : Springer, 2008 (Lecture Notes in Computer Science ; 4947) S. 580-587. - ISBN 978-3-540-78567-5. - ISBN 3-540-78567-1 *

Also Published As

Publication number Publication date
US20140244578A1 (en) 2014-08-28

Similar Documents

Publication Publication Date Title
DE102013101863A1 (de) Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen
DE112014001873T5 (de) Replikation für Hot-Standby-Online-Datenbank
DE102014117465B4 (de) Unterstützter kohärenter gemeinsamer Speicher
EP2880534B1 (de) Hochverfügbares rechnersystem, arbeitsverfahren und dessen verwendung
DE112019002584T5 (de) Wechseln zwischen vermittlerdiensten für ein speichersystem
DE602005002532T2 (de) Cluster-datenbank mit ferndatenspiegelung
DE60316776T2 (de) Auf netzwerkdatenspeicherung bezogene operationen
DE60111072T2 (de) Verfahren und vorrichtung zur parallelen nachrichtenübermittlung in echtzeit von dateisegmentierten
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE112011100112B4 (de) Pufferspeicher-platte in blitzkopie-kaskade
DE112013001421B4 (de) Auf Richtlinien beruhendes Verwalten von Speicherfunktionen in Datenreplikationsumgebungen
DE69724834T2 (de) System für hochverfügbare datenspeicherung mit allgemein-adressiertem speicher
DE602005003490T2 (de) Verteiltes System mit Quorumredundanz und Verfahren dafür
DE102012215918A1 (de) Spiegeln virtueller Maschinen von einem primären auf einen sekundären Host
DE112011103666T5 (de) Speicherverwaltung in Cluster-Datenverarbeitungssystemen
DE10236179A1 (de) Speichersystem und Verfahren zur Verwendung desselben
DE112013006549T5 (de) Computersystem und Datensteuerverfahren
DE112014003287T5 (de) Dynamische Bildung von symmetrischen Multiprozessordomänen (SMP-Domänen)
DE112012000282B4 (de) Anwendungswiederherstellung in einem Dateisystem
DE102005012448A1 (de) System und Verfahren zur Wiederherstellung eines Laufwerks nach einem Ausfall eines Laufwerks
DE112013007300T5 (de) Speichersysteme mit adaptiver Löschcode-Generierung
EP1959639B1 (de) Ausfallsicheres System zum Verwalten von Client-Server-Kommunikation
DE112012003695T5 (de) Aufrechterhalten mehrerer Zielkopien
DE112011103367T5 (de) Replizieren von Daten
DE112018001561B4 (de) Verteiltes speichernetzwerk

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee