Migration 4.0.8 Appliance -> 4.0.8 Linux

[SIGjo]

Hallo zusammen,

seit ein paar Tagen versuche ich nun verzweifelt, meine Appliance (Version 4.0.8 ) auf eine neue Linux-Kiste zu migrieren.

Ist-Situation:
- OTRS 4.0.8
- Appliance
- PostgreSQL

Soll-Situation:
- OTRS 4.0.8
- CentOS7
- MySQL

Nachdem die "Soll-Situation" läuft, soll natürlich auf 5.x geupdatet werden.


Versuch #1:
- Sicherung der Appliance per /opt/otrs/scripts/backup.pl -d /backup/
- Übertragen der Daten per WinSCP
- Wiederherstellung der Daten per /opt/otrs/scripts/restore.pl -b /backup/2016-04-06_14-44/ -d /opt/otrs/

Ergebnis:

Code: Select all

[root@otrsneu ~]# /opt/otrs/scripts/restore.pl -b /backup/2016-04-06_14-44/ -d /opt/otrs/
Restore /backup/2016-04-06_14-44//Config.tar.gz ...
which: no psql in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)
ERROR: Can't locate psql!

OK... ist eben kein PostgreSQL


Versuch #2:
- Anpassung der MySQL-Datenbank für Remotezugriff (Firewall temporär aus, per GRANT Rechte erteilt etc.)
- Installation CloneDB auf Appliance
- Konfiguration CloneDB
- Ausführen von /opt/otrs/bin/otrs.CloneDB.pl -r

Ergebnis:

Code: Select all

root@otrsalt:/opt/otrs/bin# ./otrs.CloneDB.pl -r
[2016-04-06 16:12:00] Generating DDL for OTRS.
[2016-04-06 16:12:00] Generating DDL for package FAQ.
[2016-04-06 16:12:00] Generating DDL for package OTRSCloneDB.
[2016-04-06 16:12:00] Creating structures in target database (phase 1/2)...................................................................................................... done.
[2016-04-06 16:12:01] Converting table acl...
[2016-04-06 16:12:01] Finished converting table acl.
[2016-04-06 16:12:01] Converting table acl_sync...
[2016-04-06 16:12:01] Finished converting table acl_sync.
[2016-04-06 16:12:01] Converting table article...
    Inserting 1000 of 27217
    Inserting 2000 of 27217
    ....
[2016-04-06 16:12:42] Finished converting table article.
[2016-04-06 16:12:42] Converting table article_attachment...
Getötet

Die Logdatei, welche ja standardmäßig als /tmp/OTRSCloneDB.log angelegt werden sollte, existiert nicht.


Ich habe keine Ahnung mehr, wie ich die Datenbank sauber migrieren soll.

[reneeb]

Gibt es einen Grund warum ihr nicht bei Postgres bleibt?

[SIGjo]

Mir persönlich wäre es fast egal auf welcher Datenbank das Ding läuft.

Die ganzen bisher gefundenen Anleitung zeigen mir aber irgendwie, dass MySQL quasi der "Standard" für OTRS ist... dem würde ich dann doch gerne Folgen.

[SIGjo]

Versuch #3:
Ich habe es jetzt irgendwie geschafft, dass das restore.pl -Script die MySQL-Datenbank findet.
Es werden mir jetzt aber unzählige Fehler ausgegeben.

Beispiel:

Code: Select all

...
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
ERROR 1064 (42000) at line 4213 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': 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 'charset=utf-8      Offizielle Info erhalten, dass der Umzug der PCs am 10.12.2013 sta' at line 1
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
...

oder auch

Code: Select all

PAGER set to stdout
PAGER set to stdout
PAGER set to stdout
ERROR 2005 (HY000) at line 4213 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Unknown MySQL server host 'CLIENT' (110)
PAGER set to stdout
ERROR 2005 (HY000) at line 4213 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Unknown MySQL server host '%App%\Config.reg' (110)
ERROR 2005 (HY000) at line 4213 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Unknown MySQL server host 'regedit' (110)
ERROR 2005 (HY000) at line 4213 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Unknown MySQL server host '14:04:24     3       2013-12-02' (110)
No connection. Trying to reconnect...
ERROR 2005 (HY000) at line 8620 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Unknown MySQL server host '14:04:24     3       2013-12-02' (110)
ERROR at line 8620 in file: '/backup/2016-04-06_22-00/DatabaseBackup.sql': Can't connect to the server

PAGER set to stdout

Was checkt der da nicht?

Standardmäßig wird die Datenbank folgendermaßen angelegt:

Code: Select all

MariaDB [(none)]> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| 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                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

Auch wenn ich die Variablen 'char%' auf utf8 setze (Wert "character_set_server=utf8" in die my.cnf) komme ich nicht weiter.

Code: Select all

MariaDB [(none)]> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

[SIGjo]

Versuch #4:
Ich habe auf einer Windows-VM einen PostgreSQL-Server installiert. Der Dump konnte dort ohne Probleme (zumindest kamen keine Meldungen) importiet werden.

Beim Versuch CloneDB zu nutzen kommt beim Schritt "Converting table article_attachment..." wieder das schöne Wort "Getötet". Super!

Was soll denn da bitte an der Quelldatenbank kaputt sein!?

[SIGjo]

... und weiter gehts.

Ich habe mir eine neue Appliance aufgesetzt und ich konnte das Backup tatsächlich auch dort mit restore.pl einspielen - das Backup scheint also OK zu sein.

Nach dem Restore kann ich mich allerdings mit keinem Nutzer/Agent mehr anmelden. Was ist denn jetzt da schonwieder los!?

[RStraub]

Auf "was ist denn jetzt schon wieder los" lässt sich nicht viel sagen.

Für die Konvertierung PGress -> MySQL gibt's bei Dr. Google einige Anleitungen.

Laufen denn die Daemons? Was sagen die Logs? Was sagt der Browser?

[darkdead]

Genau aus diesem Grund habe ich damals nicht versucht von PostgresSQL auf MySQL zu gehen, ich habe auch die Migration von Appliance auf ein reelles Linux vorgenommen. Bleib doch einfach bei PostgresSQL

viewtopic.php?t=30766

Gruß

[SIGjo]

In den Logdateien fand ich leider rein garnichts.

Ich habe jetzt folgendes gemacht:

- Neue 4.0.8er Appliance installiert und Backup eingespielt -> Appliance läuft einwandfrei
- Neue 4.0.8er unter Linux frisch hochgezogen mit MySQL und Remotezugriff auf Datenbank erlaubt

Einrichtung CloneDB auf Appliance mit folgenden Einstellungen:

Code: Select all

TargetDatabase: otrs
TargetDatabaseHost: IP der Linuxkiste
TargetDatabasePw: Passwort aus der Config.pm
TargetDatabaseType: mysql
TargetDatabaseuser: otrs

Auf der Appliance führte ich dann einen Testlauf von CloneDB durch (/opt/otrs/bin/otrs.CloneDB.pl -r -f -n)

Code: Select all

...
[2016-04-11 08:28:48] Checking table xml_storage...
Dry run successfully finished.

27000 article, 26500 article_attachment, 58000 article_flag.... das alles packt er.

Jetzt steigt er bei article_plain aus:

Code: Select all

[2016-04-11 09:14:57] Converting table article_plain...
    Inserting 1000 of 11480
    Inserting 2000 of 11480
    Inserting 3000 of 11480
    Inserting 4000 of 11480
    Inserting 5000 of 11480
[Mon Apr 11 09:17:08 2016] otrs.CloneDB.pl: DBD::mysql::db do failed: MySQL server has gone away at /TARGET/SHARE/var/otrs/Kernel/System/DB.pm line 442.
[Mon Apr 11 09:17:09 2016] otrs.CloneDB.pl: Version string '-1, set by base.pm' contains invalid data; ignoring: '-1, set by base.pm' at /TARGET/SHARE/var/otrs/Kernel/System/Log.pm line 197.
ERROR: OTRS-otrs.CloneDB.pl-10 Perl: 5.10.1 OS: linux Time: Mon Apr 11 11:17:09 2016

 Message: MySQL server has gone away, SQL: 'INSERT INTO article_plain (id, article_id, body, create_time, create_by, change_time, change_by) VALUES (?, ?, ?, ?, ?, ?, ?)'

 Traceback (32296):
   Module: Kernel::System::CloneDB::Driver::Base::DataTransfer Line: 375
   Module: Kernel::System::CloneDB::Backend::DataTransfer Line: 216
   Module: /opt/otrs/bin/otrs.CloneDB.pl Line: 80

Could not insert data: Table: article_plain - id:5989.

Ich geh jetzt wirklich mal her und versuche mit postgresql klar zu kommen...

Aber trotzdem interessiert es mich, wieso der da jetzt abbricht

[SIGjo]

So.... das Problem ist GELÖST.


Ich hab mir jetzt CentOS7 frisch installiert, PostgreSQL draufgeknallt, eine leere otrs-Datenbank mit entsprechenden Nutzern erstellt und das Backup manuell wiederhergestellt.

Die Config/Application.tar.gz wurde einfach unter /opt/otrs entpackt.
Der Datenbank-Dump wurde simpel per psql otrs < /backup/DatabaseBackup.sql importiert.

Ich musste dann zwar noch die Kernel/Config.pm anpassen, da diese den MySQL-DSN aktiv hatte (warum auch immer...) aber es klappt alles einwandfrei.

Das Update auf 5.0.9 war innerhalb von 5 Minuten erledigt. Basta!



Ist aber irgendwie enttäuschend, dass man nirgends eine offizielle Anleitung zur Ablösung der Appliance findet.

[jojo]

CloneDB ist der offizielle Weg, bitte beachte auch das die Appliance niemals für die produktive Nutzung empfohlen wurde...

[Refaeliadria]

Is there a reason why you remain in Postgres ?