Vergleichende Analyse der Hochverfügbarkeitslösungen von Oracle und MySQL

Was die Hochverfügbarkeitslösungen für Oracle und MySQL betrifft, wollte ich sie schon immer zusammenfassen und werde daher in mehreren Serien kurz darauf eingehen. Durch einen solchen Vergleich erhalten wir ein grundlegendes Verständnis der detaillierten Unterschiede im Design der beiden Datenbankarchitekturen. Oracle verfügt über eine sehr ausgereifte Lösung. Der PPT nach zu urteilen, die ich auf OOW gepostet habe, handelt es sich um das MAA-Programm, und dieses Jahr ist der 16. Jahrestag dieses Programms.

Aufgrund des Open-Source-Charakters von MySQL hat die Community weitere Lösungen auf den Markt gebracht. Meiner persönlichen Meinung nach wird InnoDB Cluster in Zukunft die Standardlösung für hohe Verfügbarkeit für MySQL sein.

Derzeit ist MGR gut, es gibt auch MySQL Cluster-Lösungen, PXC, Galera und andere Lösungen, aber ich persönlich bevorzuge MHA.

Daher wird dieser Artikel zur Interpretation in mehrere Teile gegliedert. Zunächst werden wir einen grundlegenden Vergleich zwischen RAC und MHA anstellen.

Die Lösungen von Oracle unterstützten die Kerngeschäftsanforderungen von Alibaba während seiner rasanten Entwicklungsphase. Dies ist wahrscheinlich das architektonische System und es sieht riesig aus. Der darin enthaltene RAC gilt als edel, da er teuren kommerziellen Speicher verwendet, extrem hohe Anforderungen an die Netzwerkbandbreite stellt und am Frontend eine große Anzahl kleiner Maschinenunternehmen mit saftigen Lizenzgebühren betreibt. Eine sehr typische klassische IOE-Architektur.

Wenn Sie eine externe Notfallwiederherstellung in Betracht ziehen möchten, müssen die Ressourcenzuweisung und das Budget verdoppelt werden.

Die MySQL-Architektur ist relativ beliebter. Sie kann auf einem normalen PC installiert werden, ist aber sehr skalierbar. Durch Aufteilung des Geschäfts und horizontale Aufteilung kann eine große Anzahl von Knoten horizontal erweitert werden. Die Größe der MySQL-Cluster vieler großer Internetunternehmen liegt bei Hunderten, und Tausende sind keine Seltenheit. Bei so vielen Serviceressourcen besteht immer noch die Möglichkeit eines Ausfalls. Der Schlüssel zur technischen Lösung besteht darin, einen nachhaltigen Zugriff auf Business-Services sicherzustellen. Gemäß der MHA-Architektur ist der MHA-Manager-Knoten grundsätzlich für den Status des gesamten Clusters verantwortlich, genau wie eine Tante im Nachbarschaftskomitee, die alle großen und kleinen Dinge über die Bewohner weiß.

Natürlich ist die obige Aussage zu allgemein, also beginnen wir mit einigen Details. Lassen Sie uns beispielsweise zuerst über das Internet sprechen.

Oracle stellt sehr strenge Anforderungen an das Netzwerk. Im Allgemeinen sind zwei physische Netzwerkkarten erforderlich. Jeder Server benötigt mindestens drei IPs, darunter eine öffentliche IP, eine private IP und eine VIP. Zusätzlich zum gemeinsam genutzten Speicher sind mindestens zwei Rechenknoten erforderlich.

Private IPs werden zwischen Knoten gegenseitig vertraut. Öffentliche IPs und VIPs befinden sich im selben Netzwerksegment. Einfach ausgedrückt ist VIP extern und eine Drift-IP des Netzwerks, in dem sich die öffentliche IP befindet. In 10g erfolgt der Lastausgleich über VIPs. 11g hat begonnen, Scan-IPs zu haben, und die ursprüngliche VIP wird immer noch beibehalten, sodass die Anforderungen an die Netzwerkkonfiguration in Oracle immer noch sehr hoch sind. Wenn man den gemeinsam genutzten Speicher beiseite lässt, ist die Netzwerkkonfiguration der Kern der Konstruktion. Wenn das Netzwerk verbunden ist, wird es verbunden.

Scan-IP kann weiter erweitert werden, um bis zu 3 Scan-IPs zu unterstützen, wie in der folgenden Abbildung dargestellt

Natürlich besteht die Netzwerkschicht aus mehr als nur diesem, und Oracle ist auf diesem Gebiet sehr professionell. Wir müssen TAF verstehen. In meinem Buch Oracle DBA Work Notes schrieb ich:

TAF (Transparent Application Failover) ist eine für Anwendungen transparente Failover-Funktion in Oracle, die insbesondere in RAC-Umgebungen häufig verwendet wird. Im RAC gab es tatsächlich große Verbesserungen beim Load Balancing, vom Load Balancing mehrerer VIP-Adressen in Version 10g bis hin zum SCAN in Version 11g, das stark vereinfacht wurde.

Es gibt jedoch immer noch bestimmte Nutzungsbeschränkungen bei der Implementierung des Failovers. Beispielsweise verfügt die Standardimplementierung von SCAN-IP in 11g standardmäßig nicht über eine Failover-Option. Wenn einer der beiden Knoten ausfällt, wird bei fortgesetzter Abfrage in der ursprünglichen Verbindung angezeigt, dass die Sitzung getrennt wurde und erneut verbunden werden muss. Client TAF bespricht hauptsächlich einige einfache Inhalte der Failover-Methode und des Failover-Typs.

(1) Failover-Methode

Die Hauptidee der Failover-Methode besteht darin, dies im Austausch gegen Failover-Zeit oder -Ressourcen zu erreichen.

Man kann es folgendermaßen verstehen. Angenommen, wir haben zwei Knoten. Wenn eine Sitzung mit Knoten 2 verbunden ist, Knoten 2 aber plötzlich auflegt, gibt es zwei Failover-Methoden: Preconnect und Basic, um die Failover-Situation schneller zu bewältigen.

— Vorab verbinden Diese Vorabverbindungsmethode beansprucht noch immer mehr Ressourcen. Sie belegt auf jedem Knoten einige zusätzliche Ressourcen, wodurch das Umschalten reibungsloser und schneller wird.

— Bei dieser grundlegenden Methode werden bei einem Failover die entsprechenden Ressourcen umgeschaltet. In der Mitte kommt es zwar zu einer gewissen Verzögerung, der Ressourcenverbrauch ist jedoch relativ viel geringer.

Einfach ausgedrückt wird bei der Basismethode nur dann eine Entscheidung getroffen, wenn ein Fehler auftritt, während die Vorverbindung eine Vorsichtsmaßnahme ist. Aus Sicht der tatsächlichen Anwendung ist die Basismethode häufiger anzutreffen und die Standard-Failover-Methode.

(2) Failover-Typ

Der Failover-Typ ist leistungsfähiger und flexibler. Zu diesem Zeitpunkt kann die Steuerungsgranularität auf der Ausführung von Benutzer-SQL basieren, das entweder eine Auswahl oder eine Sitzung sein kann. Lassen Sie uns dies anhand eines kleinen Beispiels veranschaulichen.

Nehmen wir beispielsweise an, dass auf Knoten 2 eine große Abfrage ausgeführt wird und Knoten 2 plötzlich abstürzt. Für die ausgeführte Abfrage gibt es beispielsweise 10.000 Datensätze, und wenn der Fehler auftritt, werden 8.000 Datensätze gefunden. Was soll dann mit den verbleibenden 2.000 Datensätzen geschehen?

Die erste Möglichkeit besteht darin, select zu verwenden. Das heißt, das Failover wird abgeschlossen und die verbleibenden 2.000 Datensätze werden weiterhin zurückgegeben. Natürlich wird es in der Mitte einige Kontextwechsel geben, die für den Benutzer transparent sind.

Die zweite Methode ist die Sitzungsmethode, d. h. die Verbindung wird direkt getrennt und eine erneute Abfrage verlangt.

In der 10g-Version wird die Konfiguration von Load Balance + Failover mithilfe der VIP-Konfiguration wie folgt erreicht:

racdb=
(BESCHREIBUNG =
(ADRESSE= (PROTOKOLL= TCP)(HOST=192.168.3.101)(PORT= 1521))
(ADRESSE= (PROTOKOLL= TCP)(HOST=192.168.3.201)(PORT= 1521))
(LOAD_BALANCE = ja)
(FAILOVER = EIN)
(CONNECT_DATA =
(SERVER=DEDIZIERT)
(DIENSTNAME = racdb)
(FAILOVER_MODE =
(TYP=AUSWÄHLEN)
(METHODE = GRUNDLEGEND)
(WIEDERHOLUNGSVERSUCH = 30)
(VERZÖGERUNG = 5))))
Wenn Sie das Failover von SCAN-IP 11g weiter erweitern möchten, müssen Sie zusätzlich den failover_mode und den entsprechenden Typ festlegen.
RACDB =
(BESCHREIBUNG =
(ADRESSE = (PROTOKOLL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDIZIERT)
(DIENSTNAME = RACDB)
)
)

Aus dieser Perspektive ist die Lösung von Oracle wirklich ausgereift. Werfen wir einen Blick auf die MySQL-Lösung.

Die verteilte Lösung lässt MySQL wie ein Schweizer Taschenmesser aussehen. Was die Anforderungen auf Netzwerkebene betrifft, kann man sagen, dass MySQL fast keine Anforderungen hat. Wenn Sie einen Master und einen Slave beantragen, benötigen Sie nur 4 IP-Adressen (Master, Slave, VIP, MHA_Manager (betrachten Sie einen Managerknoten)), und ein Master und zwei Slaves bedeuten 5 IP-Adressen.

In dieser Hinsicht unterstützt MySQL nicht nativ das sogenannte Lastenausgleich. Es kann durch das Front-End-Geschäft umgeleitet werden, beispielsweise durch die Verwendung eines Middleware-Proxys oder durch kontinuierliches Aufteilen. Nach Erreichen einer bestimmten Granularität können die Anforderungen durch architektonisches Design erfüllt werden. Aufgrund der logikbasierten Replikation ist eine Erweiterung einfach. Ein Master und mehrere Slaves sind sehr üblich und die Kosten sind nicht hoch. Es gibt zwar eine Latenz, diese ist jedoch sehr gering, was den meisten Anforderungen von Internetunternehmen gerecht wird.

Wenn es um die Bedingungen geht, die MHA-Umschaltungen auslösen, sind aus Netzwerksicht die folgenden roten Punkte potenzielle versteckte Gefahren. Einige sind Netzwerkunterbrechungen und einige sind Netzwerkverzögerungen. Wenn ein Fehler auftritt, kann er, sei es zum Erhalt von Daten oder zur Gewährleistung einer stabilen Leistung, an Ihre eigenen Bedürfnisse angepasst werden. Aus dieser Sicht besteht die Möglichkeit eines Datenverlusts. Es handelt sich definitiv nicht um eine verlustfreie Replikation mit starker Konsistenz.

Insgesamt ist RAC eine zentralisierte Sharing-Lösung. Zusätzlich zum Sharing auf Speicherebene erhöht Multicast auf Netzwerkebene tatsächlich die Kosten der Kommunikation zwischen Knoten. Daher stellt RAC hohe Anforderungen an das Netzwerk. Wenn es zu einer Verzögerung kommt, ist das sehr gefährlich, und wenn es zu einem Brain Split kommt, wird es sehr peinlich. Die MySQL MHA-Lösung ist verteilt. In einer Umgebung, die große Volumina unterstützt, sind die Kosten der Kommunikation zwischen Knoten relativ viel niedriger. Da es sich jedoch um eine replizierte Datenverteilungsmethode handelt, sind aus Sicht der Datenarchitektur die Speicherkosten (nicht der Speicherpreis, sondern die gespeicherte Datenmenge) immer noch höher als bei RAC, obwohl der Speicher nicht gemeinsam genutzt wird.