softjury
30.05.2008, 14:48
Hi,
IST-Zustand
wir betreiben ein vBulletin Version 3.6.7 (Deutsch) auf dem Server aaa, wobei die Datenbank auf einem zweiten Server liegt, Namens bbb.
Auf bbb läuft MySQL in Version 4.0.27, die Webseiten verwenden ISO-8859-1 als Zeichensatz und in der Datenbank ist auch alles ISO-8859-1 bzw. latin1.
SOLL-Zustand
Die Datenbank soll vom externen Server bbb runter und stattdessen auf aaa (wo auch der Webserver läuft). MySQL auf aaa ist Version 5.0.54.
ProblemNach der Migration sagt vBulletin:
Sie wurden aus folgendem Grund gesperrt:
Es wurde keine Begründung angegeben.
Ende der Sperre:
Wegen des falschen Encodings könnte man denken, dass es etwas mit dem Zeichensatz zu tun hat.
Vorgehensweise
Auf aaa in der Konsole:
mysqldump --opt -a --compatible=mysql40 -h bbb DBNAME > DBNAME.sqlDas erstellt mir DBNAME.sql mit dem Dump der vBulletin-Tabelle vom MySQL-Server, der auf bbb läuft.
perl -pi -e 's/^\) TYPE=MyISAM;/) TYPE=MyISAM DEFAULT CHARSET=latin1;/' < DBNAME.sql > DBNAME_latin1.sqlDies ersetzt mir im SQL-Dump
CREATE TABLE `foo` (
[..]
) TYPE=MyISAM;durch
CREATE TABLE `foo` (
[..]
) TYPE=MyISAM DEFAULT CHARSET=latin1;(Nur zur Sicherheit)
Anschließend
mysql -e 'DROP DATABASE IF EXISTS DBNAME'
mysql -e 'CREATE DATABASE DBNAME CHARACTER SET latin1'
mysql DBNAME < DBNAME_latin1.sqlDies legt die Datenbank für vBulletin im latin1-Format an und importiert den modifizierten SQL-Dump.
Wenn ich mit auf der Konsole den SQL-Dump anschaue, dann sieht man ganz deutlich, daß die Sonderzeichen dort wirklich nicht UTF8-kodiert sind - die Daten im latin1-Format also zur Tabellendefinition und Datenbankdefinition im latin1-Format passen.
Nun noch die includes/config.php anpassen (bbb wird zu localhost) und das Forum sollte ohne Probleme mit der lokalen Datenbank laufen.
Dennoch sieht man nach Aufruf des Forums nicht die Forenübersicht sondern die oben bereits erwähnte Fehlermeldung.
Es hilft auch nichts, anstatt der DBNAME_latin1.sql die DBNAME.sql zu importieren oder beim mysqldump extra noch den Parameter --default-character-set=latin1 anzugeben - alles das gleiche Ergebnis.
Schalte ich den Debug-Modus an, bekomme ich folgende Informationen:
Hooks Called:
init_startup
style_fetch
cache_templates
global_start
parse_templates
error_nopermission
error_fetch
error_generic
Die DEBUG-Ausgabe der SQL-Queries fordert folgendes zu Tage (Auszüge):
SELECT calendarpermission.usergroupid, calendarpermission.calendarpermissions,calendar.calendarid,calendar.title, displayorder
FROM vb3_calendar AS calendar
LEFT JOIN vb3_calendarpermission AS calendarpermission ON (calendarpermission.calendarid=calendar.calendarid AND usergroupid IN(1))
ORDER BY displayorder ASC
Beim Explain der Query steht im Extra-Feld für die Tabelle calendarpermission der Hinweis const row not found.
(...)
SELECT title, template
FROM vb3_template
WHERE templateid IN (405,133,134,135,136,137,138,139,141,142,143,144,145,140,412,409,383,241,207,208,378,381,390,227,228 ,229,230,341,395,394,396,399)
Anschließend direkt ein Query, was mit Bans zu tun hat:
SELECT reason, liftdate
FROM vb3_userban
WHERE userid = 0Beim Explain der Query steht im Extra-Feld der Hinweis Impossible WHERE noticed after reading const tables.
Danach folgen
SELECT text, languageid, special
FROM vb3_phrase AS phrase
LEFT JOIN vb3_phrasetype USING (fieldname)
WHERE phrase.fieldname = 'error'
AND varname = 'no_reason_specified' AND languageid IN (-1, 0, 1)
SELECT text, languageid, special
FROM vb3_phrase AS phrase
LEFT JOIN vb3_phrasetype USING (fieldname)
WHERE phrase.fieldname = 'error'
AND varname = 'nopermission_banned' AND languageid IN (-1, 0, 1)
UPDATE vb3_session
SET lastactivity = 1212151037, location = '/?explain=1'
WHERE sessionhash = 'xxxxx'
Hat jemand eine Idee, was das Problem sein könnte? Muss nach der Migration von MySQL 4.0 auf 5.0 vBulletin irgendwo mitgeteilt werden, dass nun Version 5.0 zum Einsatz kommt? Müssen irgendwelche Tabellen geleert werden?
Cookies leeren hat nichts gebracht.
Gruß,
Marcel.
IST-Zustand
wir betreiben ein vBulletin Version 3.6.7 (Deutsch) auf dem Server aaa, wobei die Datenbank auf einem zweiten Server liegt, Namens bbb.
Auf bbb läuft MySQL in Version 4.0.27, die Webseiten verwenden ISO-8859-1 als Zeichensatz und in der Datenbank ist auch alles ISO-8859-1 bzw. latin1.
SOLL-Zustand
Die Datenbank soll vom externen Server bbb runter und stattdessen auf aaa (wo auch der Webserver läuft). MySQL auf aaa ist Version 5.0.54.
ProblemNach der Migration sagt vBulletin:
Sie wurden aus folgendem Grund gesperrt:
Es wurde keine Begründung angegeben.
Ende der Sperre:
Wegen des falschen Encodings könnte man denken, dass es etwas mit dem Zeichensatz zu tun hat.
Vorgehensweise
Auf aaa in der Konsole:
mysqldump --opt -a --compatible=mysql40 -h bbb DBNAME > DBNAME.sqlDas erstellt mir DBNAME.sql mit dem Dump der vBulletin-Tabelle vom MySQL-Server, der auf bbb läuft.
perl -pi -e 's/^\) TYPE=MyISAM;/) TYPE=MyISAM DEFAULT CHARSET=latin1;/' < DBNAME.sql > DBNAME_latin1.sqlDies ersetzt mir im SQL-Dump
CREATE TABLE `foo` (
[..]
) TYPE=MyISAM;durch
CREATE TABLE `foo` (
[..]
) TYPE=MyISAM DEFAULT CHARSET=latin1;(Nur zur Sicherheit)
Anschließend
mysql -e 'DROP DATABASE IF EXISTS DBNAME'
mysql -e 'CREATE DATABASE DBNAME CHARACTER SET latin1'
mysql DBNAME < DBNAME_latin1.sqlDies legt die Datenbank für vBulletin im latin1-Format an und importiert den modifizierten SQL-Dump.
Wenn ich mit auf der Konsole den SQL-Dump anschaue, dann sieht man ganz deutlich, daß die Sonderzeichen dort wirklich nicht UTF8-kodiert sind - die Daten im latin1-Format also zur Tabellendefinition und Datenbankdefinition im latin1-Format passen.
Nun noch die includes/config.php anpassen (bbb wird zu localhost) und das Forum sollte ohne Probleme mit der lokalen Datenbank laufen.
Dennoch sieht man nach Aufruf des Forums nicht die Forenübersicht sondern die oben bereits erwähnte Fehlermeldung.
Es hilft auch nichts, anstatt der DBNAME_latin1.sql die DBNAME.sql zu importieren oder beim mysqldump extra noch den Parameter --default-character-set=latin1 anzugeben - alles das gleiche Ergebnis.
Schalte ich den Debug-Modus an, bekomme ich folgende Informationen:
Hooks Called:
init_startup
style_fetch
cache_templates
global_start
parse_templates
error_nopermission
error_fetch
error_generic
Die DEBUG-Ausgabe der SQL-Queries fordert folgendes zu Tage (Auszüge):
SELECT calendarpermission.usergroupid, calendarpermission.calendarpermissions,calendar.calendarid,calendar.title, displayorder
FROM vb3_calendar AS calendar
LEFT JOIN vb3_calendarpermission AS calendarpermission ON (calendarpermission.calendarid=calendar.calendarid AND usergroupid IN(1))
ORDER BY displayorder ASC
Beim Explain der Query steht im Extra-Feld für die Tabelle calendarpermission der Hinweis const row not found.
(...)
SELECT title, template
FROM vb3_template
WHERE templateid IN (405,133,134,135,136,137,138,139,141,142,143,144,145,140,412,409,383,241,207,208,378,381,390,227,228 ,229,230,341,395,394,396,399)
Anschließend direkt ein Query, was mit Bans zu tun hat:
SELECT reason, liftdate
FROM vb3_userban
WHERE userid = 0Beim Explain der Query steht im Extra-Feld der Hinweis Impossible WHERE noticed after reading const tables.
Danach folgen
SELECT text, languageid, special
FROM vb3_phrase AS phrase
LEFT JOIN vb3_phrasetype USING (fieldname)
WHERE phrase.fieldname = 'error'
AND varname = 'no_reason_specified' AND languageid IN (-1, 0, 1)
SELECT text, languageid, special
FROM vb3_phrase AS phrase
LEFT JOIN vb3_phrasetype USING (fieldname)
WHERE phrase.fieldname = 'error'
AND varname = 'nopermission_banned' AND languageid IN (-1, 0, 1)
UPDATE vb3_session
SET lastactivity = 1212151037, location = '/?explain=1'
WHERE sessionhash = 'xxxxx'
Hat jemand eine Idee, was das Problem sein könnte? Muss nach der Migration von MySQL 4.0 auf 5.0 vBulletin irgendwo mitgeteilt werden, dass nun Version 5.0 zum Einsatz kommt? Müssen irgendwelche Tabellen geleert werden?
Cookies leeren hat nichts gebracht.
Gruß,
Marcel.