schaffe keinen Datenbanktransfer

[TITAN3000]

Hallo,

ich wil ein paar Datenbanken (jeweils ca. 15 MB laut phpmyadmin) von einem MySQL zu einem anderen MySQL (auf einem anderen Server) kopieren.

Es handelt sich hierbei um Typo3- Datenbanken.

Mit dem tool mysql-dump hat der Export nicht besonders gut geklappt, er brachte mir eine Fehlermeldung und beendete... die esportierte .sql- Datei war nur wenige hunder kilobyte klein..

Anschließend hab ich die 3 Datenbanken mit phpMyAdmin exportiert, und jeweils ca. 8 MB große .sql - dateien bekommen.

Allerdings hab ich es bis jetzt noch nicht geschafft alle exportieren Datenbanken zum neuen mySQL zu importieren.

Nur bei einer Datenbank hatts problmelos geklappt.

Bei der einen Datenbank kommt es beim Import zu dem Fehler:

Fehler

Es scheint einen Fehler in Ihrer MySQL-Abfrage zu geben. Die MySQL-Fehlerausgabe, falls vorhanden, kann Ihnen auch bei der Fehleranalyse helfen.

ERROR: Unbekannte Interpunktion @ 6

STR: />

SQL:

<br />

<b>Warning</b>: mysql_free_result(): supplied argument is not a valid MySQL result resource in <b>/srv/www/htdocs/typo3_src-3.6.2/typo3/ext/phpmyadmin/modsub/phpmyadmin-2.5.6-rc1/libraries/export/sql.php</b> on line <b>246</b><br />

# --------------------------------------------------------

#

# Tabellenstruktur f�r Tabelle `cache_pagesection`

#

;

SQL-Befehl:

Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /srv/www/htdocs/typo3_src-3.6.2/typo3/ext/phpmyadmin/modsub/phpmyadmin-2.5.6-rc1/libraries/export/sql.php on line 246

# -------------------------------------------------------- # # Tabellenstruktur f�r Tabelle `cache_pagesection` # ;

MySQL meldet:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<br />

<b>Warning</b>: mysql_free_result(): supplied argument is not a valid My' at line 1

wenn ich die andere Datenbank importieren will, kommt´s zu diesem Fehler

Fehler

SQL-Befehl:

--

-- Daten f�r Tabelle `be_groups` --

INSERT INTO `be_g roups ` VAL UES( 1, 0, 1082672003, 'Redakteure ', 0x, '2,3,4, 5, 6, 1 ', 0x312c322c342c323534, 0x70616765732c74745f636f6e74656e742c74745f70726f64756374732c74745f70726f64756374735f636174, 0x70616765732c74745f636f6e74656e742c74745f70726f64756374732c74745f70726f64756374735f636174, 1082669267, 2, 0x7765625f6c61796f75742c7765622c7765625f766965772c7765625f6d6f64756c65732c7765625f6c6973742c7765625f696e666f2c7765625f7065726d2c7765625f66756e632c66696c652c66696c655f6c6973742c66696c655f696d61676573, '', 0, 1, '', '', 0, 0x61646d50616e656c207b0d0a202020202020656e61626c652e65646974203d20310d0a20202020202068696465203d20300d0a7d, 0x, 0 ) ;

MySQL meldet:

#1054 - Unknown column '0x' in 'field list'

Ich darf die original -datenbank nicht "berühren"... also auch nicht reparieren oder ähnliches

ich würde mich sehr über eure Hilfe freuen... langsam bin ich am verzweifelt, hab damit schon mein ganzes wochenende verbracht

[flashpixx]

Hi,

könntest Du es bitte mal mit "mysqldump" probieren und bitte die Fehlermeldung posten?.

Im Moment deutet die Meldung auf einen PHP Fehler hin. Ich würde beim Export die mySQL-Tools verwenden.

HTH Phil

[Amstelchen]

stooop. bitte mal ein bisschen übersicht reinbringen.

welche versionen von MySQL auf den *beiden* hosts?

welche versionen von PHPMyAdmin auf *beiden* hosts? beide 2.5.6-rc1?

du solltest einen export mittels mysqldump auch nur mit mysql importieren.

du solltest einen export mittels mysqladmin auch nur mit demselben importieren.

ist dem so?

dein dump hat im übrigen einige überschüssige zeilenumbrüche inmitten von VALUES.

s'Amstel

[TITAN3000]

Ok, erstmal zu den Versionen.

Alter Server:

Betriebssystem:Suse v. ?

MySQL: 4.0.18-Max

phpMyAdmin: 2.6.0-rc1

Neuer Server:

Betriebssystem: Debian 40r3

MySQL: 5.0.32

phpMyAdmin: 2.9.1.1-Debian-6

exportiert hab ich´s mit phpmyadmin, anschließend hab ich´s auf dem neuen server auch mit phpmyadmin versucht zu importieren.

[flashpixx]

Ich würde eher zu "mysqldump" raten, da hier die Fehler direkt auf der Konsole sichtbar sind. Gerade wenn man mit verschiedenen Versionen arbeiten muss, dann kann das schon mal schief gehen. Aber der Export sollte innerhalb einer Version fehlerfrei sein.

Phil

[TITAN3000]

wenn ich die datenbank mit mysqldump exportieren will, so kommt es zu folgender meldung

ns:/home/db-export-oliver # mysqldump -u root -p xy_typo3>xy_typo3.sql

Enter password:

mysqldump: Can't get CREATE TABLE for table `cache_pagesection` (Can't open file: 'cache_pagesection.MYI'. (errno: 145))

[Amstelchen]

mysqldump: Can't get CREATE TABLE for table `cache_pagesection` (Can't open file: 'cache_pagesection.MYI'. (errno: 145))

deine datenbank und/oder tabelle ist beschädigt.

Ich darf die original -datenbank nicht "berühren"... also auch nicht reparieren oder ähnliches

dann kannst du sie gleich löschen. mach ein backup und REPAIR TABLE.

der für die kaputte MySQL zuständige admin hilft dir.

s'Amstel

[TITAN3000]

gibts keine möglichkeit die mit phpmyadmin exportierte .sql- datei zu reparieren?

kann ich denn nicht eine beschädigte datenbank vollständig mit mysqldump auslesen? (und dann diese .sql- datei reparieren?)

falls obiges nicht möglich ist, so werd ich die gesamte datenbank erstmal sichern (ich kann doch eigentlih nur das gesamte mysql- verzeichniss sichern, das müsste doch reichen, oder? ist es var/lib/mysql/ ? )

zur anderen datenbank (nicht die "xy_typo3", sondern nun die "monie")

ich habe mit mysqldump ohne fehlermeldungen die monie - DB exportiert --> monie.sql. (Diese monie.sql ist übrigens nur 4 mb groß, während die mit phpmyadmin exportierte ca. 5,8 MB groß ist.)

anschließend hab ich sie versucht mit mysqldump zu beim neuen server zu importieren. was auch ohne Fehlermeldung ablief.

debian40r3:/home# mysqldump -u root -p monie<monie.sql

Enter password:

-- MySQL dump 10.11

--

-- Host: localhost Database: monie

-- ------------------------------------------------------

-- Server version 5.0.32-Debian_7etch5-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;

/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;

/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;

/*!40101 SET NAMES utf8 */;

/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;

/*!40103 SET TIME_ZONE='+00:00' */;

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;

/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;

/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2008-04-20 21:00:02

allerdings ist die Datenbank komplett leer

Info- Update

Alter Server:

Betriebssystem:Suse v. ?

MySQL: 4.0.18-Max

phpMyAdmin: 2.6.0-rc1

MySQL dump 9.10

Neuer Server:

Betriebssystem: Debian 40r3

MySQL: 5.0.32

phpMyAdmin: 2.9.1.1-Debian-6

MySQL dump 10.11

[Amstelchen]

gibts keine möglichkeit die mit phpmyadmin exportierte .sql- datei zu reparieren?

das macht keinen sinn und funktioniert auch nicht.

kann ich denn nicht eine beschädigte datenbank vollständig mit mysqldump auslesen? (und dann diese .sql- datei reparieren?)

wie du an der fehlermeldung des mysqldump ersehen kannst: nein.

falls obiges nicht möglich ist, so werd ich die gesamte datenbank erstmal sichern (ich kann doch eigentlih nur das gesamte mysql- verzeichniss sichern, das müsste doch reichen, oder? ist es var/lib/mysql/ ? )

sie dir dazu bitte deine mysql.conf an - darin steht, wo die daten liegen.

es ist deine datenbank, du solltest das wissen

zur anderen datenbank (nicht die "xy_typo3", sondern nun die "monie")

ich habe mit mysqldump ohne fehlermeldungen die monie - DB exportiert --> monie.sql. (Diese monie.sql ist übrigens nur 4 mb groß, während die mit phpmyadmin exportierte ca. 5,8 MB groß ist.)

das ist, denke ich, normal. phpmyadmin kommentiert den dump ausführlich.

anschließend hab ich sie versucht mit mysqldump zu beim neuen server zu importieren. was auch ohne Fehlermeldung ablief.

allerdings ist die Datenbank komplett leer

sieh dir den dump an. sind da INSERT-statements drin oder nur CREATEs?

s'Amstel

[TITAN3000]

in der mit mysqldump exportierten monie.sql sind viele insert sowie auch create´s drinnen.

entweder auch diese datenbank ist beschädigt (warum gibt´s keine fehlermeldung beim export) oder

die unterschiedlichen mysqldump- versionen machen probleme

[TITAN3000]

Es ist nicht möglich die Datenbanken direkt auf dem Server zu reparieren. (Server ist zu wichtig, da darf es zu überhaupt keinem Ausfall kommen)

Der einzige mir gestatteter Weg ist, den gesamten MySQL- Ordner auf einen anderen Server zu kopieren, und von dort aus die Reparatur sowie den Export auszuführen.

Ich hab´s mir wie folgt vorgestellt

Schritt1: Installation von MySQL auf irgend einem anderen Server (muss es exact die gleiche MySQL- Version sein? deutlich einfacher wäre die Installation einer aktuellen Version, dann hätte ich auch gleich die gleiche mysqldump- version)

Schritt2:Ersetzen des Installationspfades durch die vom alten Server rauskopierte Installationspfad.

Schritt3: reparatur sowie export der Datenbanken.

Was meint ihr dazu, kann ich´s so machen?:confused:

[Ratzinger]

kA aber am besten du installiest MySQL lokal auf deinem Rechner oder einer VM dann hast du mal keine Rechte Probleme mehr!

[flashpixx]

Hi,

Du kannst es probieren. Also ich würde mir lokal die gleiche mySQL Version installieren und dann die Datenbanken (sprich die Dateiversion) kopieren. Falls aber Dateien fehlen bzw kaputt sind, wirst Du sie nicht aus dem Nirwana herzaubern können.

Warum machst Du eigentlich diese ganze Sache, nimm doch Dein letztes Backup das funktionsfähig war und hol Dir dort via Dump die Daten und kopiere sie in das neue DBMS?

Phil

[Amstelchen]

der hinweis auf eine lokale oder in einer virtuellen maschine gehaltene MySQL-engine ist doch völlig unsinnig, wenn die daten von bestehendem server A auf bestehenden server B übertragen werden sollen.

Was meint ihr dazu, kann ich´s so machen?

wäre eine gängige lösung, ja.

s'Amstel

[Ratzinger]

ja aber er möchte sie ja erst "reparieren"

[TITAN3000]

ok, muss/sollte also die Version MySQL: 4.0.18-(Max) sein, die ich nun auf irgend einen Server (wird wohl eine VM) draufpacken werde... ich bin aktuell noch nicht vor Ort und kann erst ca. in 1h zum Netzwerk.

[Carnie]

Übrigens nimmst du zum import ganz normal mysql und kein mysqldump.

[TITAN3000]

also ist es OK wenn ich aus einem älteren mysql die Daten per mysqldump exportiere und anschließend beim neuen mysql die Daten direkt mit mysql importiere. ich dachte das es besser wäre immer das gleiche programm zu benutzen.

[Amstelchen]

solange keine versionsspezifischen anweisungen im dump vorhanden sind, mit denen die 5er MySQL nichts anfangen kann, ja. im normalfall sollte dies allerdings - nicht korrumpierte datenbankfiles vorausgesetzt - klappen.

s'Amstel

[TITAN3000]

hmm, ich kann die MySQL- Version 4.0.18 Max (ist max wichtig?) nirgends finden. Mysql hat den support für diese alten Versionen eingestellt:(... kennt ihr vielleicht eine Quelle?

[Amstelchen]

die "max" ist die erweiterte version des mysqld. verwendet ihr denn features der max?

ich ging im übrigen davon aus, dass - vorallem, wenn dieser auf einer produktiven maschine betrieben wurde, ein RPM oder SRPM archiviert wurde. du kannst allenfalls noch beim mysql-support nachfragen, ob die eine 4.0.18er zur verfügung stellen.

da aber weder das noch scheinbar eine unbeschädigte DB existiert...

allenfalls kannst du versuchen, die binaries vom alten zum neuen system zu übertragen. aufgrund der unbekannten suse-version und der unbekannten architektur auf dem einen system und debian etch auf dem anderen ist das aber ein höchst wackelige bis unmögliche geschichte.

s'Amstel

[TITAN3000]

ich habe nun (doch) das Erlaubnis bekommen, die Reparatur auf dem alten Server vorzunehmen. Hierzu hab ich erstmal den kompletten Typo3- Ordner gesichert, und zwar so, das die Berechtigungen nicht verändert wurden:

cp blabla -R -p (p behält die Berechtigungen)

Anschließend hab ich mit folgendem Befehl nacheinander die Datnbanken repariert:

mysqlcheck -p --auto-repair --databases DBxyz

danach konnte ich die Datenbanken einzeln ohne weitere Fehlermeldungen oder Probleme mit: mysqldump DBxyz > DBxyz.sql -u root -p

exportieren.

Der Import klappte nicht mit mysqldump, die Datenbanken blieben leer.

allerdings klappte es prima mit mysql. der befehl hierzu fällt mir grad nicht mehr ein.

Ich will mir hier noch für eure, besonders Amstelchen´s, Hilfe bedanken:uli

Sonst hätte ich das Problem sicher nicht so schnell gelöst.