Datenbanken können ohne Vorwarnung ausfallen – entweder aufgrund eines durch einen Softwarefehler verursachten Absturzes oder der zugrunde liegenden Hardwarekomponenten. Die Cloud verleiht dem Problem aufgrund der kurzlebigen Natur von Rechen- und Speicherressourcen eine weitere Dimension. Um unsere Datenbankinfrastruktur vor diesen Ausfällen zu schützen, bauen wir Redundanz in unsere Systeme ein. Wenn eine Instanz nicht verfügbar ist, sollte ein Standby-System in der Lage sein, die Arbeitslast zu übernehmen und von dort aus weiterzumachen. Die Replikation ist eine bekannte und weit verbreitete Methode zum Erstellen redundanter Kopien einer Master-Datenbank.
In diesem Beitrag werden wir die Replikationsfunktionalität in den zwei beliebtesten Datenbanksystemen der Welt (laut db-engines) vergleichen – Oracle und MySQL. Wir werden uns speziell die logische Replikation von Oracle 12c und MySQL 5.7 ansehen. Beide Technologien bieten zuverlässige Standby-Systeme, um Produktionslasten zu entlasten und im Katastrophenfall zu helfen. Wir werden uns ihre unterschiedlichen Architekturen ansehen, Vor- und Nachteile analysieren und die Schritte zur Einrichtung der Replikation mit Oracle und MySQL durchgehen.
Oracle Data Guard Architecture – So funktioniert es
Oracle Data Guard gewährleistet Hochverfügbarkeit, Datenschutz und Notfallwiederherstellung Ihrer Daten. Es ist wahrscheinlich die erste Wahl eines Oracle DBA für die Replikation von Daten. Die Technologie wurde 1990 (Version 7.0) mit einer wesentlichen Anwendung von Archivprotokollen auf Standby-Datenbanken eingeführt. Data Guard hat sich im Laufe der Jahre weiterentwickelt und bietet jetzt eine umfassende Reihe von Diensten zum Erstellen, Warten, Verwalten und Überwachen von Standby-Datenbanken.
Data Guard verwaltet Standby-Datenbanken als Kopien der Produktionsdatenbank. Wenn die primäre Datenbank nicht mehr reagiert, kann Data Guard jeden Standby-Server auf die Produktionsrolle umstellen, was zu Ausfallzeiten führt. Data Guard kann für Sicherungs-, Wiederherstellungs- und Cluster-Techniken verwendet werden, um ein hohes Maß an Datenschutz und Datenverfügbarkeit bereitzustellen.
Data Guard ist eine Ship Redo / Apply Redo-Technologie, "Redo" ist die Information, die zum Wiederherstellen von Transaktionen benötigt wird. Eine Produktionsdatenbank, die als primäre Datenbank bezeichnet wird, sendet Redo an eine oder mehrere Replikate, die als Standby-Datenbanken bezeichnet werden. Wenn eine Tabelle eingefügt oder aktualisiert wird, wird diese Änderung vom Protokollschreiber in einem Archivprotokoll erfasst und auf das Standby-System repliziert. Standby-Datenbanken befinden sich in einer kontinuierlichen Phase der Wiederherstellung, Überprüfung und Anwendung von Redo, um die Synchronisierung mit der Primärdatenbank aufrechtzuerhalten. Eine Standby-Datenbank wird auch automatisch neu synchronisiert, wenn sie aufgrund von Stromausfällen, Netzwerkproblemen usw. vorübergehend von der primären Datenbank getrennt wird.
Oracle Data Guard Net-Dienste Data Guard Redo Transport Services regeln die Übertragung von Redo von der primären Datenbank zur Standby-Datenbank. Der LGWR-Prozess (Log Writer) übermittelt die Redo-Daten an einen oder mehrere Netzwerkserver-Prozesse (LNS1, LSN2, LSN3, ... LSNn). LNS liest aus dem Redo-Puffer in der SGA (Shared Global Area) und übergibt Redo an Oracle Net Services, um es an die Standby-Datenbank zu übertragen. Sie können die LGWR-Attribute auswählen:synchroner (LogXptMode ='SYNC') oder asynchroner Modus (LogXptMode ='ASYNC'). Mit einer solchen Architektur ist es möglich, die Redo-Daten an mehrere Standby-Datenbanken zu liefern oder sie mit Oracle RAC (Real Application Cluster) zu verwenden. Der Remote File Server (RFS)-Prozess empfängt das Redo von LNS und schreibt es in eine reguläre Datei, die als Standby Redo Log (SRL)-Datei bezeichnet wird.
Es gibt zwei Haupttypen von Oracle Data Guard. Physische Datenbanken mit Redo Apply und Logische Standby-Datenbanken mit SQL Apply.
Logische Replikationsarchitektur von Oracle Dataguard SQL Apply erfordert mehr Verarbeitung als Redo, der Prozess liest zuerst die SRL und „minet“ die Redo, indem er sie in logische Änderungsdatensätze umwandelt, und baut dann SQL-Transaktionen auf, bevor er die SQL auf die Standby-Datenbank anwendet. Es gibt mehr bewegliche Teile, sodass mehr CPU, Arbeitsspeicher und E/A erforderlich sind, um die Anwendung erneut durchzuführen.
Der Hauptvorteil von "SQL apply" besteht darin, dass die Datenbank für Lese- und Schreibzugriff geöffnet ist, während der Apply-Prozess aktiv ist.
Sie können sogar Ansichten und lokale Indizes erstellen. Dies macht es ideal für Reporting-Tools. Die Standby-Datenbank muss keine Eins-zu-eins-Kopie Ihrer Primärdatenbank sein und ist daher möglicherweise nicht der beste Kandidat für DR-Zwecke.
Die Hauptmerkmale dieser Lösung sind:
- Eine Standby-Datenbank, die zum Lesen und Schreiben geöffnet ist, während SQL apply aktiv ist
- Mögliche Änderungssperre von Daten, die von der SQL-Anwendung verwaltet werden
- Kann laufende Datenbank-Upgrades ausführen
Es gibt Nachteile. Oracle verwendet eine Primärschlüssel- oder Unique-Constraint/Index-Ergänzungsprotokollierung, um eine geänderte Zeile in der logischen Standby-Datenbank logisch zu erkennen. Wenn die datenbankweite Primärschlüssel- und Unique-Constraint/Index-Ergänzungsprotokollierung aktiviert ist, schreibt jede UPDATE-Anweisung auch die erforderlichen Spaltenwerte in das Redo-Protokoll, um die geänderte Zeile in der logischen Standby-Datenbank eindeutig zu identifizieren. Oracle Data Guard unterstützt die verkettete Replikation, die hier als „Kaskade“ bezeichnet wird, aufgrund der Komplexität des Setups jedoch nicht typisch ist.
Oracle empfiehlt, Tabellen in der Primärdatenbank nach Möglichkeit einen Primärschlüssel oder einen eindeutigen Nicht-Null-Index hinzuzufügen, um sicherzustellen, dass SQL Apply Redo-Datenaktualisierungen effizient auf die logische Standby-Datenbank anwenden kann. Dies bedeutet, dass es bei keinem Setup funktioniert, Sie müssen möglicherweise Ihre Anwendung ändern.
Oracle Golden Gate Architecture – So funktioniert es
Mit Data Guard werden, wenn Blöcke in der Datenbank geändert werden, Datensätze zum Redo-Protokoll hinzugefügt. Dann werden diese Protokolldatensätze basierend auf dem Replikationsmodus, den Sie ausführen, entweder sofort in die Standby-Instanz kopiert oder nach SQL-Befehlen durchsucht und angewendet. Golden Gate funktioniert anders.
Golden Gate repliziert Änderungen erst, nachdem die Transaktion festgeschrieben wurde. Wenn Sie also eine Transaktion mit langer Laufzeit haben, kann die Replikation eine Weile dauern. Der „Extraktionsprozess“ von Golden Gate hält Transaktionsänderungen im Speicher.
Ein weiterer großer Unterschied besteht darin, dass Oracle Golden Gate den Austausch und die Manipulation von Daten auf Transaktionsebene zwischen mehreren heterogenen Plattformen ermöglicht. Sie sind nicht nur auf die Oracle-Datenbank beschränkt. Es gibt Ihnen die Flexibilität, ausgewählte Datensätze, Transaktionsänderungen und Änderungen an DDL (Datendefinitionssprache) über eine Vielzahl von Topologien hinweg zu extrahieren und zu replizieren.
Oracle Golden Gate-Architektur Der typische Golden Gate-Fluss zeigt, dass neue und geänderte Datenbankdaten aus der Quelldatenbank erfasst werden. Die erfassten Daten werden in eine Datei namens Source Trail geschrieben. Der Trail wird dann von einer Datenpumpe gelesen, über das Netzwerk gesendet und vom Collector-Prozess in eine Remote-Trail-Datei geschrieben. Die Delivery-Funktion liest den Remote-Trail und aktualisiert die Zieldatenbank. Jede der Komponenten wird vom Manager-Prozess verwaltet.
Logische MySQL-Replikation – wie es funktioniert
Die Replikation in MySQL gibt es schon seit langer Zeit und hat sich im Laufe der Jahre weiterentwickelt. Es gibt verschiedene Möglichkeiten, die MySQL-Replikation zu aktivieren, einschließlich Gruppenreplikation, Galera-Cluster, asynchrones "Master to Slave". Um die Oracle- und MySQL-Architektur zu vergleichen, konzentrieren wir uns auf die Replikationsformate, da sie die Grundlage für alle verschiedenen Replikationstypen bilden.
Zunächst einmal entsprechen die unterschiedlichen Replikationsformate dem in der Konfigurationsdatei my.cnf angegebenen binären Logging-Format. Unabhängig vom Format werden Protokolle immer binär gespeichert und können nicht mit einem normalen Editor angezeigt werden. Es gibt drei Formattypen:zeilenbasiert, anweisungsbasiert und gemischt. Gemischt ist die Kombination der ersten beiden. Wir werden einen Blick auf Anweisungs- und Zeilenbasis werfen.
Aussagebasiert – in diesem Fall sind dies die schriftlichen Anfragen. Nicht alle Anweisungen, die Daten ändern (z. B. INSERT DELETE-, UPDATE- und REPLACE-Anweisungen), können mithilfe der anweisungsbasierten Replikation repliziert werden. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() usw. werden nicht repliziert.
Zeilenbasiert – in diesem Fall handelt es sich um Änderungen an Datensätzen. Alle Änderungen können repliziert werden. Dies ist die sicherste Form der Replikation. Seit 5.7.7 ist dies die Standardoption.
Lassen Sie uns nun einen Blick darauf werfen, was unter der Haube passiert, wenn die Replikation aktiviert ist.
MySQL-Replikationsarchitektur Zunächst schreibt die Master-Datenbank Änderungen in eine Datei namens Binary Log oder binlog. Das Schreiben in das Binärlog ist normalerweise eine leichte Aktivität, da Schreibvorgänge gepuffert und sequenziell sind. Die binäre Protokolldatei speichert Daten, die ein Replikations-Slave später verarbeitet, die Master-Aktivität hängt nicht von ihnen ab. Wenn die Replikation beginnt, löst mysql drei Threads aus. Einer am Master, zwei am Slave. Der Master hat einen Thread, genannt Dump-Thread, der das Binärlog des Masters liest und an den Slave liefert.
Auf dem Slave verbindet sich ein Prozess namens IO-Thread mit dem Master, liest binäre Protokollereignisse vom Master, sobald sie eintreffen, und kopiert sie in eine lokale Protokolldatei namens Relay Log. Der zweite Slave-Prozess – SQL-Thread – liest Ereignisse aus einem Relaisprotokoll, das lokal auf dem Replikations-Slave gespeichert ist, und verwendet sie dann.
MySQL unterstützt die verkettete Replikation, die sehr einfach einzurichten ist. Slaves, die auch Master sind, müssen mit den Parametern --log-bin und --log-slave-update laufen.
Um den Status der Replikation zu überprüfen und Informationen über Threads zu erhalten, führen Sie auf dem Slave aus:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Logische Data Guard-Replikation in Oracle einrichten
-
Erstellen Sie eine physische Standby-Datenbank
Um eine logische Standby-Datenbank zu erstellen, erstellen Sie zuerst eine physische Standby-Datenbank und übertragen sie dann auf eine logische Standby-Datenbank.
-
Wiederholen-Anwenden auf die physische Standby-Datenbank beenden
Das Beenden von Redo Apply ist erforderlich, um zu verhindern, dass Änderungen übernommen werden.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Vorbereiten der primären Datenbank zur Unterstützung einer logischen Standby-Datenbank
Ändern Sie das Attribut VALID_FOR im ursprünglichen LOG_ARCHIVE_DEST_1 und fügen Sie LOG_ARCHIVE_DEST_3 für die logische Datenbank hinzu.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEErstellen Sie ein Wörterbuch in den Redo-Daten
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
In eine logische Standby-Datenbank konvertieren
Um weiterhin Redo-Daten auf die physische Standby-Datenbank anzuwenden, bis sie bereit ist, in eine logische Standby-Datenbank konvertiert zu werden, setzen Sie die folgende SQL-Anweisung ab:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Initialisierungsparameter für die logische Standby-Datenbank anpassen
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Öffnen Sie die logische Standby-Datenbank
SQL> ALTER DATABASE OPEN RESETLOGS;Überprüfen Sie, ob die logische Standby-Datenbank ordnungsgemäß funktioniert
v$data_guard_stats-Ansicht
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv$logstdby_process-Ansicht
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Dies sind die notwendigen Schritte zum Erstellen einer logischen Oracle Data Guard-Replikation. Die Aktionen unterscheiden sich geringfügig, wenn Sie diesen Vorgang mit einem nicht standardmäßigen Kompatibilitätssatz oder Datenbanken ausführen, die in der Oracle RAC-Umgebung ausgeführt werden.
MySQL-Replikation einrichten
-
Konfigurieren Sie die Master-Datenbank. Legen Sie eine eindeutige server_id fest, geben Sie verschiedene Replikationsprotokolle an –log-basename (MariaDB) , aktivieren Sie das Binärprotokoll. Ändern Sie meine.cnf-Datei mit den folgenden Informationen.
log-bin server_id=1 log-basename=master1Melden Sie sich bei der Master-Datenbank an und gewähren Sie dem Replikationsbenutzer Zugriff auf die Master-Daten.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Starten Sie beide Server mit aktivierten GTIDs.
gtid_mode=ON enforce-gtid-consistency=true -
Konfigurieren Sie den Slave für die Verwendung der GTID-basierten automatischen Positionierung.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Wenn Sie den Slave mit Daten zum Master hinzufügen möchten, müssen Sie ein Backup erstellen und es auf dem Slave-Server wiederherstellen.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlMelden Sie sich bei der Slave-Datenbank an und führen Sie Folgendes aus:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
