Hallo und guten Abend, > Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten: > > [Tablespace Enabling](http://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) > > 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](http://dba.stackexchange.com/questions/11043/mysql-changing-innodb-file-per-table-for-a-live-db)) 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 -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Abend, > Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten: > > [Tablespace Enabling](http://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) > > 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](http://dba.stackexchange.com/questions/11043/mysql-changing-innodb-file-per-table-for-a-live-db) 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 -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Abend, > Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten: > > [Tablespace Enabling](http://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) > > 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. 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 -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Abend, > Du kannst, wenn das MySQL Handbuch nicht lügt, die Tabelle aus dem Shared Space herausspalten: > > [Tablespace Enabling](http://dev.mysql.com/doc/refman/5.7/en/tablespace-enabling.html) > > 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 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. 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 -- es wachse der Freifunk <http://freifunk-oberharz.de>