Die Vorteile contra die Unbilden von InnoDB

[Christian Kruse]

Hallo TS,

Ich habe bisher noch nicht herausgefunden, wie man nachträglich eine geschlossene InnoDB-Datenbankdatei in einzelne Tabellendateien zerlegen kann, so dass man sie LowLevel transferieren kann auf einen anderen DBMS-Server.

Warum möchtest du das? Vor allem: warum möchtest du das „in einzelnen Dateien?“

Es geht um shared Hosting, was man bei Datenbanken ja meistens hat - auch innerhalb eines Kunden-Accounts.

Meistens hat ist eine mutige Aussage ;-)

Ich will aber auch nicht für jeden "Kunden" einen eigenen DBMS-Server aufstetzen müssen. Also bin ich gezwungen, die irgendwie prallel auf dem DBMS-Server unterzubringen. Bei MyISAM war das alles kein Problem.

Warum sollte das ein Problem sein bei InnoDB? Ich habe dein Problem noch nicht verstanden.

Ich würde sie lieber logisch übertragen wollen (dump & restore), alles andere verursacht doch Downtimes.

Das ist auch nicht immer ohne weiteres möglich, wenn Trigger, Stored Procedures, Relational Restrictions, Select-History usw. benutzt werden.

Dafür liefert MySQL fertige Tools mit: mysqldump. Das sollte mit allem umgehen können.

Und da die Projekte, an die man unsere gtruppe ranlässt doch etwas kleiner als Facebook sind, sind die notwendigen Downtimes überschaubar kurz.

Ist dir bewusst, dass du für ein physikalisches Backup - auch bei MyISAM! - während des kopierens das DBMS herunterfahren musst, weil sonst die Dateien in einem inkonsistenten Zustand sein können?

Wie lange dauert das bei den Self-Servern, die Datenbank runter- und wieder raufzufahren?

Der reine Restart? 10 Sekunden vielleicht. Mit Backup? Keine Ahnung, ein Dump dauert etwa 10 Minuten. Ich verwende allerdings PostgreSQL.

LG,
CK