Möglichkeiten zur automatischen Skalierung von MySQL-Servern?

Ich betreibe eine Site mit hohen Verkehrsschwankungen und aus diesem Grund sind automatische Skalierungslösungen für diesen Fall sehr profitabel. Derzeit kann der Webserver horizontal automatisch skalieren, der Engpass liegt jedoch auf dem MySQL-Server.

• Ich habe es mit Amazon RDS Multi-AZ versucht, aber es dauert ungefähr 15 Minuten, bis die 12-GB-Datenbank mit einigen Minuten Ausfallzeit aktualisiert ist. Es hat mir sehr geholfen, als ich bereits wusste, dass in einem bestimmten Moment ein Verkehrsanstieg eintreten würde.
• Ich habe auch über Xeround nachgedacht. Dies ist wahrscheinlich die beste Lösung, obwohl sie für Datenbanken dieser Größe ziemlich teuer ist. Auf jeden Fall ist dies keine Option, da ich die Datenbank legal in der Europäischen Union haben muss.
• Ich habe über Scalr gelesen, bin mir aber nicht sicher, ob und wie das hilfreich sein könnte.
• Ich habe gesehen, dass viele Cloud-Hosting-Anbieter vertikale Skalierungslösungen anbieten, die meiner Meinung nach keine Ausfallzeit haben (ich bin mir nicht sicher, ob dies wirklich möglich ist, soweit ich weiß, dass sie Xen-Hypervisor verwenden). Das könnte eine Lösung sein, aber ich frage mich, ob es keine Ausfallzeiten gibt und wie die MySQL-Konfiguration (und viele andere Dinge auf dem Betriebssystem) auch ohne Ausfallzeiten aktualisiert werden können.
• Ich habe es mit MySQL-Slave-Servern versucht, aber es war überhaupt nicht hilfreich.
• Ich benutze Memcache, was sehr hilfreich ist, aber nicht ausreicht. Ich muss wegen Schreibvorgängen aktualisieren, nicht nur wegen Lesevorgängen.

Irgendwelche Vorschläge? Vielen Dank im Voraus

Eine einfachere Lösung wäre es, Memcached zu Ihrem Stack hinzuzufügen, um DB-Last zu sparen. Dies kann drastisch Last sparen und ist viel einfacher als der Versuch, das Problem des schnellen Aufstehens von Servern (geringer Schwierigkeitsgrad) und der anschließenden schnellen MySQL-Synchronisierung (viel höherer Schwierigkeitsgrad) zu lösen.

http://toblender.com/?s=memcached

Um das Problem zu vieler Schreibvorgänge zu lösen, wird am häufigsten Speicher zum Server hinzugefügt (ein größerer Arbeitssatz kann im RAM gespeichert werden), Ihre Datenbank auf schnellere Festplatten gestellt (SSDs sind eine gute Lösung, aber teuer) oder Sharding (was bei zusätzlichen Servern und Komplexität teuer ist).

Eine andere Möglichkeit, die Schreiblast der Datenbank zu verringern, besteht darin, einen speicherinternen Datenspeicher (z. B. Redis) zu integrieren, um häufig wechselnde Daten zu verarbeiten, und bei Bedarf regelmäßig Änderungen in Ihre Hauptdatenbank zurückzuschreiben.

Sie sollten die Verwendung einer Sterntopologie in Betracht ziehen

Folgendes schlage ich vor

• One Write Master (auch bekannt als WM)
• Ein Distributionsmaster (auch bekannt als DM)
• Fünf (5) Read Slave Server (auch bekannt als RSS)

Bereiten Sie die Topologie wie folgt vor

Schritt 01: Richten Sie 5 RSS mit diesen allgemeinen Optionen ein

[mysqld]
skip-innodb
key_buffer_size=1G

Dadurch werden alle Tabellen erstellt und als MyISAM Storage Engine geladen

Schritt 02: DM und alle RS Server einrichten

• mysqldump das Schema aller Tabellen von WM in eine Schemaadump-Datei
• Laden Sie die Schemadump-Datei in DM und alle 5 RSS
• Führen Sie ALTER TABLE tblname ROW_FORMAT=Fixed;für alle Tabellen in RSS aus
• Führen Sie ALTER TABLE tblname ENGINE=BLACKHOLE;für alle Tabellen in DM aus
• Nur mysqldump-Daten (mit --no-create-info) zu einem Datadump
• Laden Sie den Datadump in alle 5 RSS

Schritt 03: Replikation einrichten Von DM auf alle 5 RSS

Schritt 04: Replikation von WM nach DM einrichten

Ende des Setups

So funktioniert Ihr Lese- / Schreibmechanismus

• Alle Ihre Schreibvorgänge (INSERTs, UPDATEs, DELETEs) erfolgen im WM
• SQL wird in den Binärprotokollen des DM aufgezeichnet (in DM befinden sich keine tatsächlichen Daten)
• Jeder RSS ist ein Read Slave für den DM
• Alle Ihre Lesevorgänge erfolgen beim RSS

Jetzt ist hier der Haken ...

• Sie verwenden RSS 1-4 zunächst für Lesevorgänge
• Verwenden Sie das 5. RSS, um andere RSS zu starten
  • Sie laufen service mysql stopbeim 5. RSS
  • Drehen Sie ein weiteres RSS hoch
  • Kopieren Sie / var / lib / mysql und /etc/my.cnf des 5. RSS in das neu gesponnene RSS
  • Sie laufen service mysql stopbeim 5. RSS
  • Sie laufen service mysql stopbeim neuen RSS

Mit RSS # 5 können Sie immer wieder neue Server hochfahren

Nebenbei bemerkt, verwenden Sie XEROUND nicht für WM oder DM, da diese die InnoDB- oder BLACKHOLE-Speicher-Engine nicht unterstützen.

Ich hoffe diese Ideen helfen.

Wenn Sie Innodb verwenden, sollten Sie MySQL-Multi-Master in Betracht ziehen, die von Galera verwaltet werden . Dies erleichtert das Einrichten von MySQL-Multi-Master und sollte es Ihnen erleichtern, die automatische Semi-Skalierung durchzuführen.

Wenn dies eine Anwendung ist, die Sie oder Ihr Unternehmen schreiben, können Sie in Betracht ziehen, zu einem Sharded-Design (partitioniert) für die Anwendung zu wechseln. Aber Scherben können kompliziert werden. Hier ist ein Link , um Ihnen den Einstieg zu erleichtern.

Ich gehe davon aus, dass Sie die MySQL-Konfigurationsdateien "optimiert" haben, wie im zugewiesenen entsprechenden Speicher usw.

Befindet sich dies in einem Rack, das Sie steuern, oder befindet es sich in der Cloud? 12 GB ist eine sehr kleine Datenbank im Verhältnis zur Größe der verfügbaren Festplatten. Wenn Sie es auf ein RAID1- oder RAID10-Array kleiner SLC-SSDs legen, verschwindet Ihre Schreiblatenz.

Die 20-GB-SLC-SSD der Intel 311-Serie (jeweils 120 US-Dollar) würde diese Aufgabe hervorragend erfüllen.

Wenn die Datenbank größer wäre, könnten Sie ähnlich spektakuläre Ergebnisse erzielen, indem Sie Ihre Datenbank auf ein iSCSI-Ziel auf einem ZFS-SAN-Server verschieben (basierend auf Standard-Serverhardware mit Nexenta, OpenIndiana, FreeNAS oder was auch immer) und einen Spiegel ähnlicher SSDs für einrichten Ihr ZIL-Schreibcache. Mit Ausnahme der außergewöhnlichsten Umstände ist Gigabit-Ethernet mehr als ausreichend, um den iSCSI-Datenverkehr der Datenbank zu verschieben.