[oi-polloi]

Huhu,

ich will bugzilla aktualisieren.
Dafür hab ich Virtuell ein neues Debian Etch aufgesetzt.
Alles installiert und Buzilla läuft auch.
Nun will ich die alten Datenbankbestände (mysql 4er, bugzilla 2.16.7.7) vom altem Server rüber konvertieren.
Nur irgendwie will das nicht gelingen.
Ich habs mit mysqldump probiert und auch mit mysql die DBs rüber zu schieben, bis her ohne Erfolg.
mysqldump -u root bugzilla > bugzilla_bak gesichert und dann auf das neue System kopiert. Dort mysqldump -u root bugzilla < bugzilla_bak importiert. Dabei erscheinen auf meinem Bildschirm nur noch komische Zeichen und danach bekomm ich eine Fehlermeldung im Browser wenn ich mich an der DB anmelde.
Gibt es andere Möglichkeiten die DB auf das neue System zu bekommen, oder mach ich das was grundsätzlich falsch?

Cheers

[trojan]

in /var/lib/mysql liegen ordner mit den plain-files der datenbanken, den ordner der entsprechenden db samt inhalt ins gleiche dir auf dem neuen verschieben sollte eigentlich funzen

einziger warscheinlicher "bug" ist, dass du dann beim starten vom sql5 angemeckert bekommst, dass die db eigentlich aus sql4 ist und nicht alles sql5-konform ist, passende meldung zum berichtigen der tables werden eigentlich mit ausgegeben.

die mail sollte der root-acc bekommen und einsehbar sein im file /var/mail/root, eigentlich und in den logs stehts sicher auch

[tiberian]

Der wieder einspiel befehl für sqldumps ist NICHT mysqldump sondern mysql

mysql -u root bugzilla < bugzilla_bak

[DanielCheef]

wo wir gerade beim Dumpen sind:

Wieso muss ich eigentlich wenn ich ein vollständiges Dump meiner MySQL5-Datenbank machen will die Option -R (zum Dumpen der Functions und SP) bei mysqldump anhängen? Ich meine gibt es irgendeinen Grund wieso die MySQL-Entwickler das nicht schon als Standardoption aktiviert haben, ohne -R habe ich ja keinen vollständigen Dump und dass sollte doch der Sinn von mysqldump sein?

Mir ist es jetzt schon ein paar mal passiert das ich das beim Backupen vergessen habe und nachher liefen dann die entsprechenden Programme/Webseiten nicht mehr weil die Functions und SPs fehlten. Ärgerlich war das als ich mir selbst ein paar umfangreiche SPs geschrieben habe die dadurch verlorenen gegangen sind. Naja hinterher ist man immer schlauer, jetzt wird direkt nach dem Backupen geprüft ob auch alles drin ist und ob sich das Backup auch zurückspielen lässt.

Also für ein vollständiges Backup oder auch wenn irgendwelche Scripte zum Einsatz kommen die automatisch mittels mysqldump ein Backup anlegen immer an -R denken:

mysqldump -u root -R datenbank > datenbank_backup.sql

[tiberian]

Zitat von DanielCheef 

wo wir gerade beim Dumpen sind:

Wieso muss ich eigentlich wenn ich ein vollständiges Dump meiner MySQL5-Datenbank machen will die Option -R (zum Dumpen der Functions und SP) bei mysqldump anhängen? Ich meine gibt es irgendeinen Grund wieso die MySQL-Entwickler das nicht schon als Standardoption aktiviert haben, ohne -R habe ich ja keinen vollständigen Dump und dass sollte doch der Sinn von mysqldump sein?

Ich denke, dass liegt daran dass die MySQL entwickler wissen, dass Functios und Stored Procedures nichts in einer Datenbankschicht zu suchen haben. Das sind sowas wie altlasten aus alt eingesessenen Datenbanksystemen. MySQL war wohl der Meinung, diese altlasten auch in ihr System einbinden zu müssen, um konkurrenzfähig zu bleiben.

[oi-polloi]

huhu,

habs hin bekommen mit myslq < DB-Name.
Bugzilla hatte mich nur etwas verwirrt, aber nun läuft erst mal wieder alles.

danke euch