OTRS Datenbank von latin1 auf UTF8 konvertieren

[GustavG]

Hallo,

ich habe ein neues OTRS 4.0.15 auf einem Debian 64bit Jessie installiert und mit den Daten einer produktiven Installation (gleiches OS, gleiche OTRS Version) gefüttert. Es läuft soweit alles. Ziel dabei ist aber, die MariaDB Datenbank von latin1 auf utf8 zu konvertieren. Dazu habe ich folgende URL gefunden:

http://itsm-demo.otrs.com/otrs/public.p ... ItemID=202

Ich habe also zuerst "recode latin1..UTF-8 <otrs_1.sql >otrs-database-utf8.sql" gemacht, was ohne Fehler durch lief. Danach erstellte ich eine neue Datenbank mit "CREATE DATABASE otrs CHARACTER SET utf8;". Jetzt kommt der Schritt, die DB einzulesen. Wenn ich es so eingebe, wie auf der Seite steht, kommt:

ERROR 1115 (42000) at line 25: Unknown character set: 'utf8$'

Wenn ich das $ entferne, schiebt er die DB ohne Fehler in MariaDB:

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' <otrs-database-utf8.sql | mysql -u otrs -pXXXXXXXXXXXXXXXXX otrs

Leider sind danach in OTRS die Umlaute "kaputt".

Ich schaue gerade noch in eine info.php, dort finde ich zum Zeichensatz:

HTTP_ACCEPT_LANGUAGE de-DE,de;q=0.8,en;q=0.6

Accept-Language de-DE,de;q=0.8,en;q=0.6

default_charset UTF-8 UTF-8

Ist das relevant?

Und in der /etc/mysql/conf.d/mariadb.cnf steht

[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8

[mysqld]
#
# * Character sets
#
# Default is Latin1, if you need UTF-8 set all this (also in client section)
#
character-set-server = utf8
collation-server = utf8_general_ci
character_set_server = utf8
collation_server = utf8_general_ci

Hat jemand eine Idee was falsch lief?

Ich hab grad mal mit vim alle "latin1" in "utf8" umbenannt: "2701 Ersetzungen auf 2701 Zeilen". Jetzt kommt beim einspielen:

root@server:/upload$ mysql -u otrs -pXXXXXXXXXXXXXXXX otrs < otrs-database-utf8.sql
ERROR 1064 (42000) at line 7: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '40[utf8]01 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */' at line 1
root@server:/upload$

Das war wohl nix...

Weiterer Versuch: mit "mysqldump -u otrs -pXXXXXXXX otrs >otrs-database.sql" eine aktuelle Version der produktiven DB geholt und auf den anderen Server geschoben. Danach ein

recode latin1..UTF-8 <otrs-database.sql >otrs-database-utf8.sql

und

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8$/' <otrs-database-utf8.sql > otrs-database-utf8-neu.sql

(mit $ dieses mal)

Hat beides geklappt. Danach ein:

mysql -u otrs -pXXXXXXXXXXXXXXXXX otrs < otrs-database-utf8-neu.sql

und es kommt der bekannte Fehler:

Code: Select all

ERROR 1115 (42000) at line 25: Unknown character set: 'utf8$'

Einige Umlaute werden korrekt dargestellt und andere sind kaputt. Hää? Wie geht denn das?

Weitere Erkenntnis: Die Titel im Ticket, also ganz oben das dick geschriebene nach "Ticket#1006842 — ......" ist kaputt wobei unten in der ersten Mail der Betreff korrekt dargestellt wird. Für mich sieht das so aus, als ob OTRS dort Mist baut. In der DB steht es nämlich korrekt drin. Doch warum wird der gleiche Text einmal korrekt und einmal falsch/kaputt dargestellt?

[wurzel]

Hi,

Also ich hab schon öfter Datenbanken konvertiert. Das klappte bisher immer einwandfrei.

Ein Bug ist es nicht.


Was aber sein kann, dass dein otrs 4 (welches utf8 als DB benötigt) in deine latin DB flasch geschrieben hat.
Dann hast du kaputte Zeichen.

Entweder Du lebst damit oder Du änderst alles manuell.


Utf8 ist Muss für OTRS mindestens seit 3.2
https://www.otrs.com/release-notes-otrs ... 0/?lang=de

OTRS 3.2 supports only UTF-8 as internal character set. Non-UTF-8 installations of OTRS must switch to UTF-8.

Wenn man das nicht beachtet kann ein character kaputt sein.


und das ist, was ich vermute: dass Dein Ursprungsdump schon falsch ist. und deshalb so ein mismatch kommt.

Viele Grüße
Flo

[dtraenapp]

Hi,

wir haben das gleiche Problem, wobei es unerheblich ist, ob wir das vor 3.2 oder danach machen.

Einigen Umlaute sind nach der Migration der DB defekt:

- E-Mail-Nutzername
- Manche Titel/Betreffs, aber nicht alle

Gibt es bereits eine Lösung oder eine weitere Idee?

Gruß

Dirk

[jojo]

prüfe das client encoding des mysql clients for dem dump, wenn dieses bereits utf8 ist, muss der Dump nicht mehr konvertiert werden. Dann braucht es nur noch das sed...

[GustavG]

Guten Morgen,

erstmal vielen Dank für eure Antworten.

Ich hatte hier eine Probeinstallation gemacht, die irgendwann funktionierte. Ich wollte erst die Version 4 vollständig installiert haben mit ganzen Umlauten und machte damit alle Versuche. Das hat ewig nicht funktioniert, weshalb ich irgendwann die Version 4 (mit kaputten Umlauten) auf die 5 upgradete. Danach waren die Umlaute ganz. Als ich dann das produktive OTRS endgültig umziehen wollte, ging ich genau so vor, und hatte das gleiche Problem wieder, kaputte Umlaute.

Ich probierte wieder ewig, mein Fazit ist jetzt, beide male habe ich den letzten gepipten Befehl aus der Anleitung:

Code: Select all

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8$/' <otrs-database-utf8.sql | mysql -u otrs -p otrs

einzeln ausgeführt (und ohne das $ nach utf8) und damit ging es:

Code: Select all

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' <otrs-database-utf8.sql > otrs-database-utf8-fixed.sql

mysql -u otrs -pXXXXXXXXXXXX otrs < otrs-database-utf8-fixed.sql

die einzelnen Befehle funktionierten beide male, zusammen waren die Umlaute in zich Versuchen kaputt.

Jetzt läuft OTRS 5 sauber mit utf8 Datenbank und ganzen Umlauten.

[kleinemeise]

Hey Leute,

ich stehe aktuell beim Update von 5.0 auf 6.0 vor dem selben Problem.

Das Check Script sagt:

Code: Select all

    Error: The setting character_set_database needs to be 'utf8'.

Meine Datenbank ist im folgenden Schema:

Code: Select all

'character_set_client', 'utf8'
'character_set_connection', 'utf8'
'character_set_database', 'latin1'
'character_set_filesystem', 'binary'
'character_set_results', 'utf8'
'character_set_server', 'latin1'
'character_set_system', 'utf8'

Leider geht der Link oben nicht mehr. Wie gehen ich hier am besten vor?

[GustavG]

Guten Morgen,

ich würde an deiner Stelle ein Test-OTRS aufsetzen mit der gleichen Version die du aktuell produktiv nutzt. Dann die DB des vorhandenen OTRS exportieren, ich glaub das war mit:

Code: Select all

mysqldump -uotrs -pPASSWORT -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B otrs > otrs-database-utf8.sql

und wie oben beschrieben bearbeiten:

Code: Select all

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' <otrs-database-utf8.sql > otrs-database-utf8-fixed.sql

mysql -u otrs -pXXXXXXXXXXXX otrs < otrs-database-utf8-fixed.sql

Die otrs-database-utf8-fixed.sql schiebst du dann ins Test-OTRS und schaust ob alles passt.

[kleinemeise]

Guten Morgen,

ich würde an deiner Stelle ein Test-OTRS aufsetzen mit der gleichen Version die du aktuell produktiv nutzt. Dann die DB des vorhandenen OTRS exportieren, ich glaub das war mit:

Code: Select all

mysqldump -uotrs -pPASSWORT -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B otrs > otrs-database-utf8.sql

und wie oben beschrieben bearbeiten:

Code: Select all

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' <otrs-database-utf8.sql > otrs-database-utf8-fixed.sql

mysql -u otrs -pXXXXXXXXXXXX otrs < otrs-database-utf8-fixed.sql

Die otrs-database-utf8-fixed.sql schiebst du dann ins Test-OTRS und schaust ob alles passt.

Hallo GustavG,
habe alles so gemacht - und lief auch ohne Problem. Nur kommt die Meldung immer noch.
In MySQL Workbench zeigt es noch folgendes an:

otrs_db.PNG

Muss ich das nicht auch umstellen bzw. was genau wird den von dem Update Script geprüft?

[GustavG]

Ist die Datenbank denn auch wirklich auf UTF8 bzw "utf8_general_ci" eingestellt? Hast du eine neue DB angelegt und die Kollation "utf8_general_ci" gewählt?

[kleinemeise]

Ich habe jetzt die bestehende per

Code: Select all

ALTER DATABASE otrs DEFAULT CHARACTER SET utf8;

auf UTF8 gesetzt. Jetzt läuft es erstmal weiter. Ich denke, hier muss ich noch etwas Testen

Danke GustavG

[kleinemeise]

und jetzt bekomme ich leider beim Update folgende Meldung:

Code: Select all

    Step 1 of 37: Check framework version ...
    Step 2 of 37: Check required Perl version ...
    Step 3 of 37: Check required database version ...
    Step 4 of 37: Check database charset ...
    Step 5 of 37: Check required Perl modules ...
    Step 6 of 37: Check if database has been backed up ...
    Step 7 of 37: Upgrade database structure ...
    Step 8 of 37: Migrate configuration ...
    Step 9 of 37: Refresh configuration cache after migration of OTRS 5 settings ...
    Step 10 of 37: Migrating ticket storage configuration ...
    Step 11 of 37: Migrating article search index configuration ...
    Step 12 of 37: Migrating ticket zoom customer information widget configuration ...
    Step 13 of 37: Drop deprecated table gi_object_lock_state ...
    Step 14 of 37: Migrate PossibleNextActions setting ...
    Step 15 of 37: Migrating time zone configuration ...
    Step 16 of 37: Create appointment calendar tables ...
    Step 17 of 37: Create ticket number counter tables ...
    Step 18 of 37: Update calendar appointment future tasks ...
    Step 19 of 37: Add basic appointment notification for reminders ...
    Step 20 of 37: Create Form Draft tables ...
    Step 21 of 37: Clean and drop group_user permission_value column ...
    Step 22 of 37: Migrate GenericAgent jobs configuration ...
    Step 23 of 37: Migrate TicketAppointment rules configuration ...
    Step 24 of 37: Migrate Merged Ticket history name values ...
    Step 25 of 37: Migrate ticket statistics ...
    Step 26 of 37: Migrate ticket notifications ...
    Step 27 of 37: Create entries in new article table ...
    Step 28 of 37: Post changes on article related tables ...
[Fri Dec 15 09:29:47 2017] DBUpdate-to-6.pl: DBD::mysql::db do failed: Cannot delete or update a parent row: a foreign key constraint fails at /opt/otrs/Kernel/System/DB.pm line 470.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.20.2 OS: linux Time: Fri Dec 15 09:29:48 2017

 Message: Cannot delete or update a parent row: a foreign key constraint fails, SQL: 'DROP TABLE IF EXISTS article_type'

 Traceback (2494):
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 349
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 297
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_DropArticleTypeTable Line: 445
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 71
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: scripts/DBUpdate-to-6.pl Line: 89


ERROR: OTRS-otrs.Console.pl-Maint::Database::Check-10 Perl: 5.20.2 OS: linux Time: Fri Dec 15 09:29:48 2017

 Message: Error during execution of 'DROP TABLE IF EXISTS article_type'!

 Traceback (2494):
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 352
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 297
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_DropArticleTypeTable Line: 445
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 71
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: scripts/DBUpdate-to-6.pl Line: 89




 Not possible to complete migration, check previous messages for more information.

Jemand eine Idee?

[kleinemeise]

hab die Tabelle manuell gelöscht - jetzt passt es.

[reneeb]

Hast Du QuickClose installiert? Dann muss man vor dem Upgrade auf OTRS6 folgendes machen: https://gist.github.com/reneeb/138d0489 ... 1516fe636e