Meine Produktionsdatenbank enthält alle MyISAM-Tabellen, die auf einen Slave-Server repliziert werden. Wenn ich ein Backup durchführen muss, stoppe ich einfach den MySQL-Server auf dem Slave, kopiere die Tabellendateien und starte den Server dann erneut. Das hat jetzt mehrere Jahre lang gut funktioniert. Allerdings muss ich jetzt einige Tabellen auf meinem Master in InnoDB konvertieren, da ich einige Sperrprobleme habe. Ich glaube nicht, dass ich die Tabellendateien einfach auf den Slave kopieren kann. Ich habe ein paar Fragen:
Ist es eine gute Idee, MyISAM- und InnoDB-Tabellen in derselben Datenbank zu mischen? Tabellen unterschiedlichen Typs werden bei Verknüpfungen und anderen Vorgängen verwendet.
Sollte ich zwei Backup-Prozesse auf dem Slave haben – einen zum Sichern von MyISAM und den anderen für InnoDB-Tabellen? Das scheint mir ein ziemliches Durcheinander zu sein.
Kann ich die InnoDB-Tabellen auf dem Slave in MyISAM-Tabellen konvertieren und meinen bestehenden Backup-Prozess beibehalten? Kann eine InnoDB-Tabelle auf dem Master in dieselbe Tabelle im MyISAM-Format auf dem Slave repliziert werden?
Antwort1
Gemischte Tabellentypen sind in Ordnung, Sie sollten jedoch den Leistungsunterschied zwischen gemischten und reinen InnoDB-Tabellen für Ihre spezielle Anwendung prüfen.
Auch ohne Mischen von Tabellen empfehle ich, zur Sicherung einen Dump auszuführen. Das ist dem Kopieren der Dateien/Ordner weit vorzuziehen, da es die Migration auf einen anderen Server oder eine andere MySQL-Version vereinfacht.
Es gibt keinen Grund, dies in zwei separate Backups aufzuteilen.
Ich rate Ihnen dringend davon ab, das Tabellenformat auf dem Slave zu ändern, insbesondere wenn Sie Transaktionen verwenden. Wenn Sie die InnoDB-Tabellen beibehalten, verarbeitet der Slave die Transaktionen korrekt. Wenn Sie die Tabellen auf MyISAM ändern, können Sie möglicherweise Probleme verursachen, indem Sie Teiltransaktionen in das Backup einbeziehen, was bei einer Wiederherstellung wahrscheinlich nicht gut ist.