mysqldump: Import schlägt fehl

[s24!]

Guten Morgen,

ein paar Datenbanken (in dem Fall ca. 6500 Stück) zu dumpen und auf einem anderen Server wieder einzuspielen, übersteigt meine Kompetenzen in aller Regel nicht. Heute ist aber irgendwie der Wurm drin - umgezogen werden sollen die DBs von einem Debian Squeeze-Server mit MariaDB 5.2.14 auf einen Ubuntu 12.04-Server mit MariaDB 5.5.30:

root@web2:~# mysqldump -u root -p --all-databases | ssh root@web1 "cat > /ssd/fulldump.sql"

[...]

root@web1 /ssd # mysql -p < fulldump.sql
ERROR 1054 (42S22) at line 2203219: Unknown column 'source' in 'NEW'

Nach etwas googeln bin ich auf einen Blogeintrag gestoßen:

To fix this problem [To make Linux case insensitive] add the following line in the file /etc/mysql/my.cnf
lower_case_table_name = 1
This line make MySql case-in-sensitive in linux environment.

Das habe ich sowohl auf dem Quellsystem als auch auf dem Zielsystem als auch gleichzeitig auf beiden probiert - Fehlanzeige. Unabhängig davon bin ich unsicher, ob das nicht nach dem "Umschalten" aufs neue System massenhaft Probleme mit den Anwendungen gegeben hätte.

Ein Gedanke war, dass es am Versionssprung und/oder Betriebssystemwechsel liegen könnte. Allerdings sollten etwaige Probleme in dem Fall doch eigentlich nur auftreten, wenn man sich die Binärdaten kopiert - nicht aber bei einem Dump, oder? Hat jemand eine Idee?


Viele Grüße
Tim

 

[Deleted member 11740]

Mit sed drüberjagen und den Fehler korrigieren.
Natürlich am Backup der Datei.

Hab hier noch was gefunden: http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Muss jetzt arbeiten..

 

[s24!]

Danke für deine Antwort!

Mit sed drüberjagen und den Fehler korrigieren.
Natürlich am Backup der Datei.

Ich weiß ja nicht im Voraus, welche Fehler auftreten. Daher wäre es in meinen Augen eher sinnig, das eigentliche Problem zu beheben... Irgendwas scheint ja beim Im-/Export schiefzulaufen.

Hab hier noch was gefunden: http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

?
Siehe oben: Längst ausprobiert.

 

[Joe User]

Schauen wir uns die bemängelte Zeile doch erstmal an:

sed '2203219q;d' fulldump.sql

 

[s24!]

Gute Idee. Hatte ich auch schon gemacht, aber beim Posten war's dann wohl schon etwas spät...

root@web1 /ssd # sed '2203219q;d' fulldump.sql
/*!50003 CREATE*/ /*!50017 DEFINER=`anacleto01_ext`@`%`*/ /*!50003 TRIGGER after_insert_on_magazz

Das Bemängelte kommt da doch gar nicht vor.


Grüße
Tim

 

[Joe User]

Dann halt die langsamere Methode:

egrep -n '(source|NEW)' fulldump.sql

 

[s24!]

Das ist hoffnungslos, die Ausgabe ist viel zu groß:

root@web1 /ssd # egrep -n '(source|NEW)' fulldump.sql | wc -l
83738

Ich werde jetzt mal einen Dump mit --skip-extended-insert ziehen, damit die Ausgabe etwas lesbarer wird...

// Das wird ja ewig dauern. :|

 

[s24!]

Leider werde ich nicht schlau draus:

root@web1 /ssd # mysql -p < fulldump.sql
ERROR 1054 (42S22) at line 64555008: Unknown column 'source' in 'NEW'

Zeile angucken...

root@web1 /ssd # sed '64555008q;d' /ssd/fulldump.sql
/*!50003 CREATE*/ /*!50017 DEFINER=`anacleto01_ext`@`%`*/ /*!50003 TRIGGER after_insert_on_magazz

Wie erwartet wie vorher. Machen wir uns die bessere Lesbarkeit der Datei zu Nutze. =) Schuld scheint ja irgendeine DB des Nutzers anacleto01 zu sein.

root@web1 /ssd # grep "anacleto01" fulldump.sql
-- Current Database: `anacleto01sql1`
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `anacleto01sql1` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `anacleto01sql1`;
[B]/*!50003 CREATE*/ /*!50017 DEFINER=`anacleto01_ext`@`%`*/ /*!50003 TRIGGER after_insert_on_magazz[/B]
/*!50003 CREATE*/ /*!50017 DEFINER=`anacleto01_ext`@`%`*/ /*!50003 TRIGGER before_update_on_magazz
[...]

Dort finden wir wieder die "schuldige" Zeile, demnach scheint es ein Problem mit der DB anacleto01sql1 zu geben.

root@web1 /ssd # egrep -n 'anacleto01sql1' fulldump.sql
64554851:-- Current Database: `anacleto01sql1`
[...]

Das Problem müsste demnach zwischen Zeile 64554851 und Zeile 64555008 liegen. Aus der Differenz der beiden Zahlen ergibt sich:

root@web1 /ssd # head -n64555008 fulldump.sql | tail -n157 | egrep -ni "(source|new)"
[keine Ausgabe]

Bin ich der einzige, der das nicht versteht?


Grüße
Tim

 

[s24!]

Ich habe mal etwas weiter "geforscht", komme aber nicht weiter. Im Gegenteil, es verwirrt mich noch mehr, aber erstmal der Part des Dumps der ihn stört:

/*!50003 CREATE*/ /*!50017 DEFINER=`anacleto01_ext`@`%`*/ /*!50003 TRIGGER after_insert_on_magazz
AFTER INSERT
ON magazz FOR EACH ROW
BEGIN
        IF NEW.quantita != 0 THEN
                [B]CALL updateStock( NEW.codicearticolo, NEW.source );[/B]
        END IF;
END */;;

Das Fettgedruckte markiert das, was wohl das Unknown column 'source' in 'NEW' erzeugt.

Weiter im Text - ich habe versucht, den Dump der "störenden" Datenbank auf dem aktuellen MySQL-Server einzuspielen, um Probleme mit der neuen Maschine ausschließen oder eben belegen zu können:

root@web2:~# mysql -u testdb -p testdb < anacleto01.sql
ERROR 1227 (42000) at line 168: Access denied; you need the SUPER privilege for this operation

Zeile 183 ist die erste Zeile aus dem vorherigen Zitat.

Die Fehlermeldung ist insofern komisch, als dass der Kunde mit dem benutzen MySQL-Account somit offenbar schon mal mehr Rechte als ein normaler Datenbanknutzer hat. Und tatsächlich hat sein oben erwähnter Account 'anacleto01_ext' (Account für externen Zugriff) auch GRANT-Rechte, sonst kann ich keine Unterschiede zu den Accounts erkennen, die beim Anlegen einer Datenbank für ebendiese erstellt werden.

Wie auch immer, root darf ja alles, also spielen wir mal root... Es könnte ja Kompatibilitätsprobleme geben (obgleich ich das bei einem Dump für annähernd unmöglich halte, sofern man nicht gerade als Ziel eine MySQL < 5.4-Büchse hat...

root@web2:~# mysql -u root -p testdb < anacleto01.sql
ERROR 1054 (42S22) at line 168: Unknown column 'source' in 'NEW'

... Gleiche Fehlermeldung wie beim Import auf web1, dem neuen Server. Was heißt das jetzt? Aus meiner Sicht wurde hier irgendwas angelegt, was eigentlich nicht angelegt werden kann, oder so ähnlich...

Leider kenne ich mich mit SQL an sich auch nicht besonders gut aus; oder zumindest nicht gut genug, um hier den Fehler zu finden - aber irgendwer muss doch mehr wissen als ich?


Viele Grüße & danke im Voraus
Tim

 

[Mr.Check]

Naja die Meldung besagt ja, dass es in der Tabelle "NEW" keine Spalte "source" gibt.

Poste doch bitte mal den Part, in dem die Tabelle angelegt wird.

 

[s24!]

Es gibt keine solche Tabelle. Das verwirrt mich jetzt nicht weniger.

Ich bin wahrlich kein SQL-Profi - aber sollte es nicht so sein, dass zu einer Tabelle gehörende Trigger mit dem Löschen der Tabelle ebenfalls verschwinden? Also aus rein logischer Sicht wäre das.. logisch.