[solved] Nach Umstellung postgres auf mysql Tickets defekt

[TvonV]

Moin Moin,

ich habe ein OTRS mit postgresql laufen und möchte das auf mysql umbauen. Also eine Kopie der VM zum Testen gezogen und per mysql workbench die Daten der otrs Datenbank auf mysql migriert. Dann otrs auf mysql umgeswitcht und es sieht erst einmal gut aus: Einloggen geht, Schaltflächen funktionieren, Kunden und Kundenuser da, so weit so gut. ABER: Die Tickets selber werden nicht vernünftig dargestellt. Statt der normalen Ansicht sehe ich nur eine wirre Buchstaben- und Zahlenaneinanderreihung.
Ich vermute hinter den Inhalten der Tickets die Tabelle "articel_plain", sehe aber keinen Unterschied zwischen den Inhalten in der postgres und der mysql. Auch die Datentypen scheinen sinnvoll übernommen worden zu sein.

Irgendwer einen Tip wo ich ansetzen kann oder eine Erklärung warum die Daten auch in postgres anscheinend "merkwürdig" sind aber trotzdem richtig vom otrs dargestellt werden?

[jojo]

Du kannst nicht einfach mit Datenbanktools die Datenbanken konvertieren. Bitte nutze das OTRSCloneDB-5.0.1.opm dafür

[TvonV]

Danke dir soweit. Ich werde erst am Montag dazu kommen das Ganze zu machen.

Sollte irgendwer noch vor diesem Problem stehen: Hier der Link zum Paket und hier der zu einer Anleitung Den Link zum Paket muß man natürlich seiner Version anpassen und die Anleitung sinnentnehmend betrachten.

[TvonV]

Heute mal probiert aber leider klappt es nicht so ganz. Wenn ich

Code: Select all

su -c "bin/otrs.Console.pl Maint::Database::Clone" -s /bin/bash otrs

ausführe, bekomme ich folgende Meldung:

Meaningful start message...
[2016-08-22 09:22:45] Generating DDL for OTRS.
[2016-08-22 09:22:45] Generating DDL for package FAQ.
[2016-08-22 09:22:45] Generating DDL for package OTRSCloneDB.
[2016-08-22 09:22:45] Creating structures in target database (phase 1/2)......................................................................................................... done.
[Mon Aug 22 09:22:46 2016] otrs.Console.pl: DBD::mysql::st execute failed: Table 'otrs2.notifications' doesn't exist at /srv/www/htdocs/otrs-5.0.1/Kernel/System/DB.pm line 666.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Clone-10 Perl: 5.20.2 OS: linux Time: Mon Aug 22 09:22:46 2016

Message: Table 'otrs2.notifications' doesn't exist, SQL: '
SELECT COUNT(*)
FROM notifications'

Traceback (1861):
Module: Kernel::System::CloneDB::Driver::Base::RowCount Line: 171
Module: Kernel::System::CloneDB::Driver::Base::SanityChecks Line: 125
Module: Kernel::System::CloneDB::Backend::SanityChecks Line: 269
Module: Kernel::System::Console::Command::Maint::Database::Clone::Run Line: 99
Module: (eval) Line: 441
Module: Kernel::System::Console::BaseCommand::Execute Line: 435
Module: Kernel::System::Console::InterfaceConsole::Run Line: 86
Module: bin/otrs.Console.pl Line: 38

Error: Died at /srv/www/htdocs/otrs-5.0.1/Kernel/System/CloneDB/Driver/Base.pm line 171.

Es sind dann tatsächlich nur 105 Tabellen angelegt statt der erwarteten 106. Wo muß ich da ansetzen?

[TvonV]

Kleiner Nachtrag: Der dry-run läuft übrigens ohne Porbleme durch und auch ein --force bricht mit der gleichen Fehlermeldung ab.

[TvonV]

Einen kleinen Schritt bin ich weiter gekommen: Ich habe die Tabelle "notifications" versucht per Hand anzulegen bevor ich das Skript gestartet hab. Dabei trat folgender Fehler auf

mysql> CREATE TABLE notifications (
-> id INT not null primary key,
-> notification_type VARCHAR(200) not null,
-> notification_charset VARCHAR(60) not null,
-> notification_language VARCHAR(60) not null,
-> subject VARCHAR(200) not null,
-> text VARCHAR(4000) not null,
-> content_type VARCHAR(250),
-> create_time DATE not null,
-> create_by INT not null,
-> change_time DATE not null,
-> change_by INT not null,
-> FOREIGN KEY (create_by) REFERENCES users(id),
-> FOREIGN KEY (change_by) REFERENCES users(id)
-> );
ERROR 1005 (HY000): Can't create table 'otrs2.notifications' (errno: 150)
mysql> show tables;
Empty set (0.00 sec)

Wenn man das Ganze ohne die FOREIGN KEYs macht, wird die Tabelle angelegt (die Fremdschlüssel könnte man mutmaßlich später noch setzen, aber soweit bin ich nicht gekommen) und dann läuft das Skript auch deutlich länger. Hier ist mein Verdacht das notifications angelegt werden soll bevor users angelegt wurde und somit würde sich der Fremdschlüssel auf einen nicht vorhandenen Primär Schlüssel beziehen.

Leider läuft das Skript immer noch nicht durch.

[2016-08-23 09:48:30] Converting table customer_user...
[Tue Aug 23 09:48:30 2016] otrs.Console.pl: DBD::mysql::db do failed: Unknown column 'customer_ids' in 'field list' at /srv/www/htdocs/otrs-5.0.1/Kernel/System/DB.pm line 449.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Clone-10 Perl: 5.20.2 OS: linux Time: Tue Aug 23 09:48:30 2016

Message: Unknown column 'customer_ids' in 'field list', SQL: 'INSERT INTO customer_user (id, login, email, customer_id, pw, title, first_name, last_name, phone, fax, mobile, street, zip, city, country, comments, valid_id, create_time, create_by, change_time, change_by, customer_ids) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'

Traceback (8988):
Module: Kernel::System::CloneDB::Driver::Base::DataTransfer Line: 379
Module: Kernel::System::CloneDB::Backend::DataTransfer Line: 223
Module: Kernel::System::Console::Command::Maint::Database::Clone::Run Line: 104
Module: (eval) Line: 441
Module: Kernel::System::Console::BaseCommand::Execute Line: 435
Module: Kernel::System::Console::InterfaceConsole::Run Line: 86
Module: bin/otrs.Console.pl Line: 38

Could not insert data: Table: customer_user - id:2.

Keine Ahnung was da nun wieder schief läuft...

[TvonV]

Ok, der war einfach: Wir hatten einstmals versucht, wie bei OTRS 4, Firmenkunden zu erzeugen. Dafür wurde customer_ids als Feld eingefügt. Mußte einfach nur in der Postgres-Tabelle customer_user gelöscht werden.

Nun hängt das Skript hierbei:

2016-08-23 10:43:18] Finished converting table xml_storage.
[Tue Aug 23 10:43:23 2016] otrs.Console.pl: DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`otrs2`.`#sql-20e2_2c`, CONSTRAINT `FK_ticket_history_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)) at /srv/www/htdocs/otrs-5.0.1/Kernel/System/DB.pm line 449.
ERROR: OTRS-otrs.Console.pl-Maint::Database::Clone-10 Perl: 5.20.2 OS: linux Time: Tue Aug 23 10:43:23 2016

Message: Cannot add or update a child row: a foreign key constraint fails (`otrs2`.`#sql-20e2_2c`, CONSTRAINT `FK_ticket_history_article_id_id` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`)), SQL: 'ALTER TABLE ticket_history ADD CONSTRAINT FK_ticket_history_article_id_id FOREIGN KEY (article_id) REFERENCES article (id)'

Traceback (9305):
Module: Kernel::System::CloneDB::Backend::PopulateTargetStructuresPost Line: 448
Module: Kernel::System::Console::Command::Maint::Database::Clone::Run Line: 120
Module: (eval) Line: 441
Module: Kernel::System::Console::BaseCommand::Execute Line: 435
Module: Kernel::System::Console::InterfaceConsole::Run Line: 86
Module: bin/otrs.Console.pl Line: 38

Error: ERROR: Could not generate structures in target database!

Mal gucken ob ich da noch etwas finde. Mir sagt "child row" erst mal gar nichts. Und das "#sql-20e2_2c" sieht auch irgendwie komisch aus.

[TvonV]

Der Letzte war so dämlich wie unnötig. Durch die ganze Bastelei war der clone mit dem ich gearbeitet habe online gegangen und hatte just in dem Moment wo ich das Skript laufen ließ ein neues Ticket aus dem Postfach gezogen. Also erstmal den cron-job gekillt, die E-Mail-Adresse ungültig gemacht und dann von vorne mit Datenbank löschen, neu erstellen, Tabelle notifications erstellen und dann das Skript laufen lassen.

Jetzt lief das Skript ohne Fehler durch.

Ganz zum Schluß noch die Fremdschlüssel in notifications "einbauen"

Code: Select all

ALTER TABLE notifications ADD FOREIGN KEY (create_by) REFERENCES users(id);
ALTER TABLE notifications ADD FOREIGN KEY (change_by) REFERENCES users(id);

und otrs in der Konfig auf mysql umbauen. Läuft jetzt und die Tickets werden richtig dargestellt. Für mich bleibt damit noch die Geschichte mit den Firmen-Tickets übrig die der Hauptgrund für den Umbau waren.