MySQL InnoDB-Tabellen auf einen anderen Host übertragen

[TS]

Hallo und guten Abend,

Datenbank vom lokalen Xampp auf einen Linux-Host übertragen - ohne Dump.

Leider klappt es nicht, wie ich es mit MyISAM sonst immer gemacht habe: einfach einpacken und auf auf dem anderen Host im data-Directory wieder auspacken.

Man muss da wohl irgendwie die ibdata#x-Dateien auch mitmehmen...

Die stehen aber nicht im Datenbankverzeichnis, sondern eine Ebene darüber, scheinen also Informationen/Daten für alle Datenbnbanken mit InnoDB-Tabellen zu enthalten.

Was muss ich tun, wenn ich keinen Dump ziehen will?

Grüße
TS

[TuLäte]

Hallo!

Was muss ich tun, wenn ich keinen Dump ziehen will?

Erst den Plan machen und dann das zu diesem passendende Subsystem wählen. Im Handbuch steht doch sehr deutlich, warum Dein Vorhaben nicht funktioniert und was rechtzeitig zu tun gewesen wäre.

TuLäte

[Mäibie Not]

Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten:

Tablespace Enabling

Da steht:

To move a table from the system tablespace to its own tablespace, change the innodb_file_per_table setting and rebuild the table:

SET GLOBAL innodb_file_per_table=1;
ALTER TABLE table_name ENGINE=InnoDB;

Tables added to the system tablespace using CREATE TABLE ... TABLESPACE or ALTER TABLE ... TABLESPACE syntax are not affected by the innodb_file_per_table setting. To move these tables from the system tablespace to a file-per-table tablespace, they must be moved explicitly using ALTER TABLE ... TABLESPACE syntax.

[TS]

Hallo und guten Abend,

Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten:

Tablespace Enabling

Da steht:

To move a table from the system tablespace to its own tablespace, change the innodb_file_per_table setting and rebuild the table:

SET GLOBAL innodb_file_per_table=1;
ALTER TABLE table_name ENGINE=InnoDB;

Tables added to the system tablespace using CREATE TABLE ... TABLESPACE or ALTER TABLE ... TABLESPACE syntax are not affected by the innodb_file_per_table setting. To move these tables from the system tablespace to a file-per-table tablespace, they must be moved explicitly using ALTER TABLE ... TABLESPACE syntax.

So ganz verstehe ich noch nicht, was da wann genau passiert. Ich muss leider auf beiden Hosts Hand anlegen.

Auf dem lokalen Host habe ich innodb_file_per_table = 1 nun aktiviert. Ein Kopieren der Tabellen mit create table <neu> like <alt>; und anschließendes insert into <neu> select * from <alt>, drop table <alt>, usw. ... erzeugt dann auch eine <neu>.frm und eine <neu>.ibd und zurück ....

Genau das Gleiche wird wohl auch bei einem alter table <alt> engine=InnoDB passieren. Warum aber einfach, wenn es auch umständlich geht ;-)

Aber wenn ich die beiden w. o. b. neu erstellten Files <alt>.frm und <alt>.ibd dann auf den anderen Host ins data-Verzeichnis kopiere (vorher beide Server runtergefahren, hinterher wieder hoch), werden die dort trotzdem nicht anerkannt. Mit show tables from <datenbank> werden sie zwar angezeigt, aber darauf zugreifen kann man nicht. Ein select führt zur Fehlermeldung "Tabelle nicht vorhanden" (o. ä.).

Für die einfachen Datenbanken, in denen keine Referenzen (referenzielle Integrität) benutzt wurden, kann ich mir erst einmal helfen, indem ich einfach auf MyISAM zurückkonvertiere. Die zugehörigen Tabellen kann ich dann nach dem altbelkannten Tarball-Zip->Copy->Unzip-Untar schnell verschieben. Die laufen dann auch anstandslos auf dem zweiten Host.

Und sie lassen sich dann auch schnell als Vollsicherung sichern!

Wenn ich das aber richtig verstehe, benötigt die Gesamt-Datenbank (mit den einzelnen Datenbanken drinnen) trotzdem noch die files ibdata1, ib_logfile0, ib_logfile1 für alle Teil-Datenbanken zusammen. Damit kann ich also nicht "mal eben schnell" die Daten einer Teildatenbank vorn einem Host zum anderen verschieben/kopieren. (siehe auch Beschreibung)

Bitte berichtigt mich, wenn das falsch ist.

Nun habe ich auf dem Zielhost eigentlich nur eine aktive Anwendung, die ich nicht auf MyISAM zurückfahren kann wegen der refenziellen Integrität => postfixadmin. Das ist K....!

Da ich für ein neues Projekt aber auch gerne die Vorzüge der in der DB verankerten Relations nutzen möchte, stehe ich jetzt ziemlich auf dem Schlauch. Da brauche ich noch reichlich Nachhilfe.

Grüße
TS

[TS]

Hallo und guten Abend,

Zusatzfrage:

Was geht bei der Konvertierung von InnoDB in MyISAM sonst noch verloren, außer der Foreign Key Contraints?

Wenn in der gesamten Teil-DB keine Constraints im Create-Code stehen, können je eigentlich auch keine vorhanden sein? Merkwürdigerweise sind nur ein paar Tabellen im InnoDB-Format, die anderen sind ohnehin MyISAM. Und die Angaben für Collation stehen fast alle auf latin_swedish_ci. Kommt davon, wenn man sich auf apt-get verlässt... ohoh

Da habe ich mir passend zu Weihnachten eine Baustelle reingeholt :-(

Grüße
TS

[Rolf b]

Du tust mir leid. Aber Tipps - außer Handbuch studieren, Tante Google ausquetschen und vielleicht noch Onkel Bing nerven - habe ich nicht. Hoffentlich kannst Du Heiligabend rechtzeitig noch YaHoo schreien.

[TS]

Hallo und guten Abend,

Du tust mir leid. Aber Tipps - außer Handbuch studieren, Tante Google ausquetschen und vielleicht noch Onkel Bing nerven - habe ich nicht. Hoffentlich kannst Du Heiligabend rechtzeitig noch YaHoo schreien.

Naja, eine Milliarde Datensätze habe ich zum Glück nicht drin in den Datenbanken. Da schreie ich dann lieber auch nicht so laut ;-)

Ich muss das mit InnoDB nochmal separat durchtesten. Dass damit soviele Ungereimtheiten verbunden sind, war mir nicht bewusst. Im Moment hilft mir wirklich der Schritt zurück zu MyISAM.

Grüße
TS

[Womöchlich nich!]

Hallo!

Im Moment hilft mir wirklich der Schritt zurück zu MyISAM.

Dann stellt sich die Frage, ob Du Transaktionen benutzen willst. Ist die Antwort "Ja", dann ist die Antwort auf die Frage, ob MyISAM das richtige Backend sei, ein klares "Nein".

[TS]

Hallo und guten Tag,

Im Moment hilft mir wirklich der Schritt zurück zu MyISAM.

Dann stellt sich die Frage, ob Du Transaktionen benutzen willst. Ist die Antwort "Ja", dann ist die Antwort auf die Frage, ob MyISAM das richtige Backend sei, ein klares "Nein".

siehste wohl, da woar doch außer Relations noch 'was anderes :-(

Grüße
TS

[Mitleser]

Dann stellt sich die Frage, ob Du Transaktionen benutzen willst. Ist die Antwort "Ja", dann ist die Antwort auf die Frage, ob MyISAM das richtige Backend sei, ein klares "Nein".

Die Antwort auf die Frage "MyISAM oder InnoDB?" lautet schon seit Jahren ziemlich pauschal "InnoDB", Ausnahmen wären nötige Features, die InnoDB nicht kann. Oder wg. mir auch irgendwelche Inkompatiblitäten alter Software. Sonst überwiegen die Vorteile deutlich, ich werfe nur mal row-level-locking in den Raum.

[pl]

hi,

Was muss ich tun, wenn ich keinen Dump ziehen will?

Master/Slave einrichten, gucken ob's läuft, Urlaub machen. In der Zeit sickern die Daten nach und nach und ganz spontan 'rüber auf den Slave /nurneidee

[TS]

Hallo und guten Tag,

Was muss ich tun, wenn ich keinen Dump ziehen will?

Master/Slave einrichten, gucken ob's läuft, Urlaub machen. In der Zeit sickern die Daten nach und nach und ganz spontan 'rüber auf den Slave /nurneidee

Nette Idee :-O

Leider trifft das nicht die Aufgabenstellung:

Auf Host A gibt es einen MySQL-Server.
.
Auf Host B gibt es einen MySQL-Server.
Auf Host C gibt es einen MySQL-Server.
Auf Host D gibt es einen MySQL-Server.
...
Auf Host X gibt es einen MySQL-Server.

Nun soll eine vorbereitete Datenbank aus dem DBMS des Host A in das DBMS des Host B übertragen werden.
Es soll eine andere vorbereitete Datenbank aus dem DBMS des Host A in das DBMS des Host D übertragen werden. usw.

Mit MyISAM geht sowas ohne Probleme. Nur weil hier im Forum mal irgend Jemand schrieb (sinngemäß) "MyISAM benutzt man doch nicht mehr, man nimmt heute InnoDB" haben wir uns leider darauf eingelassen.

Wenn man InnoDB nicht ohne die zentralen Dateien im DBMS benutzen kann, ist das für Multi-Client-Backup-Tasking totaler Schrott!

Schade eigentlich.

Grüße
TS

[Mitleser]

Wenn man InnoDB nicht ohne die zentralen Dateien im DBMS benutzen kann...

Kann doch womöglich sogar so konfigurieren, sagte ein anderer Poster.

..ist das für Multi-Client-Backup-Tasking totaler Schrott!

Wenn man für die Datenreplikation eines DBMS direkt im Dateisystem rummengt, ist das auch totaler Sch..., äh nicht so optimal. Bei großen Datenmengen tatsächlich Master/Slave, den Slave runterfahren und dumpen. Für kleine Datenmengen kann man auch direkt Dumpen.

Schade eigentlich.

Ja, genau.

[TS]

Hallo und guten Abend,

Wenn man InnoDB nicht ohne die zentralen Dateien im DBMS benutzen kann...

Kann doch womöglich sogar so konfigurieren, sagte ein anderer Poster.

Finde ich nett von Dir, dass Du nochmal genau erklären willst, wie es geht. Wann kann ich damit rechnen? Ich habe ja vermutlich dabei nur noch etwas falsch gemacht? Du zeigst mir jetzt, wie man es richtig macht ;-)

Grüße
TS

[Mitleser]

Wenn man InnoDB nicht ohne die zentralen Dateien im DBMS benutzen kann...

Kann doch womöglich sogar so konfigurieren, sagte ein anderer Poster.

Finde ich nett von Dir, dass Du nochmal genau erklären willst, wie es geht. Wann kann ich damit rechnen?

Finde ich ja nett von Dir, dass Du nochmal nachfragst, obwohl ich bereits auf den anderen Teilthread verwiesen habe. Ich habe keine Ahnung, wie man das konfiguriert, nur am Rande mitbekommen, dass es gehen soll. Bislang habe ich weder mit großen noch mit kleinen Datenmengen direkt im Dateisystem eines DBMS rumgemengt, wüsste auch nicht, wieso. Warum tust Du Dir das an?

[TS]

Hallo und guten Abend,

Warum tust Du Dir das an?

Weil ich nur einen MySQL-Datenbankserver auf meinem Host habe, damit aber für viele andere MySQL-Datenbankserver auf anderen Hosts Modelle und Programme erstellen muss. Die Datenbanken haben also nichts miteinander zu tun, außer, dass sie von einer Maschine bedient werden. Und auf den entfernten Hosts sieht das ähnlich aus. Die haben dort auch jeweils mehrere Datenbanken laufen, wollen mkir aber meistens nur eine bestimmte davon geben.

Wat nu?

Mit MyISAM ging und ghejt das auch noch immer wunderbar!
Da fehlen dann aber inzwischen diverse Features, wie im Thread schon mehrfach besprochen.

Grüße
TS

[Mitleser]

Warum tust Du Dir das an?

Weil ich nur einen MySQL-Datenbankserver auf meinem Host habe, damit aber für viele andere MySQL-Datenbankserver auf anderen Hosts Modelle und Programme erstellen muss. Die Datenbanken haben also nichts miteinander zu tun, außer, dass sie von einer Maschine bedient werden. Und auf den entfernten Hosts sieht das ähnlich aus. Die haben dort auch jeweils mehrere Datenbanken laufen, wollen mkir aber meistens nur eine bestimmte davon geben.

Was spricht konkret in Deinem Setup gegen mysqldump + import?

[TS]

Hallo und guten Tag,

Was spricht konkret in Deinem Setup gegen mysqldump + import?

Die Downtime ist zu lang.

Und ein Export / Import einer DB mit weit über 140 Tabellen, Funktionen, Triggers usw. mit voller Integrität hinzubekommen ist nicht so leicht, wie bei einer einzigen Tabelle.

Deine Fragen lassen mich jetzt aber ahnen, dass Du selber noch nie eine solche Aufgabe in der Praxis zu erfüllen hattest?

Grüße
TS

[Mitleser]

Hallo und guten Tag,

Was spricht konkret in Deinem Setup gegen mysqldump + import?

Die Downtime ist zu lang.

Zitat: "Bei großen Datenmengen tatsächlich Master/Slave, den Slave runterfahren und dumpen."

Und ein Export / Import einer DB mit weit über 140 Tabellen, Funktionen, Triggers usw. mit voller Integrität hinzubekommen ist nicht so leicht, wie bei einer einzigen Tabelle.

Deine Fragen lassen mich jetzt aber ahnen, dass Du selber noch nie eine solche Aufgabe in der Praxis zu erfüllen hattest?

Falsch geahnt.

[pl]

Mit MyISAM geht sowas ohne Probleme. Nur weil hier im Forum mal irgend Jemand schrieb (sinngemäß) "MyISAM benutzt man doch nicht mehr, man nimmt heute InnoDB" haben wir uns leider darauf eingelassen.

Nur weil irgend Jemand sowas schrieb? Hallo? Solche Phrasen sind doch absolut nichts wert, solange man das nicht selbst umfassend überprüft hat und zum gleichen Ergebnis kommt!

Das ist genau derselbe Stuss wie mit dem Design-Pattern und anderem Buzz-Geschwafel. Da werden ganze Doktorarbeiten darüber geschrieben aber in Wirklichkeit sieht doch die Praxis ganz anders aus, da sind nämlich nicht irgendwelche Entwurfsmuster entscheidend sondern Erfahrung und handwerkliches Geschick.

Es gibt 3 wesentliche Dinge, die ein Entwickler mitbringen sollte:

1. Kreativität,
2. Pioniergeist,
3. Leidenschaft.

Zu Punkt (3) könnte man auch sagen: Beharrlichkeit. Also lassen wir uns doch nicht beirren von irgendwelchen unhaltbaren Aussagen. Ein etwaiges So und nur so geht es ist für mich erst verbindlich, wenn ich selbst zu solch einem Ergebnis gekommen bin unter Anwendung obenstehender 3 Eigenschaften.

Na, ich geh dann mal'n Türchen aufmachen /pl

[1unitedpower]

Nur weil irgend Jemand sowas schrieb? Hallo? Solche Phrasen sind doch absolut nichts wert, solange man das nicht selbst umfassend überprüft hat und zum gleichen Ergebnis kommt!

Das ist genau derselbe Stuss wie mit dem Design-Pattern und anderem Buzz-Geschwafel.

Oh, die Ironie in diesen Sätzen.