Slave meckert wg. fehlenden Tabellen

[knebb]

Yohoo!

Ich habe hier etwas, das ich nicht verstehe. Und zwar mache ich eine Master-Slave Replikation.
Master ist MySQL 5.0.45-7.el5 (CentOS 5.2) 64bit
Slave ist MySQL 5.0.45-7.el5 (CentOS 5.2) 32bit
Die Replikation laeuft ueber eine 2Mbit Standleitung via VPN. Auf dem Server ist nicht viel los, da reicht die Leitung eigentlich dicke.
Ich starte die Replikation wie folgt:
Master

Code: Select all

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysqld-bin.000004 |       98 |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Dann sichere ich alle Datenbanken (ausser der mysql) mittels tar: tar cjpvf /master.tar.bz2 db1 db2 db3 und kopiere die Datei zum Slave.
Und dann kommt ein

Code: Select all

UNLOCK TABLES;

Slave

Code: Select all

service mysqld stop; #(loesche auch noch ggf. existierende Slave-Datenbankverzeichnisse)
tar xpjvf /master.tar.bz2
mysqld_safe --skip-slave-start &
[...]
mysql> RESET SLAVE;

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='mysqld-bin.000004',
    ->     MASTER_LOG_POS=98;
START SLAVE;

Zur Ueberpruefung dann das folgende:

Code: Select all

mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: master.dom.ain
                Master_User: slave1
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysqld-bin.000004
        Read_Master_Log_Pos: 98
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 236
      Relay_Master_Log_File: mysqld-bin.000004
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 98
            Relay_Log_Space: 236
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.01 sec)

Ist also alles in Ordnung, oder? Jetzt will ich den Slave sichern:

Code: Select all

[root@mysql mysql]# mysqldump --opt -u root -p --all-databases > mysql.dump
Enter password:
mysqldump: Got error: 1146: Table 'gallerie.g2_EventLogMap' doesn't exist when using LOCK TABLES

:evil:
Und im Verzeichnis /var/lib/mysql/gallerie sieht das so aus:

Code: Select all

[root@mysql gallery]# ls |grep -i event
g2_EventLogMap.frm
g2_SequenceEventLog.frm
g2_SequenceEventLog.MYD
g2_SequenceEventLog.MYI

Auf dem Master uebrigens die gleiche Dateistruktur. Da funktioniert der mysqldump Befehl aber wunderbar :roll:

Weiss jemand, warum das nicht sauber ist oder was ich machen kann?

[knebb]

Solltest ggf. die Tabelle analysieren und danach reparieren.

Aber auf dem Master ist sie doch (scheinbar) in Ordnung. Da meckert mysqldump eben nicht.

[oxygen]

Du solltest nicht die Datenbankdateien kopieren, sondern ein Dump machen. Das kannst du auch direkt On-the-fly einspielen, z.b. mit
mysqldump -hlocalhost --opt db1 | mysql db1 -handererhost

[knebb]

Du solltest nicht die Datenbankdateien kopieren, sondern ein Dump machen. Das kannst du auch direkt On-the-fly einspielen, z.b. mit
mysqldump -hlocalhost --opt db1 | mysql db1 -handererhost

Ich kann das im Laufe des Tage mal ausprobieren, glaube aber nicht so recht dran, denn da sprechen alle anderen Quellen deutlich eine andere Sprache, z.B. hier:
http://www.tecchannel.de/server/sql/429 ... ndex9.html

[knebb]

Man fährt die Db runter, dann kann man meinetwegen die Tabellen kopieren und dann fährt man diese wieder hoch.
Braucht zwar eine kurze downtime, dafür sind die Daten auch konsistent.

Sollte genau dafuer nicht "FLUSH TABLES WITH READ LOCK" zustaending sein? NAja, dann habe ich da wohl etwas falsch verstanden.

DB wurde weder auf dem Slave noch auf dem Master gestoppt aber mindestens eine nicht gestoppt, als man die Db Files kopiert hat.
Dass das dem Master nicht juckt ist klar. Aber der Client hat hinterher keine korrektes Datenfile.

MAster war nicht gestoppt, aber mit obigem Befehl "angehalten". Slave war gestoppt. Hatte heute wenig Zeit, werde mich da evtl. heute Abend mal dransetzen.

Frage noch: Wenn ich das also ueber Kopieren machen will, muss ich also den Master komplett stopen- aber wie kriege ich dann die binlog Position raus? SHOW MASTER STATUS geht ja nicht, ist ja kein Server aktiv.

[knebb]

zuerst Tabellen locken,

Done: FLUSH TABLES WITH READ LOCK;

Die logposition ermitteln,

Done: mysql> SHOW MASTER STATUS;

Code: Select all

/etc/init.d/mysql stop

Done: service mysqld stop [waehrend mysql-Client noch hochgefahren war]

Datendateien kopieren.

Done: tar cjpvf /root/master.tar.bz2 db1 db2 db3 [ausser der mysql Datenbank]

DB auf dem Salve starten.

Du meinst "Master", richtig? Done: service mysqld start
Dann fehlt noch das Einspielen der Dateien auf dem Slave:

Code: Select all

scp root@master:/root/master.tar.bz2 /root
cd /var/lib/mysql
service mysqld stop
tar xjpvf /root/master.tar.bz2
mysqld_safe --skip-slave-start &
mysql> RESET SLAVE; 
mysql> CHANGE MASTER TO MASTER_HOST='master.doma.in', MASTER_USER='slave1', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysqld-bin.000005', MASTER_LOG_POS=98;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
[...]

So sollte das stimmen, oder?

Dennoch bleibt der gleiche Fehler, der auf dem Master nicht auftritt:
Master

Code: Select all

[root@master mysql]# mysqldump --opt -u root -p --all-databases > mysql.dump
Enter password:
[root@master mysql]#

Slave

Code: Select all

[root@slave mysql]#  mysqldump --opt -u root -p --all-databases > mysql.dump
Enter password:
mysqldump: Got error: 1146: Table 'gallerie.g2_EventLogMap' doesn't exist when using LOCK TABLES
[root@mysql mysql]#

Was ich halt nicht verstehe: Selbst wenn die Tabelle wirklich defekt sein sollte- warum meckert der Master nicht rum? Es ist doch jetzt wirklich eine reine Binaerkopie der DB-Files.

Wie kann ich sowas (ohne PHPMyAdmin) ueberpruefen?

[Joe User]

Einfach mal http://www.rootforum.org/forum/viewtopi ... 04&t=39167 insbeondere http://www.rootforum.org/forum/viewtopi ... 67#p302387 lesen...

[knebb]

Einfach mal http://www.rootforum.org/forum/viewtopi ... 04&t=39167 insbeondere http://www.rootforum.org/forum/viewtopi ... 67#p302387 lesen...

Hmmm....mache ich das mit

Code: Select all

mysqldump --opt --master-data --lock-all-tables --triggers --routines --flush-logs --delete-master-logs  -u root -p --all-databases > mysql.dump

, funktioniert es ohne Fehlermeldung. Auf Master und Slave. :oops:

[knebb]

Du hast die Slave Db nicht runter gefahren *arg*.

Damit das wirklich eine eins zu ein Binär Kopie wird,
Fahre sowohl die Master Db als auch die Slave DB runter.

Mooooment, jetzt uebertrieb' mal nicht ;)
Solange wie die SlaveDB runtergefahren wird, BEVOR man die Binaerfile einspielt, ist das allemal gut!

dann versuche es ohne zippen und co per rsync -avz z.b oder scp.

Mooooment, jetzt uebertrieb' mal nicht ;) :D Warum sollte das mit tar nicht gehen? Ob ich das nun per rsync oder tar mache...ich kann ja gerne mal die md5sum der jeweiligen Dateien vergleichen (solange die DB noch unten sind) und wette, dass die identisch sind.

Beide Datenbank down ganz wichtig.

In dem Moment, wenn man auf die DB-Files zugreift, das war mir (zumindest fuer Slave) von Anfang an klar.

Warum also der Client meckert und der Master nicht?
Ich will es mal so sagen:

Aber mit Deinem Vergleich hast Du es doch gut ausgedrueckt- solange der MAler davorsteht. Aber genau das tut er doch nicht, wenn die (Master)DB runtergefahren ist. Und dennoch fehlt die "Kleinigkeit". Warum? Das Filehandle ist definitiv geschlossen.
Und auch wenn das Filehandle mit gestarteter DB noch geoeffnet ist, sollte es doch keine nicht abgeschlossenen Transaktionen geben, da man das ja mit "FLUSH TABLES" verhindert hat, oder wofuer ist dieser Befehl sonst da?

[knebb]

Dann mach doch mal den MD5 Vergleich der MYD MYI und frm Datei der betroffenen Tabelle.

Gerade gemacht und das Ergebnis ist so, wie ich es erwartet habe: Die Dateien sind 100%ig identisch. Sowohl vom Inhalt (md5sum) also auch von den Attributen her.

Tar und co, verändern ürigens Deine Daten.

Soso. Quelle? DAS waere mir absolut neu. Wo tar eigentlich das alt eingestammte Backup Tool unter Unix ist. Was meinst du, warum so viele Backups ueber tar laufen?

Ein untar sollte zwar den Orginalzustand wieder herstellen, aber das hängt immer von der Qualität des Codes ab.

Von wessen Code? tar? [-X Jetzt werden wir aber leicht esoterisch, oder? Und warum sollte tar Dateiinhalte veraendern und scp/ rsync nicht? Nenene, diese Schiene fahre ich nicht mit! =;

Wo ist die index und auch die Datendatei für die Tabelle g2_EventLogMap?

Das war mir ja auch aufgefallen, deshalb habe ich es ja gleich im ersten Post geschrieben. Ist die Tabelle defekt? Warum existieren die Dateien nicht? Wie mache ich das mit REPAIR?

[knebb]

1. tar verändert die Daten stell doch mal md5sum einer md5sum der orginalen gegenüber.

Also entweder reden wir aneinander vorbei oder hier geht es wirklich um Esoterik.
Was meinst Du, was ich gemacht habe, als ich schrieb

Gerade gemacht und das Ergebnis ist so, wie ich es erwartet habe: Die Dateien sind 100%ig identisch. Sowohl vom Inhalt (md5sum) also auch von den Attributen her.

Ich mag von MySQL nur sehr bedingt Ahnung haben- aber meine allgemeinen Administrationshausaufgaben habe ich gemacht. Du willst mir jetzt nicht ernsthaft erzaehlen, dass am Ende eines Kopiervorganges ueber tar, bzip2, scp, bzip2, tar etwas anderes rauskommt, als man reingesteckt hat, oder? :-k

Oder wie soll das komprimiern sonst klappen mit physischer Kraft?

Komprimieren <> Kopieren. Das Eine hat mit dem Anderen nichts zu tun.

Mit Esoterik hat das nichts zu tun sondern mit Informatik wenn beim "kopieren" mit scp Eingabe = Ausgabe bleibt.

Aha. Und bei tar nicht? Dann pipe eine tar Ausgabe dochmal in ein anderes tar rein und vergleiche Ein- und Ausgbae:

Code: Select all

tar cf - /etc | tar xvf - -C /backup

Und ein Blick in die Release Notes mreicht manchmal, um wenigstens zu erkennen, dass die "niemals Fehler machende Anwendung" auch schon mal Bugs hatte.

Diese Argumentation zieht definitiv nicht- oder meinst Du, Deine Aussage gilt nicht fuer rsync und scp?

Die Befehle analyze, check und repair findest Du in der Mysql Doku.

Alles klar, schaue ich mir mal an.

Wenn MYI, MYD nicht vorhanden sind, kann der Tabellentyp durchaus innodb sein.

Warum sollte man eine Tabelle innerhalb der gleichen Datenbank anders machen? Macht sowas Sinn? Waere aber zumindest recht aussergewoehnlich, oder? Ne, ich glaube, da ist was faul.

Hast Du in dem Falle, auch die innodb Datenfiles kopiert?

Welche Syntax die auch immer haben moegen- ich habe das ganze Verzeichnis kopiert. Mit allem, was drinnen war.

[knebb]

Das mit dem tar diskutieren wir ein ander mal und ich liefer dir praktische Beispiele, warum das untar auf der gegenseite nicht das gleiche Ergebniss liefern muss als das tar auf der anderen.

Lass es mich wissen- das wuerde mich ernsthaft interessieren!

Back to topic:
Keine InnoDB vorhanden.
So, die erste Analyse erbrachte kein sinnvolles Ergebnis:
Master

Code: Select all

mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p
[...]
gallerie.g2_EventLogMap                             OK
gallerie.g2_ExifPropertiesMap                       OK
gallerie.g2_ExternalIdMap                           Table is already up to date

Die erste ist die Tabelle, die auf dem Client immer Sorgen macht. Und wo auch die M* Dateien "fehlen". Ergebnis: "OK".
Slave

Code: Select all

mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p
[...]
gallerie.g2_EventLogMap
error    : Table 'gallerie.g2_EventLogMap' doesn't exist
gallerie.g2_ExifPropertiesMap                       Table is already up to date
gallerie.g2_ExternalIdMap                           Table is already up to date

Repairing tables
gallerie.g2_EventLogMap
error    : Table 'gallerie.g2_EventLogMap' doesn't exist

Jetzt bin ich so schlau wie zuvor. :-s
Tabelle scheint kaputt zu sein. Aber nur auf dem Slave. Bloss: Warum? Und wie fixen?

[knebb]

Es ist doch klar, wenn die Tabellendefinition aus der frm nicht mit den Daten aus der ggf. innodb überein stimmt, kann die DB damit nichts anfangen!
Poste doch bitte mal die my.cnf der master DB.

Jo, ist tatsaechlich eine InnoDB whistle :oops:

Code: Select all

[root@master ~]# mysqlshow gallerie g2_EventLogMap -uroot -p -i
Enter password:
Database: gallerie  Wildcard: g2_EventLogMap
+----------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+----------------------+
| Name           | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation       | Checksum | Create_options | Comment              |
+----------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+----------------------+
| g2_EventLogMap | InnoDB | 10      | Compact    | 9    | 1820           | 16384       | 0               | 16384        | 0         |                | 2009-03-25 21:33:39 |             |            | utf8_general_ci |          |                | InnoDB free: 4096 kB |
+----------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+----------------------+

Hier die my.cnf:

Code: Select all

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
bind-address = 127.0.0.1

#Following entries for MASTER DB
log-bin
server-id=1

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
bind-address = 127.0.0.1

Sind denn überhaupt Inhalte in der Problemtabelle?

Gem. obiger Ansage schon.

[knebb]

Ist das alles?
Die my.cnf?

Ja.

gut, dann hilft es nur auf dem Quellsystem mal den inhalt aus /var/lib/mysql zu posten dort muss die innodb Datei liegen.

:-$ :oops: whistle

Code: Select all

#ls -l /var/lib/mysql
drwx------ 2 mysql mysql    12288 Mar 25 21:13 gallerie
-rw-rw---- 1 mysql mysql 10485760 Mar 25 21:47 ibdata1
-rw-rw---- 1 mysql mysql  5242880 Mar 25 21:47 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Jan  9 20:33 ib_logfile1
[...]

:-({|=
Ok, tar um "ib*" ergaenzt und das Ganze von vorne. Siehe da, ploetzlich geht alles :D/

Man! Auf die Idee muss man erst mal kommen, dass EINE Tabelle anders angelegt ist- und diese dann auch noch ausserhalb des "normalen" Datenbankfolders liegt....

Sehe ich das richtig, dass es allerdings immer nur _genau_ eine InnoDB innerhalb MySQL gibt, die dann alle entsprechenden Tabellen enthaelt?

D.h. mit Innodb kann man dieses Binaerkopieren nicht machen, sondern muss immer ueber mysqldump gehen, richtig? Zumindest dann nicht, wenn der Slave auch ein paar InnoDB Tabellen hat, die er selbst betreibt, also nicht als Slave.

[knebb]

Also 1. Hau dem DBA eine auf die Nuss oder kümmere Dich um eine vernünftige my.cnf.
Das ist meiner Meinung nach definitiv zu mager.
Aber defaultwerte reichen ja bekannterweise.

[-( Nene- das mit der Nuss tut mir sonst weh! ;)
Und ja, in diesem Fall reichen die Defaultwerte wohl aus. Auf der DB passieren im Monat vielleicht eine Handvoll Schreibvorgaenge und taeglich vielleicht 10-20 Lesevorgaenge. Du wirst mir sicherlich bestaetigen, dass es der Default hier wunderbar tut.
Auf der Slave passiert mehr- die hat noch eine zusaetzliche DB, auf der schon einiges mehr passiert- alls fuenf Minuten. Allerdings habe ich auch hier nicht den Eindruck, dass das Teil lahmt.

2. Es kann bis zu 2 Innodb Files geben.

Alles klar, Danke fuer die kurze Erklaerung.

Setz eine Oracle DB 8.0 / 9.0 auf z.B. Mac oder neuer Linux Umgebung auf.
Packe die Datafiles, mit dem dort vorrätigen tar.
Kopiere es auf eine z.B. Solaris 7 oder 8 da bin ich mir nicht 100% sicher.
entpacke es mit dem dort verfügbaren tar. Die DB komt in 30% aller Fälle nicht mehr hoch, ein md5sum bestätigt dies.

Solaris ist in der Tat ein Sonderfall, da Sun -wie die meisten anderen "richtigen" Unixe- eben nicht die GNU Tools als Standard setzen, sondern eigene Variationen. Das kann das in der Tat vorkommen. Kann Dir aber auch bei openssh/ scp passieren. Hatte ich auch schon, dass die Keys (oder waren es die Algorithmen?) und die Kommandozeilenparameter nicht kompatibel waren ](*,)
GNUtar rein=GNUtar raus.

[daemotron]

InnoDB hat mindestens zwei Dateien (ibdata und ib_logfile). Diese haben eine feste Größe. Ist ein File voll, wird das jeweils nächste begonnen (ibdata2, ...). Die Möglichkeit, pro Tabelle ein Datafile anzulegen, existiert auch in 5.0 schon.

Genaueres weiß Kris - und dankenswerter Weise teilt er sein Wissen auch:
http://blog.koehntopp.de/archives/1985- ... ngine.html
http://blog.koehntopp.de/archives/1997- ... ation.html

[isotopp]

Sollte genau dafuer nicht "FLUSH TABLES WITH READ LOCK" zustaending sein? NAja, dann habe ich da wohl etwas falsch verstanden.

Ist es. Aber die Tables sind trotzdem gecrashed. MyISAM-Benutzer haben bitte myisam_recover=FORCE,BACKUP und myisam_recover_threads=1 in der my.cnf, sonst bumm.

[isotopp]

Du hast die Slave Db nicht runter gefahren *arg*.

Auch das ist - bei MyISAM - nicht schlimm, wenn es die Zieldatenbanken oder -tabellen auf dem Zielserver nicht gibt. Der Punkt ist, daß der Zielserver kein Filehandle in einer der kopierten bzw. überschriebenen Dateien offen haben darf. Wenn das der Fall ist, ist es dem Server unsagbar schnurz, ob Du ihm einen Haufen MyISAM-Dateien irgendwo bei laufendem Server reinschubst.

FLUSH TABLES macht alle Filehandles zu, und wenn Du garantieren kannst, daß bis zum Abschluß des Kopiervorgangs keine der kopierten Dateien wieder auf geht, ist alles gut.

Kris

[isotopp]

Ok, tar um "ib*" ergaenzt und das Ganze von vorne. Siehe da, ploetzlich geht alles :D/

Das ist eher Zufall.

InnoDB legt einen Tablespace an - der besteht aus der ibdata1-Datei ODER aus der ibdata1-Datei und der Summe aller ibd-Dateien. Ein Tablespace hat beim Anlegen in jeder seiner Dateien eine UUID. Es ist nicht möglich, Dateien verschiedner UUID in einem Tablespace zu mischen.

Wenn Du auf dem Master und dem Slave InnoDB Tablespaces unabhängig voneinander erzeugt hast, haben sie unterschiedliche UUIDs und Du kannst ibd-Dateien vom Master nicht physikalich zum Slave kopieren. Das ist gut so, denn das ist ein sinnvoller Schutzmechanismus, unten mehr.

Wenn Du den Slave dadurch erzeugt hast, daß du das ganze Datadir vom Master auf den Slave gemirrort hast, dann haben Master und Slave unglücklicherweise dieselbe InnoDB-UUID und Du kannst ibd-Dateien vom Master in den Slave kopieren. Das ist schlecht.

Das ist deshalb schlecht, weil selbst wenn Du ibd-Dateien hast, in der ibdata1 wichtige Daten stehen: Dort befindet sich das InnoDB Shadow Data Dictionary, das Undo-Log, der Doublewrite-Buffer und die Insert Merge Buffer.

Für uns ist erst einmal das Shadow Data Dictionary wichtig: InnoDB war mal eine eigenenständige Datenbank mit einem eigenen SQL-Parser, einem eigenen Data Dictionary und was sonst so dazu gehört. Sie wurde recht brutal in MyISAM integriert und auch heute ist es noch so, daß InnoDB etwa eine eigene Speicherverwaltung hat und auch sonst Datenstrukturen in MyISAM dupliziert. Dazu gehört auch, daß Daten aus .frm-Dateien von MySQL in InnoDB-eigenen Datenstrukturen dupliziert werden - das Data Dictionary.

Es ist also möglich, eine .frm-Datei zu haben, die den Typ InnoDB angibt, aber InnoDB weiß nix von der Tabelle. Es ist genau so möglich, eine Tabelle in InnoDB zu haben, zu der die .frm-Datei fehlt. Und es kann sein, daß die Defintionen einer Tabelle in MySQL und InnoDB einander widersprechen. In jedem von den drei Fällen gibt es mehr oder weniger kaputte Reparaturmechanismen, aber im Grunde bist Du im Arsch.

Und das ist genau das, wovor Dich die UUID zum Teil schützt - sie verhindert, daß Du eine .frm und .ibd in einen fremdem Server kopierst, wo sich im Data Dictionary KEIN Eintrag für die Tabelle befinden kann.

Sehe ich das richtig, dass es allerdings immer nur _genau_ eine InnoDB innerhalb MySQL gibt, die dann alle entsprechenden Tabellen enthaelt?

Lies die Artikel zu InnoDB, die ich geschrieben habe.

D.h. mit Innodb kann man dieses Binaerkopieren nicht machen, sondern muss immer ueber mysqldump gehen, richtig?

Exakt. InnoDB kann man nicht partiell kopieren.

[isotopp]

2. Es kann bis zu 2 Innodb Files geben. Das wird in der my.cnf gesteuert. Neuerdeings ist es auch möglich, für jede Tabelle ein eignes Innodb File zu haben.
Geht meines Wissens erst ab mysql 5.1.

Innodb_file_per_table geht schon mit 4.1 und 5.0. Es hat eine Menge Vorteile, einige Kosten und es macht in gewisser Weise falsche Hoffnungen.

Setz eine Oracle DB 8.0 / 9.0 auf z.B. Mac oder neuere Linux Umgebung auf. Packe die Datafiles, mit dem dort vorrätigen tar. Kopiere es auf eine z.B. Solaris 7 oder 8 da bin ich mir nicht 100% sicher. Entpacke es mit dem dort verfügbaren tar. Die DB kommt in 30% aller Fälle nicht mehr hoch, ein md5sum bestätigt dies.

Das ist unter anderem ein Wechsel der Endianness von einer Intel (LSB first) auf eine Sparc (MSB first) Architecture. Ich habe keine Ahnung wie Oracle auf so was reagiert, aber InnoDB und MyISAM ist invariant gegenüber der Endianness und der Wortlänge der Architektur - Du kannst InnoDB und MyISAM-Files von einer 32 Bit auf eine 64 Bit Kiste und von LSB auf MSB-Maschinen kopieren - kein Problem.

[isotopp]

Innodb_file_per_table geht schon mit 4.1 und 5.0. Es hat eine Menge Vorteile, einige Kosten und es macht in gewisser Weise falsche Hoffnungen.

Welche falsche Hoffnung meinst Du im Detail?

Die, daß einem eine einzelne ibd-Datei irgendwas nützen würde.

[isotopp]

Naja, sofern eine korrupt wird, ist nicht die ganze DB hops und mann kann zumindest den Dump dierser Tabelle wieder einspielen.

Nein. Die Tabelle hat vielleicht die richtige UUID, aber nicht den richtigen Transaktionszähler und wird abgelehnt. Erst mit dem InnoDB-Plugin 1.0.3 von InnoDB für 5.1 wird das gehen.

Lediglich eine Tabelle dropen, wenn man unnötig verbrauchten Speicherplatz wieder frei machen will.

Das ist der einzige derzeit erreichbare Vorteil.

Im extremfall könnte man die einzelnen Datenbanken entgegen der zentralen innodb Files auf unterschiedlichem Storage verteilen und somit eine höhere IO erreichen. ( Was ich dann auch eher als Verzweiflungstat ansehen würde)

Es gibt keinerlei Support dafür, und etwa nach einem OPTIMIZE wäre die Tabelle wieder lokal. Mit Thin Wide Striping fährst Du besser.

http://www.sun.com/blueprints/1000/layout.pdf

[isotopp]

Mit Thin Wide Striping fährst Du besser.

http://www.sun.com/blueprints/1000/layout.pdf

Man hat nicht immer die Chance eine Sun zu haben.

TWS ist eine Idee von einem Sunnie, aber man kann das mit beliebigen Systemen spielen. Ein korrekt aufgesetztes RAID-10 mit 6 oder mehr Spindeln und dann LVM drauf macht das mit einem passenden -I xxx -i xxx auch unter Linux leicht möglich.

Meine Überlegung war jedch externen Storage nach: /var/lib/mysql/<database> zu mounten.
Bzw. ich bin mir nicht mehr 100% sicher ob sich mysql dann am lost&found störte.

Stören nicht, aber Du bekommst lost+found dann als Database angezeigt, wenn Du das so machst (wenn Du ext[234] als Dateisystem nimmst, was auch noch andere Nachteile hat).

In meinem kleinen Reisebüro in Amsterdam machen das ein wenig anders. Da legen wir ein LV mit XFS drauf nach /mysql/<instanzname> und tun datadir nach /mysql/<instanzname>/data, die Binlogs nach /mysql/.../log und tmpdir nach /mysql/.../tmp. Wir können, es es Probleme gibt, das auch mit 2 oder 3 Dateisystemen direkt nach .../data, .../log und .../tmp fahren ohne Pfadnamen zu ändern.

Dadurch, daß /mysql/.../data normal nicht direkt eine Dateisystemroot ist, existieren Probleme mit lost+found nicht mal dann, wenn wir noch ext3 verwendeten.