Ist es nicht ratsam, die Replikation auf demselben physischen Server auszuführen?

13

Ich überlege, eine Master-Slave-Replikation für meine Datenbank einzurichten. Der Slave-Server wird für Redundanz und möglicherweise einen Berichtsserver verwendet. Eines der größten Probleme, auf das ich stoße, ist jedoch, dass wir in unserem Rechenzentrum bereits mit maximaler Leistung arbeiten. Das Hinzufügen eines weiteren physischen Servers ist daher keine Option.

Unser vorhandener Datenbankserver ist im Hinblick auf die CPU-Auslastung unterausgelastet (Lastdurchschnitte werden auf einem Quad-Core nie wirklich über 1). Die Hauptidee ist es, einige neue Laufwerke einzuschleusen, den Speicher zu verdoppeln (von 8 GB auf 16 GB) und eine zweite mysql-Instanz auf demselben physischen Computer auszuführen. Jede Instanz verfügt über separate Datenträger für die Datenbank.

Stimmt etwas mit dieser Idee nicht?

Bearbeiten (mehr Infos): Ich hatte (zum Glück) noch nie etwas Schlimmes, um den Server herunterzufahren, versuche aber, vorausschauend zu planen. Wir haben natürlich nächtliche Backups, von denen wir uns erholen können. Ich war jedoch der Meinung, dass die redundanten Daten auf separaten Festplatten eine schnellere Lösung darstellen würden, wenn die Laufwerke des Masterservers ausfallen würden (offensichtlich nicht, wenn die gesamte Maschine ausfällt).

Bezüglich des Berichtsaspekts sind alle Tabellen, für die wir einen Bericht erstellen würden, MyIsam. Wenn Sie also teure Lesevorgänge für dieselben Tabellen durchführen, in die geschrieben wird, kann dies den Server zum Erliegen bringen. Ich ging davon aus, dass ein zu meldender Slave-Server den Hauptserver nicht beeinträchtigen würde, solange genügend Arbeitsspeicher vorhanden ist (da die CPU-Auslastung noch kein Problem darstellt).

Derek Downey
quelle

Antworten:

11

Aus Gründen der Redundanz in Bezug auf Systemzuverlässigkeit und Datensicherheit bietet der Betrieb eines Slaves auf derselben Maschine wie der Master nichts (oder nahezu nichts). Wenn etwas Schlimmes passiert, um den Master zu stürzen, wird es wahrscheinlich auch den Slave stürzen.

Für die reine Trennung von Benutzern aus Gründen der Zugriffsrechte bietet ein gutes RDBMS effektivere Möglichkeiten, dies zu tun.

Das Ausführen der beiden Datenbanken auf demselben Computer erfordert mehr RAM, um mit derselben Effizienz ausgeführt zu werden, da die beiden Datenbanken um Speicherplatz konkurrieren, um die verschiedenen Puffer und Caches zu erhalten. Durch die E / A-Lasttrennung kann sich jedoch ein Leistungsvorteil ergeben, wenn sich die Datendateien für den Slave auf anderen physischen Laufwerken als der Master befinden. In diesem Fall können Sie komplexe Berichte ausführen, für die viele Festplattenlesevorgänge für den Slave erforderlich waren, ohne dass der Master um die E / A-Bandbreite des Laufwerks konkurriert.

Bearbeiten: Wie DTest in seinem Kommentar unten erwähnt, besteht ein weiterer möglicher Vorteil einer Slave-DB (auch wenn sie sich auf denselben Laufwerken wie der Master befindet) in den komplexen, lang andauernden Abfragen im Slave, die andernfalls zu Sperrproblemen für den Tag führen könnten laufende Abfragen auf dem Master sind sicherer. Obwohl Sie immer noch besser dran sind, den Slave auf verschiedenen Laufwerken zu haben, können solche signifikanten Abfragen Probleme mit E / A-Konflikten verursachen.

David Spillett
quelle
1
Ich dachte, der Slave würde nicht mit den Tabellensperren auf myIsam konkurrieren, wenn der Master (für komplexe Berichte) geschrieben wird.
Derek Downey
@DTest: das wäre sicherlich ein möglicher Bonus, ja (+1). Auch für andere Tabellentypen, wenn eine komplexe Berichtsabfrage möglicherweise eine große Sperre (z. B. eine Tabellensperre) anfordert. Ich werde meiner Antwort eine Notiz hinzufügen, damit es weniger wahrscheinlich ist, dass das Formular ausgeschnitten wird, wenn weitere Kommentare auftauchen.
David Spillett
7

Mir ist nicht klar, wie dies Ihr Problem löst. Es gibt keine Redundanz, da es sich auf derselben physischen Hardware, demselben Betriebssystemkernel, denselben MySQL-Binärdateien, möglicherweise verschiedenen Festplatten, aber auf demselben Speichercontroller usw. befindet. Der Grund für eine Berichtsdatenbank besteht darin, Abfragen von der OLTP-Datenbank und von as auszulagern es ist alles auf dem gleichen Kit, woher kommt die zusätzliche Kraft? Oder gibt es noch etwas, das Sie mit diesem Setup erreichen möchten?

Eine denkbare Verwendung hierfür wäre, die Benutzer vielleicht irgendwie zu trennen, aber ich hätte auch gedacht, dass dies getan werden könnte GRANT.

Gaius
quelle
hat meiner Frage noch ein paar Anmerkungen hinzugefügt. Die Trennung der Benutzer ist jedoch nicht das, was ich erreichen möchte
Derek Downey
2

Es wird in der Tat als unklug angesehen, versuchen Sie nur, mehr Kerne auszunutzen? Was sind die Ziele der neuen Designüberlegung?

(Als Antwort gepostet, kein Kommentar, um den Fokus auf den Konversationsthread zu richten.)

Jcolebrand
quelle
Bieten Sie einen leichten Schutz vor Laufwerksausfällen und stellen Sie gleichzeitig einen Server für komplexe Berichte bereit, der den Zugriff von Produktionsstandorten auf den Master nicht verlangsamt.
Derek Downey
Verwenden sie denselben Festplattencontroller oder können Sie zusätzlich zu den neuen Spindeln einen neuen Festplattencontroller installieren?
jcolebrand
1
Ich bin gerade auf diese gestoßen. Ich habe Ihre rhetorischen Fragen zur Ausnutzung mehrerer Kerne bemerkt. Ich habe das tatsächlich in meiner Antwort zwei Monate nachdem du das gesagt hast, besprochen. +1 für deine Einsicht vor meiner. Übrigens: Hier ist ein schönes Video über das mehrfache Ausführen von MySQL: youtu.be/5uKBg9prA1A
RolandoMySQLDBA
Übrigens: Mein Arbeitgeber hat einen Kunden, für den ich diese Architektur arrangiert habe. Es hat drei Leseslaves auf einer Maschine (alle in MyISAM), während der Master nur InnoDB ist.
RolandoMySQLDBA
1

Dies kann ein zweischneidiges Schwert sein

Sie können mehrere Instanzen von mysql als schreibgeschützte Slaves auf demselben Server wie der Master ausführen, vorausgesetzt, jede Instanz von MySQL befindet sich auf einer anderen Festplatte. Dies ist nur wünschenswert, wenn Sie ältere Versionen von MySQL verwenden, die nicht mehrere Kerne (CPUs) ausnutzen. Die neuesten Versionen von MySQL können so optimiert werden, dass sie tatsächlich mehrere CPUs verwenden, sodass der Zugriff auf mehrere Kerne nicht mehr erforderlich ist, wenn mehrere Instanzen von MySQL ausgeführt werden.

Gleichzeitig ist es auch eine sehr schlechte Idee. Viele meiner Kunden haben dies getan, um Geld beim Kauf von Bare-Metal- oder VM-Servern zu sparen. Jegliche Spitzen in der Serverauslastung können alle laufenden MySQL-Instanzen aufgrund von fehlerhaften Abfragen, langsamen Abfragen, zu vielen Verbindungen, überlasteter Speichernutzung, unzureichendem Serverspeicher, Cache-Thrashing usw. in einer einzelnen MySQL-Instanz beeinträchtigen. Dies erhöht auch die Anwendungskomplexität, da Sie über ihre Portnummer auf die verschiedenen MySQL-Instanzen zugreifen müssen und außerdem TCP / IP ausgeliefert wären.

RolandoMySQLDBA
quelle
0

Ich würde die Replikation auf einem anderen Server kreuzen, dh dem Slave von A auf B und dem Slave von B auf A. Wir haben mehrere Instanzen auf unseren Servern ausgeführt und hatten keine Probleme, da unsere MySQL-Server nicht voll ausgelastet waren. Ein Failover auf einen laufenden Server ist viel schneller als eine Wiederherstellung aus einer Sicherung.

Sabika
quelle