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

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).

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.

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.

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.)

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.

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.