nicht angemeldet
Moin Sven,
Ich bin skeptisch, dass ein Wechsel der Engine den entscheidenden Performance-Gewinn bringt, so dass der Server wieder ausreichend Platz hat. Du solltest das aber zunächst im Labor nachstellen und dann mit Tools wie Apaches "ab" messen, ob sich die Anzahl der Requests pro Zeiteinheit steigern lässt.
Ein Wechsel der Storage-Engine kann enorm viel Potential haben, oder auch nicht. MyISAM hat kein vernünftiges Locking implementiert, jeder Schreibzugriff in einer Tabelle sperrt die gesamte Tabelle für parallele Lesezugriffe.
Hinzu kommt, dass mit InnoDB erst wichtige Features wie Transaktionen möglich werden. Ein Umstieg ist potentiell also immer sinnvoll.
Im Kern ist Replikation nur ein Doppelverarbeiten jeglicher schreibender SQL-Queries sowohl auf dem Master, als auch auf dem oder den Slaves.
Das ist eine Möglichkeit, Synchronisation zu betreiben.
Weil das Schreiben allerdings nicht zwingend sofort erfolgen muss, können die Slaves hinter dem aktuellen Datenbestand des Masters hinterherhinken - man arbeitet auf den Slaves also nicht zwingend mit aktuellen Daten.
Hier wirds komisch.
Das hängt stark von der verwendeten Replikations-Methode ab. Was du meinst, ist asynchrone Replikation. Da gibt es aber durchaus noch synchrone und die sog. „streaming replication.“ Bei der synchronen wird nach dem COMMIT gewartet, bis alle Slaves alle Daten geschrieben haben. Es wird also nie der Fall auftreten, dass du ein erfolgreiches COMMIT hast aber auf den Slaves veraltete oder unvollständige Daten. Bei der Streaming Replication wird ein gewisser Zeitraum (im Bereich von wenigen 100 Millisekunden) garantiert.
Natürlich werden durch synchrone Replikation die Schreibzugriffe massiv verlangsamt. Du kannst dafür aber problemlos die SELECTs auf Slaves verteilen.
Und dann gibt es da natürlich noch die diversen Ansätze von Multi-Master Replication mit ihren diversen Ansätzen von Konflikt-Behandlung.
Ohne zu analysieren, wo das Problem genau liegt, kann man keine pauschalen Hilfen anbieten.
Richtig.
LG,
CK