MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Vergleich der Hochverfügbarkeit von Datenbanken – MySQL/MariaDB-Replikation vs. Oracle Data Guard

Im „State of the Open-Source DBMS Market, 2018“ prognostiziert Gartner, dass bis 2022 70 Prozent der neuen Inhouse-Anwendungen auf einer Open-Source-Datenbank entwickelt werden. Und 50 % der bestehenden kommerziellen Datenbanken werden konvertiert sein. Also, Oracle-DBAs, bereiten Sie sich darauf vor, neue Open-Source-Datenbanken bereitzustellen und zu verwalten – zusammen mit Ihren alten Oracle-Instanzen. Es sei denn, Sie tun es bereits.

Wie schlägt sich also die MySQL- oder MariaDB-Replikation im Vergleich zu Oracle Data Guard? In diesem Blog vergleichen wir die beiden unter dem Gesichtspunkt einer hochverfügbaren Datenbanklösung.

Worauf Sie achten sollten

Eine moderne Datenreplikationsarchitektur basiert auf flexiblen Designs, die eine unidirektionale und bidirektionale Datenreplikation sowie ein schnelles, automatisiertes Failover auf sekundäre Datenbanken im Falle einer ungeplanten Serviceunterbrechung ermöglichen. Failover sollte auch einfach auszuführen und zuverlässig sein, damit keine festgeschriebenen Transaktionen verloren gehen. Darüber hinaus sollte Switchover oder Failover idealerweise für Anwendungen transparent sein.

Datenreplikationslösungen müssen in der Lage sein, Daten mit sehr geringer Latenz zu kopieren, um Verarbeitungsengpässe zu vermeiden und den Echtzeitzugriff auf Daten zu gewährleisten. Echtzeitkopien könnten auf einer anderen Datenbank bereitgestellt werden, die auf kostengünstiger Hardware ausgeführt wird.

Wenn es für die Notfallwiederherstellung verwendet wird, muss das System validiert werden, um den Anwendungszugriff auf das sekundäre System mit minimaler Dienstunterbrechung sicherzustellen. Die ideale Lösung sollte ein regelmäßiges Testen des Disaster-Recovery-Prozesses ermöglichen.

Hauptthemen des Vergleichs

  • Datenverfügbarkeit und -konsistenz
    • Gtid, scm
    • Erwähnen Sie die Replikation auf mehrere Standby-, Async- und Sync-Modelle
    • Isolierung des Standby von Produktionsfehlern (z. B. verzögerte Replikation für mysql)
    • Datenverlust vermeiden (Sync-Replikation)
  • Standby-Systemauslastung
    • Nutzung des Standby
  • Failover, Switchover und automatische Wiederherstellung
    • Datenbank-Failover
    • Transparentes Anwendungs-Failover (TAF vs. ProxySQL, MaxScale)
  • Sicherheit
  • Benutzerfreundlichkeit und Verwaltung (einheitliche Verwaltung vorintegrierter Komponenten)

Datenverfügbarkeit und Konsistenz

MySQL-GTID

Die MySQL 5.5-Replikation basierte auf binären Protokollereignissen, bei denen ein Slave nur das genaue Ereignis und die genaue Position kannte, die er gerade vom Master gelesen hatte. Jede einzelne Transaktion von einem Master kann in verschiedenen Binärprotokollen von verschiedenen Slaves geendet haben, und die Transaktion würde typischerweise unterschiedliche Positionen in diesen Protokollen haben. Es war eine einfache Lösung, die mit Einschränkungen einherging, Topologieänderungen konnten dazu führen, dass ein Administrator die Replikation auf den betroffenen Instanzen stoppte. Diese Änderungen könnten einige andere Probleme verursachen, z. B. konnte ein Slave nicht ohne einen zeitaufwändigen Neuaufbau in der Replikationskette nach unten verschoben werden. Das Reparieren einer defekten Replikationsverbindung würde das manuelle Bestimmen einer neuen binären Protokolldatei und der Position der letzten auf dem Slave ausgeführten Transaktion und die Wiederaufnahme von dort oder einen vollständigen Neuaufbau erfordern. Wir alle mussten diese Einschränkungen umgehen, während wir von einer globalen Transaktionskennung träumten.

MySQL Version 5.6 (und MariaDB Version 10.0.2) hat einen Mechanismus eingeführt, um dieses Problem zu lösen. GTID (Global Transaction Identifier) ​​bietet eine bessere Transaktionszuordnung über Knoten hinweg.

Mit GTID können Slaves sehen, dass eine eindeutige Transaktion von mehreren Mastern eingeht, und diese kann einfach in die Slave-Ausführungsliste abgebildet werden, wenn die Replikation neu gestartet oder fortgesetzt werden muss. Der Rat lautet also, immer GTID zu verwenden. Beachten Sie, dass MySQL und MariaDB unterschiedliche GTID-Implementierungen haben.

Oracle-SCN

1992 führte Oracle mit Release 7.3 eine Lösung ein, um eine synchronisierte Kopie einer Datenbank als Standby zu halten, bekannt als Data Guard von Version 9i Release 2. Eine Data Guard-Konfiguration besteht aus zwei Hauptkomponenten, einer einzelnen primären Datenbank und einer Standby-Datenbank (bis zu 30). Änderungen an der Primärdatenbank werden durch die Standby-Datenbank geleitet, und diese Änderungen werden auf die Standby-Datenbank angewendet, um sie synchron zu halten.

Oracle Data Guard wird anfänglich aus einer Sicherung der primären Datenbank erstellt. Data Guard synchronisiert automatisch die primäre Datenbank und alle Standby-Datenbanken, indem Primärdatenbank-Redo – die Informationen, die von jeder Oracle-Datenbank zum Schutz von Transaktionen verwendet werden – übertragen und auf die Standby-Datenbank angewendet werden. Oracle verwendet einen internen Mechanismus namens SCN (System Change Number). Die Systemänderungsnummer (SCN) ist die Uhr von Oracle. Jedes Mal, wenn wir festschreiben, wird die Uhr erhöht. Der SCN markiert einen konsistenten Zeitpunkt in der Datenbank, bei dem es sich um einen Kontrollpunkt handelt, bei dem Dirty Blocks (geänderte Blöcke aus dem Puffer-Cache auf die Festplatte) geschrieben werden. Wir können es mit GTID in MySQL vergleichen.

Data Guard-Transportservices handhaben alle Aspekte der Übertragung von Redo von einer Primär- zu einer Standby-Datenbank. Wenn Benutzer Transaktionen auf dem Primärserver ausführen, werden Redo-Datensätze generiert und in eine lokale Online-Protokolldatei geschrieben. Die Data Guard-Transportdienste übertragen dieselbe Wiederholung gleichzeitig direkt aus dem Protokollpuffer der primären Datenbank (im globalen Systembereich zugewiesener Speicher) an die Standby-Datenbank(en), wo sie in eine Standby-Redo-Protokolldatei geschrieben werden.

Es gibt einige Hauptunterschiede zwischen der MySQL-Replikation und Data Guard. Die direkte Übertragung von Data Guard aus dem Speicher vermeidet Festplatten-I/O-Overhead in der primären Datenbank. Es unterscheidet sich von der Funktionsweise von MySQL - das Lesen von Daten aus dem Speicher verringert die E/A in einer primären Datenbank.

Data Guard überträgt nur Datenbank-Redo. Dies steht im krassen Gegensatz zur Speicher-Remote-Spiegelung, die jeden geänderten Block in jeder Datei übertragen muss, um die Echtzeit-Synchronisation aufrechtzuerhalten.

Async + Sync-Modelle

Oracle Data Guard bietet drei verschiedene Modelle für die Redo-Anwendung an. Adaptive Modelle, abhängig von verfügbarer Hardware, Prozessen und letztlich Geschäftsanforderungen.

  • Maximale Leistung - Standardbetriebsmodus, der es ermöglicht, eine Transaktion festzuschreiben, sobald die Redo-Daten, die zur Wiederherstellung dieser Transaktion erforderlich sind, in das lokale Redo-Protokoll auf dem Master geschrieben werden.
  • Maximaler Schutz – kein Datenverlust und maximaler Schutz. Die Redo-Daten, die zur Verbesserung jeder Operation benötigt werden, müssen sowohl in das lokale Online-Redo-Log auf dem Master als auch in das Standby-Redo-Log auf mindestens einer Standby-Datenbank geschrieben werden, bevor die Transaktion festgeschrieben wird (Oracle empfiehlt mindestens zwei Standbys). Die primäre Datenbank wird heruntergefahren, wenn ein Fehler sie daran hindert, ihren Redo-Stream in mindestens eine synchronisierte Standby-Datenbank zu schreiben.
  • Maximale Verfügbarkeit – ähnlich wie Maximum Protection, aber die primäre Datenbank wird nicht heruntergefahren, wenn ein Fehler sie daran hindert, ihren Redo-Stream zu schreiben.

Bei der Wahl Ihres MySQL-Replikations-Setups haben Sie die Wahl zwischen asynchroner Replikation oder halbsynchroner Replikation.

  • Asynchronous binlog apply ist die Standardmethode für die MySQL-Replikation. Der Master schreibt Ereignisse in sein Binärprotokoll und Slaves fordern sie an, wenn sie bereit sind. Es gibt keine Garantie, dass ein Ereignis jemals einen Sklaven erreicht.
  • Die halbsynchrone Festschreibung auf dem Primärserver wird verzögert, bis der Master eine Bestätigung vom halbsynchronen Slave erhält, dass Daten vom Slave empfangen und geschrieben wurden. Bitte beachten Sie, dass für die halbsynchrone Replikation ein zusätzliches Plugin installiert werden muss.

Nutzung von Standby-Systemen

MySQL ist bekannt für seine Einfachheit und Flexibilität bei der Replikation. Standardmäßig können Sie auf Ihre Standby-/Slave-Server lesen oder sogar schreiben. Glücklicherweise brachten MySQL 5.6 und 5.7 viele bedeutende Verbesserungen für die Replikation, einschließlich globaler Transaktions-IDs, Ereignisprüfsummen, Multithread-Slaves und absturzsicherer Slaves/Master, um sie noch besser zu machen. DBAs, die an MySQL-Replikationslese- und -schreibvorgänge gewöhnt sind, würden eine ähnliche oder sogar einfachere Lösung von seinem größeren Bruder Oracle erwarten. Leider standardmäßig nicht.

Die physische Standard-Standby-Implementierung für Oracle ist für alle Lese-/Schreibvorgänge geschlossen. Tatsächlich bietet Oracle logische Variationen, hat aber viele Einschränkungen und ist nicht für HA konzipiert. Die Lösung für dieses Problem ist eine zusätzliche kostenpflichtige Funktion namens Active Data Guard, mit der Sie Daten aus dem Standby lesen können, während Sie Redo-Protokolle anwenden.

Active Data Guard ist eine kostenpflichtige Add-On-Lösung für die kostenlose Disaster-Recovery-Software Data Guard von Oracle, die nur für Oracle Database Enterprise Edition (kostspieligste Lizenz) verfügbar ist. Es bietet schreibgeschützten Zugriff, während Änderungen, die von der primären Datenbank gesendet werden, kontinuierlich angewendet werden. Als aktive Standby-Datenbank hilft sie dabei, Leseabfragen, Berichte und inkrementelle Backups von der Primärdatenbank zu entlasten. Die Architektur des Produkts ist so konzipiert, dass Standby-Datenbanken von Fehlern isoliert werden können, die in der Primärdatenbank auftreten können.

Eine aufregende Funktion der Oracle-Datenbank 12c und etwas, das Oracle DBA vermissen würde, ist die Datenkorruptionsvalidierung. Oracle Data Guard-Korruptionsprüfungen werden durchgeführt, um sicherzustellen, dass die Daten genau ausgerichtet sind, bevor Daten in eine Standby-Datenbank kopiert werden. Dieser Mechanismus kann auch verwendet werden, um Datenblöcke auf der Primärdatenbank direkt aus der Standby-Datenbank wiederherzustellen.

Failover, Switchover und automatische Wiederherstellung

Um Ihr Replikations-Setup stabil und am Laufen zu halten, ist es entscheidend, dass das System ausfallsicher ist. Ausfälle werden entweder durch Softwarefehler, Konfigurationsprobleme oder Hardwareprobleme verursacht und können jederzeit auftreten. Falls ein Server ausfällt, benötigen Sie eine Alarmbenachrichtigung über das verschlechterte Setup. Failover (Beförderung eines Slaves zum Master) kann vom Administrator durchgeführt werden, der entscheiden muss, welcher Slave befördert werden soll.

Der Administrator benötigt Informationen über den Fehler, den Synchronisierungsstatus für den Fall, dass Daten verloren gehen, und schließlich Schritte zum Ausführen der Aktion. Idealerweise sollte alles automatisiert und von einer einzigen Konsole aus sichtbar sein.

Es gibt zwei Hauptansätze für MySQL-Failover, automatisch und manuell. Beide Optionen haben ihre Fans, wir beschreiben die Konzepte in einem anderen Artikel.

Mit der GTID wird das manuelle Failover viel einfacher. Es besteht aus Schritten wie:

  • Halten Sie das Empfängermodul an (STOP SLAVE IO_THREAD)
  • Master wechseln (CHANGE MASTER TO )
  • Starten Sie das Empfängermodul (START SLAVE IO_THREAD)

Oracle Data Guard wird mit einer dedizierten Failover-/Switchover-Lösung geliefert – Data Guard Broker. Der Broker ist ein verteiltes Management-Framework, das die Erstellung, Wartung und Überwachung von Oracle Data Guard-Konfigurationen automatisiert und zentralisiert. Mit dem Zugriff auf das DG-Broker-Tool können Sie Konfigurationsänderungen, Umschaltungen, Failover und sogar Trockentests Ihres Hochverfügbarkeits-Setups durchführen. Die beiden Hauptaktionen sind:

  • Der Switchover-Vorgang wird mit dem Befehl SWITCHOVER TO durchgeführt. Nach dem erfolgreichen Umschaltvorgang tauschen die Datenbankinstanzen die Plätze und die Replikation wird fortgesetzt. Es ist nicht möglich, umzuschalten, wenn der Standby-Modus nicht reagiert oder heruntergefahren ist.
  • Das allgemeine FAILOVER TO wird verwendet, um das Failover durchzuführen. Nach dem Failover-Vorgang muss der vorherige Primärserver neu erstellt werden, aber der neue Primärserver kann die Datenbankarbeitslast übernehmen.

Apropos Failover:Wir müssen berücksichtigen, wie nahtlos das Failover Ihrer Anwendung sein kann. Wie effizient können Benutzersitzungen im Falle eines geplanten/ungeplanten Ausfalls mit minimaler Betriebsunterbrechung an einen sekundären Standort umgeleitet werden?

Der Standardansatz für MySQL wäre die Verwendung eines der verfügbaren Load Balancer. Angefangen von HAProxy, das häufig für HTTP- oder TCP/IP-Failover verwendet wird, bis hin zu datenbankfähigem Maxscale oder ProxySQL.

In Oracle wird dieses Problem durch TAF (Transparent Application Failover) angegangen. Sobald ein Switchover oder Failover erfolgt, wird die Anwendung automatisch an den neuen primären Server geleitet. TAF ermöglicht es der Anwendung, sich automatisch und transparent wieder mit einer neuen Datenbank zu verbinden, wenn die Datenbankinstanz, zu der die Verbindung hergestellt wurde, ausfällt.

Sicherheit

Datensicherheit ist heutzutage für viele Organisationen ein heißes Thema. Für diejenigen, die Standards wie PCI DSS oder HIPAA implementieren müssen, ist Datenbanksicherheit ein Muss. Die WAN-übergreifenden Umgebungen können zu Bedenken hinsichtlich des Datenschutzes und der Sicherheit führen, zumal immer mehr Unternehmen nationale und internationale Vorschriften einhalten müssen. MySQL-Binärprotokolle, die für die Replikation verwendet werden, können leicht lesbare vertrauliche Daten enthalten. Mit der Standardkonfiguration ist das Stehlen von Daten ein sehr einfacher Vorgang. MySQL unterstützt SSL als Mechanismus zum Verschlüsseln des Datenverkehrs sowohl zwischen MySQL-Servern (Replikation) als auch zwischen MySQL-Servern und -Clients. Eine typische Methode zur Implementierung der SSL-Verschlüsselung ist die Verwendung selbstsignierter Zertifikate. In den meisten Fällen ist es nicht erforderlich, ein von der Zertifizierungsstelle ausgestelltes SSL-Zertifikat zu erhalten. Sie können entweder openssl verwenden, um Zertifikate zu erstellen, Beispiel unten:

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

Ändern Sie dann die Replikation mit Parametern für SSL.

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

Für eine stärker automatisierte Option können Sie ClusterControl verwenden, um die Verschlüsselung zu aktivieren und SSL-Schlüssel zu verwalten.

In Oracle 12c kann der Redo-Transport von Data Guard in eine Reihe dedizierter Sicherheitsfunktionen namens Oracle Advanced Security (OAS) integriert werden. Erweiterte Sicherheit kann verwendet werden, um Verschlüsselungs- und Authentifizierungsdienste zwischen dem Primär- und dem Standby-System zu aktivieren. Beispielsweise erfordert die Aktivierung des Verschlüsselungsalgorithmus Advanced Encryption Standard (AES) nur wenige Parameteränderungen in der Datei sqlnet.ora, um Redo (ähnlich wie MySQL Binlog) zu verschlüsseln. Es ist keine Einrichtung eines externen Zertifikats erforderlich, und es ist lediglich ein Neustart der Standby-Datenbank erforderlich. Die Änderung in sqlnet.ora und Wallet ist einfach wie folgt:

Erstellen Sie ein Wallet-Verzeichnis

mkdir /u01/app/wallet

Bearbeiten Sie sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

Erstellen Sie einen Schlüsselspeicher

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

Shop öffnen

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Erstellen Sie einen Hauptschlüssel

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

Im Standby

Kopieren Sie die p12- und .sso-Dateien in das Wallet-Verzeichnis und aktualisieren Sie die sqlnet.ora-Datei ähnlich wie beim primären Knoten.

Für weitere Informationen folgen Sie bitte dem TDE-Whitepaper von Oracle. Sie können aus dem Whitepaper lernen, wie Sie Datendateien verschlüsseln und Brieftaschen immer offen machen.

Benutzerfreundlichkeit und Verwaltung

Wenn Sie die Oracle Data Guard-Konfiguration verwalten oder bereitstellen, stellen Sie möglicherweise fest, dass es viele Schritte und Parameter gibt, nach denen Sie suchen müssen. Um das zu beantworten, hat Oracle DG Broker entwickelt.

Sie können sicherlich eine Data Guard-Konfiguration erstellen, ohne den DG Broker zu implementieren, aber es kann Ihr Leben viel komfortabler machen. Wenn es implementiert ist, ist das Befehlszeilendienstprogramm des Brokers – DGMGRL – wahrscheinlich die erste Wahl für den DBA. Für diejenigen, die GUI bevorzugen, bietet Cloud Control 13c die Möglichkeit, über die Webschnittstelle auf DG Broker zuzugreifen.

Die Aufgaben, bei denen Broker helfen kann, sind ein automatischer Start der verwalteten Wiederherstellung, ein Befehl für Failover/Switchover, Überwachung der DG-Replikation, Konfigurationsüberprüfung und viele andere.

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago

MySQL bietet keine ähnliche Lösung wie Oracle DG Broker. Sie können die Funktionalität jedoch erweitern, indem Sie Tools wie Orchestrator, MHA und Load Balancer (ProxySQL, HAProxy oder Maxscale) verwenden. Die Lösung zur Verwaltung von Datenbanken und Load Balancern ist ClusterControl. Die ClusterControl Enterprise Edition bietet Ihnen zusätzlich zu den Bereitstellungs- und Überwachungsfunktionen, die als Teil der kostenlosen Community Edition angeboten werden, einen vollständigen Satz an Verwaltungs- und Skalierungsfunktionen.