Upgrade von 5.0.28 auf 6.0.28 hängt (Step 8 of 44: Upgrade database structure)

[index5]

Hallo zusammen,

wir planen, unsere Produktiv-Instanz zu aktualisieren und testen dies nun mit einem Klon. Dabei hängt das DB-Update-Script.
Technische Daten:

Frontend - Debian 10 - OTRS 5.0.28 (ca. 1,8 TiB in der Applikation)
Backend - Debian 9 - MariaDB 10.1 (ca. 130 GiB in der DB)

Wir halten uns an diese Anleitung und bekommen diesen Output:

Code: Select all

root@otrs-p01:/data/otrs# su -c "/data/otrs/scripts/DBUpdate-to-6.pl" -s /bin/bash otrs

 Migration started ... 

 Checking requirements ... 

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Requirement check for: Check required database version ...
    Requirement check for: Check database charset ...
    Requirement check for: Check required Perl modules ...
    Requirement check for: Check if database has been backed up ...

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...
    Requirement check for: Migrating time zone configuration ...


        The currently configured time offset is 2 hours, these are the suggestions for a corresponding OTRS time zone: 

        Africa/Cairo
        Africa/Ceuta
        [...]

        It seems that Europe/Berlin should be the correct time zone to set for your OTRS. 

        Enter the time zone to use for OTRSTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

        Enter the time zone to use for UserDefaultTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Create entries in new article table ...
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
    Requirement check for: Migrate ArticleType in ProcessManagement Data ...
    Requirement check for: Migrate ArticleType in PostMaster filters ...

 Executing tasks ... 

    Step 1 of 44: Check framework version ...
    Step 2 of 44: Check required Perl version ...
    Step 3 of 44: Check required database version ...
    Step 4 of 44: Check database charset ...
    Step 5 of 44: Check required Perl modules ...
    Step 6 of 44: Check installed CPAN modules for known vulnerabilities ...
    Step 7 of 44: Check if database has been backed up ...
    Step 8 of 44: Upgrade database structure ...
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
[...]

Währenddessen läuft im Backend diese Query:

Code: Select all

ALTER TABLE article_data_mime ADD article_id BIGINT NULL

Die Query läuft für ca. 40 bis 50 Minuten, danach passiert auf der DB nichts mehr. Das Update-Script gibt weiterhin periodisch den Debug-Output aus. WIr haben das Script über Nacht laufen lassen, es scheint zu einem gewissen Punkt zu stoppen, ohne weiteren Output.
Wir sehen, dass die Partitionen nicht volllaufen, es gibt auch sonst keine spezifischen Meldungen (weder stdout noch DB- bzw. Sys-Logs).

Was könnten wir hier unternehmen?
Danke!

[zzz]

Hallo,

das sieht eher nach einem Problem mit der SSH-Verbindung aus.
Ich denke, dass die DB-Umstrukturierung durchläuft, die restlichen Schritte aber, aufgrund eines Verbindungsproblems, nicht mehr angezeigt werden.

Einfach mal nach "debug3: send packet: type 80" suchen.

Viele Grüße
Emin

[index5]

Hi Emin,

Hallo,

das sieht eher nach einem Problem mit der SSH-Verbindung aus.
Ich denke, dass die DB-Umstrukturierung durchläuft, die restlichen Schritte aber, aufgrund eines Verbindungsproblems, nicht mehr angezeigt werden.

Das würde mich schon wundern. Die Shell bleibt ja responsiv, dh. "Enter" gibt mir newlines usw:

Code: Select all

debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82

debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82


debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82

Einfach mal nach "debug3: send packet: type 80" suchen.

Das sehe ich ja direkt in der Shell als Output - oder gibt es noch weitere Logs, die dazu angelegt werden?

[zzz]

Das sehe ich ja direkt in der Shell als Output - oder gibt es noch weitere Logs, die dazu angelegt werden?

Damit meinte ich eher, dass viele Leute das Problem zu haben scheinen und es immer an der Verbindung liegt.
Ich kann zumindest garantieren, dass es nicht vom OTRS kommt.

Ob Timeouts unter /var/log/auth.log (oder /var/log/secure) angezeigt werden, kann ich leider nicht sagen.
Man könnte jedoch gucken, ob die Sitzung genau dann endet, wenn die Meldung zum ersten Mal erscheint.

[root]

Hi,

wie gross ist denn die Tabelle article_data_mime? Für ein ALTER TABLE wird die einmal komplett umkopiert, das kann schon mal dauern. Sieht man denn noch Disk IO?

- Roy

[index5]

Hallo zusammen,
vielen Dank für die Antworten. Wir haben in den letzten Tagen verschiedene Dinge bzgl. des Upgrades durchgespielt, ua. auch einem erneuten Versuch mit einem "frischen" Backup der Produktiv-Instanz. Mit --verbose bekommen wir bei DBUpdate-to-6.pl diesen Output:

Code: Select all

root@otrs-p01:~# su -c "/data/otrs/scripts/DBUpdate-to-6.pl --verbose" -s /bin/bash otrs

 Migration started ... 

 Checking requirements ... 

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Installed Perl version: v5.28.1. Minimum required Perl version: v5.16.0.
    Requirement check for: Check required database version ...
    Installed database version: MariaDB 10.1.44. Minimum required database version: 5.0.0.
    Requirement check for: Check database charset ...
    The setting character_set_client is: utf8. The setting character_set_database is: utf8. No tables found with invalid charset.
    Requirement check for: Check required Perl modules ...

    Executing /opt/otrs/bin/otrs.CheckModules.pl to check for missing required modules. 

  o Apache::DBI......................ok (v1.12)
  o Apache2::Reload..................ok (v0.13)
  o Archive::Tar.....................ok (v2.30)
  o Archive::Zip.....................ok (v1.64)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
  o Date::Format.....................ok (v2.24)
  o DateTime.........................ok (v1.50)
    o DateTime::TimeZone.............ok (v2.23)
  o DBI..............................ok (v1.642)
  o DBD::mysql.......................ok (v4.050)
  o DBD::ODBC........................Not installed! To install, you can use: 'apt-get install -y libdbd-odbc-perl'. (optional - Required to connect to a MS-SQL database.)
  o DBD::Oracle......................Not installed! (optional - Required to connect to a Oracle database.)
  o DBD::Pg..........................Not installed! To install, you can use: 'apt-get install -y libdbd-pg-perl'. (optional - Required to connect to a PostgreSQL database.)
  o Digest::SHA......................ok (v6.01)
  o Encode::HanExtra.................ok (v0.23)
  o IO::Socket::SSL..................ok (v2.060)
    Please consider updating to version 2.066 or higher: This version fixes email sending (bug#14357).
  o JSON::XS.........................ok (v3.04)
  o List::Util::XS...................ok (v1.50)
  o LWP::UserAgent...................ok (v6.26)
  o Mail::IMAPClient.................ok (v3.42)
    o IO::Socket::SSL................ok (v2.060)
    Please consider updating to version 2.066 or higher: This version fixes email sending (bug#14357).
    o Authen::SASL...................ok (v2.16)
    o Authen::NTLM...................ok (v1.09)
  o ModPerl::Util....................ok (v2.000010)
  o Net::DNS.........................ok (v1.19)
  o Net::LDAP........................ok (v0.65)
  o Net::SMTP........................ok (v3.11)
  o Template.........................ok (v2.27)
  o Template::Stash::XS..............ok (undef)
  o Text::CSV_XS.....................ok (v1.38)
  o Time::HiRes......................ok (v1.9759)
  o XML::LibXML......................ok (v2.0134)
  o XML::LibXSLT.....................ok (v1.96)
  o XML::Parser......................ok (v2.44)
  o YAML::XS.........................ok (v0.76)
    Requirement check for: Check if database has been backed up ...

        Warning: this script can make changes to your database which are irreversible.
        Make sure you have properly backed up complete database before continuing.

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...

Trying to connect to database 'DBI:mysql:database=otrs;host=xxxxxxx:8043;' with user 'otrs'...
Connection successful.

    Requirement check for: Migrating time zone configuration ...


        The currently configured time offset is 2 hours, these are the suggestions for a corresponding OTRS time zone: 

        Africa/Cairo
        Africa/Ceuta
        Africa/Johannesburg
        Africa/Khartoum
        Africa/Maputo
        Africa/Tripoli
        Africa/Windhoek
        Antarctica/Troll
        CET
        Europe/Amsterdam
        Europe/Andorra
        Europe/Belgrade
        Europe/Berlin
        Europe/Brussels
        Europe/Budapest
        Europe/Copenhagen
        Europe/Gibraltar
        Europe/Kaliningrad
        Europe/Luxembourg
        Europe/Madrid
        Europe/Malta
        Europe/Monaco
        Europe/Oslo
        Europe/Paris
        Europe/Prague
        Europe/Rome
        Europe/Stockholm
        Europe/Tirane
        Europe/Vienna
        Europe/Warsaw
        Europe/Zurich
        MET


        It seems that Europe/Berlin should be the correct time zone to set for your OTRS. 

        Enter the time zone to use for OTRSTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

        Enter the time zone to use for UserDefaultTimeZone (leave empty to show a list of all available time zones): Europe/Berlin

    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Create entries in new article table ...

        Check for orphaned entries in time_accounting table ...
        Check for orphaned entries in article_attachment table ...
        Check for orphaned entries in article_flag table ...
        Check for orphaned entries in article_plain table ...
        Check for orphaned entries in ticket_history table ...
        Check for orphaned entries in article table ...

    Requirement check for: Migrate ArticleType in ProcessManagement Data ...
    Requirement check for: Migrate ArticleType in PostMaster filters ...

 Executing tasks ... 

    Step 1 of 44: Check framework version ...
    Step 2 of 44: Check required Perl version ...
    Step 3 of 44: Check required database version ...
    Step 4 of 44: Check database charset ...
    Step 5 of 44: Check required Perl modules ...
    Step 6 of 44: Check installed CPAN modules for known vulnerabilities ...
Collecting all installed modules. This can take a while...
No advisories found

    Step 7 of 44: Check if database has been backed up ...
    Step 8 of 44: Upgrade database structure ...

       - Add table for dynamic field object names and add an index to speed up searching dynamic field text values
       - Add new sysconfig tables
       - Remove no longer needed MD5 columns from some tables
       - Add new communication channel table and insert data
       - Change article table structure and prepare renaming of article tables




[Mon Jun  8 15:55:31 2020] DBUpdate-to-6.pl: DBD::mysql::db do failed: Lost connection to MySQL server during query at /data/otrs/Kernel/System/DB.pm line 470.
ERROR: OTRS-otrs.Console.pl-Dev::Code::CPANAudit-11 Perl: 5.28.1 OS: linux Time: Mon Jun 8 13:55:32 2020

 Message: Lost connection to MySQL server during query, SQL: 'ALTER TABLE article CHANGE a_body a_body MEDIUMTEXT NULL'

 Traceback (29778): 
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 394
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 342
   Module: scripts::DBUpdateTo6::UpgradeDatabaseStructure::ArticleTableChangesPreRename::Run Line: 180
   Module: scripts::DBUpdateTo6::UpgradeDatabaseStructure::Run Line: 142
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /data/otrs/scripts/DBUpdate-to-6.pl Line: 87


ERROR: OTRS-otrs.Console.pl-Dev::Code::CPANAudit-11 Perl: 5.28.1 OS: linux Time: Mon Jun 8 13:55:32 2020

 Message: Error during execution of 'ALTER TABLE article CHANGE a_body a_body MEDIUMTEXT NULL'!

 Traceback (29778): 
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 397
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 342
   Module: scripts::DBUpdateTo6::UpgradeDatabaseStructure::ArticleTableChangesPreRename::Run Line: 180
   Module: scripts::DBUpdateTo6::UpgradeDatabaseStructure::Run Line: 142
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /data/otrs/scripts/DBUpdate-to-6.pl Line: 87

    Error.



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

Auf dem Backend (MariaDB 10.1) war nicht viel zu sehen, wir haben jetzt zunächst einmal das generelle Loglevel hochgedreht und lassen das Script noch einmal laufen. Die Fehlermeldung deutet ja u.U. auf Probleme mit der Konfiguration des DB-Servers hin, in Verbindung mit dem Upgrade.

[root]

Hi,

prüft bitte einmal den Plattenplatz da ein ALTER TABLE i.d.r. bei InnoDB ummkopieren in ein neues datenfile bedeuten kann. Auch ist die Variable tmpdir von MySQL interessant. Wenn die auf eine eigene Partition wie /tmp zeigt und diese klein ist wird's auch Probleme geben.

- Roy

[zzz]

Das erklärt natürlich die Fehlermeldungen und das Verhalten, wenn die Verbindungsprobleme nicht an der Sitzung, die das Script ausführt, sondern an der Verbindung zwischen dem OTRS und dem DB-Server liegt.

Läuft die Query auf dem DB-Server erfolgreich durch? Wenn ja, wird es nur ein Timeout Problem sein.
Ansonsten könnte der MariaDB-Log weitere Informationen liefern.

Ich vermute aber eher, dass es keine Probleme bei der Durchführung der Umstrukturierung gibt, sondern es ein reines Timeout Problem der Sitzung ist.

— Emin

[index5]

Hi,

prüft bitte einmal den Plattenplatz da ein ALTER TABLE i.d.r. bei InnoDB ummkopieren in ein neues datenfile bedeuten kann. Auch ist die Variable tmpdir von MySQL interessant. Wenn die auf eine eigene Partition wie /tmp zeigt und diese klein ist wird's auch Probleme geben.

- Roy

Hi Roy,

der Plattenplatz ist wie bereits angedeutet nicht das Problem, da wir dies auf den Systemen mit monitoren. Hier ist die komplette MySQL-Instanz (inkl. tmpdir) auf einer eigenen ausreichend großen Partition.

Das erklärt natürlich die Fehlermeldungen und das Verhalten, wenn die Verbindungsprobleme nicht an der Sitzung, die das Script ausführt, sondern an der Verbindung zwischen dem OTRS und dem DB-Server liegt.

Läuft die Query auf dem DB-Server erfolgreich durch? Wenn ja, wird es nur ein Timeout Problem sein.
Ansonsten könnte der MariaDB-Log weitere Informationen liefern.

Ich vermute aber eher, dass es keine Probleme bei der Durchführung der Umstrukturierung gibt, sondern es ein reines Timeout Problem der Sitzung ist.

— Emin

Genau - das versuchen wir, mit dem in MySQL/MariaDB jetzt eingeschaltetem Debug-Log herauszufinden. Ich würde hier aktuell auch Einstellungen am Daemon vermuten.

Dazu noch etwas mehr Hintergrund - das Setup ist sozusagen komplett "neu", da wir planen, unsere Produktiv-Instanz von einem externen Hoster auf eigene Systeme umzuziehen. Hier bekommen wir vom bisherigen Hoster lediglich einen DB-Dump und das Applikationsverzeichnis, systemspezifische Einstellungen sind mit Verweisen auf "Geschäftsgeheimnis" nicht einsehbar. Wir haben dann das Setup nachgestellt, also lokal OTRS 5.0.28 installiert sowie dann Applikation und DB importiert. Nun möchten wir vor der Migration das Upgrade einmal durchspielen, um zu evaluieren, ob sich dies evtl. im selben Wartungsfenster durchführen ließe.

[index5]

Wir haben nun mit erhöhtem Loglevel in MariaDB feststellen können, dass der Wert für "innodb_buffer_pool_size" zu niedrig eingestellt war (Default 128M). Diesen haben wir auf 4G erhöht. Dem DB-Host stehen aktuell 32 GiB RAM zur Verfügung.

Nun gab es danach beim erneuten Ausführen des Scripts diese Meldung im MariaDB-Error-Log:

Code: Select all

2020-06-09 10:34:54 140228915439360 [Warning] Aborted connection 5 to db: 'otrs' user: 'otrs' host: 'proxy-xxx' (Got an error reading communication packets)
2020-06-09 10:34:54 140228915439360 [Warning] Aborted connection 5 to db: 'otrs' user: 'otrs' host: 'proxy-xxx' (CLOSE_CONNECTION)

Der Host "proxy-xxx" ist ein haproxy 1.7.5 im tcp-Mode, welcher sich ua. um Failover kümmert, da ein zweites Backend mit Replikation Teil des Setup sein soll.
Architektur ist also OTRS Frontend -> haproxy (tcp) -> otrs Backend 01/02. Der haproxy-Log sagt nun:

Code: Select all

Jun  9 10:34:11 proxy-xxx haproxy[10752]: 10.xx.xx.xx:59692 [09/Jun/2020:09:11:24.324] mysql-otrs mysql-otrs/otrs-db-p01_3306 1/0/4966999 306089 CD 33/0/0/0/0 0/0

Hier sind die Session State Flags interessant (CD). Das haproxy-Manual sagt dazu:

CD The client unexpectedly aborted during data transfer. This can be
caused by a browser crash, by an intermediate equipment between the
client and haproxy which decided to actively break the connection,
by network routing issues between the client and haproxy, or by a
keep-alive session between the server and the client terminated first
by the client.

Der Client ist in diesem Fall ja das OTRS-Frontend, auf dem das Migrationsscript läuft.
Wir sehen auf dem MariaDB-Server aktuell keine weiteren problematischen Indikatoren, zB. ist wait_timeout = 8h, max_connections = 151 und laut netstat gibt es auch nur eine TCP-Session (ESTABLISHED) zwischen dem Frontend und MariaDB.

Zum weiteren Debugging sprechen wir aktuell das Backend direkt an, und lassen haproxy aussen vor. Nebenbei läuft auf dem Backend ein tcpdump, um genauer in die Streams schauen zu können. Wir testen nun, wie sich das Update-Script verhält.

[index5]

Update: das DBUpdate-Script schlägt nachwievor fehl, aber an einer anderen Stelle (Script lief bereits mehrmals, so dass die Zwischenschritte bereits übersprungen werden):

Code: Select all

root@otrs-p01:~# su -c "/data/otrs/scripts/DBUpdate-to-6.pl --verbose" -s /bin/bash otrs

 Migration started ... 

 Checking requirements ... 

    Requirement check for: Check framework version ...
    Requirement check for: Check required Perl version ...
    Installed Perl version: v5.28.1. Minimum required Perl version: v5.16.0.
    Requirement check for: Check required database version ...
    Installed database version: MariaDB 10.1.44. Minimum required database version: 5.0.0.
    Requirement check for: Check database charset ...
    The setting character_set_client is: utf8. The setting character_set_database is: utf8. No tables found with invalid charset.
    Requirement check for: Check required Perl modules ...

    Executing /opt/otrs/bin/otrs.CheckModules.pl to check for missing required modules. 

  o Apache::DBI......................ok (v1.12)
  o Apache2::Reload..................ok (v0.13)
  o Archive::Tar.....................ok (v2.30)
  o Archive::Zip.....................ok (v1.64)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
  o Date::Format.....................ok (v2.24)
  o DateTime.........................ok (v1.50)
    o DateTime::TimeZone.............ok (v2.23)
  o DBI..............................ok (v1.642)
  o DBD::mysql.......................ok (v4.050)
  o DBD::ODBC........................Not installed! To install, you can use: 'apt-get install -y libdbd-odbc-perl'. (optional - Required to connect to a MS-SQL database.)
  o DBD::Oracle......................Not installed! (optional - Required to connect to a Oracle database.)
  o DBD::Pg..........................Not installed! To install, you can use: 'apt-get install -y libdbd-pg-perl'. (optional - Required to connect to a PostgreSQL database.)
  o Digest::SHA......................ok (v6.01)
  o Encode::HanExtra.................ok (v0.23)
  o IO::Socket::SSL..................ok (v2.060)
    Please consider updating to version 2.066 or higher: This version fixes email sending (bug#14357).
  o JSON::XS.........................ok (v3.04)
  o List::Util::XS...................ok (v1.50)
  o LWP::UserAgent...................ok (v6.26)
  o Mail::IMAPClient.................ok (v3.42)
    o IO::Socket::SSL................ok (v2.060)
    Please consider updating to version 2.066 or higher: This version fixes email sending (bug#14357).
    o Authen::SASL...................ok (v2.16)
    o Authen::NTLM...................ok (v1.09)
  o ModPerl::Util....................ok (v2.000010)
  o Net::DNS.........................ok (v1.19)
  o Net::LDAP........................ok (v0.65)
  o Net::SMTP........................ok (v3.11)
  o Template.........................ok (v2.27)
  o Template::Stash::XS..............ok (undef)
  o Text::CSV_XS.....................ok (v1.38)
  o Time::HiRes......................ok (v1.9759)
  o XML::LibXML......................ok (v2.0134)
  o XML::LibXSLT.....................ok (v1.96)
  o XML::Parser......................ok (v2.44)
  o YAML::XS.........................ok (v0.76)
    Requirement check for: Check if database has been backed up ...

        Warning: this script can make changes to your database which are irreversible.
        Make sure you have properly backed up complete database before continuing.

        Did you backup the database? [Y]es/[N]o: y

    Requirement check for: Upgrade database structure ...

Trying to connect to database 'DBI:mysql:database=otrs;host=10.xx.xx.xx;' with user 'otrs'...
Connection successful.

    Requirement check for: Migrating time zone configuration ...
    Requirement check for: Update calendar appointment future tasks ...
    Requirement check for: Migrate GenericAgent jobs configuration ...
    Requirement check for: Migrate TicketAppointment rules configuration ...
    Requirement check for: Create entries in new article table ...
    Requirement check for: Migrate ArticleType in ProcessManagement Data ...
    Requirement check for: Migrate ArticleType in PostMaster filters ...

 Executing tasks ... 

    Step 1 of 44: Check framework version ...
    Step 2 of 44: Check required Perl version ...
    Step 3 of 44: Check required database version ...
    Step 4 of 44: Check database charset ...
    Step 5 of 44: Check required Perl modules ...
    Step 6 of 44: Check installed CPAN modules for known vulnerabilities ...
Collecting all installed modules. This can take a while...
No advisories found
    Step 7 of 44: Check if database has been backed up ...
    Step 8 of 44: Upgrade database structure ...

       - Add table for dynamic field object names and add an index to speed up searching dynamic field text values
       - Add new sysconfig tables
       - Remove no longer needed MD5 columns from some tables
       - Add new communication channel table and insert data
       - Change article table structure and prepare renaming of article tables
       - Rename article tables
       - Create new article table and change some table structures after renaming of article tables
       - Add an index to the ticket_history table and add EmailResend ticket history type
       - Add new tables for customer relations
       - Add new table for chat data
       - Change the password columns in the user/customer user tables
       - Add new table for article search index
       - Add new tables for communication logs
       - Update notification tables
       - Drop obsolete create_time_unix column from ticket table
       - Replace column create_time_unix column by create_time column in ticket_index table
       - Index article_data_mime table
       - Fix user preference keys
         - Blacklisted keys not found in user preference tables.


    Step 9 of 44: Migrate configuration ...

    If you see errors about 'Setting ... is invalid', that's fine, no need to worry! 
    This could happen because some config settings are no longer needed for OTRS 6 
    or you may have some packages installed, which will be migrated 
    in a later step (during the package upgrade). 

    The configuration migration can take some time, please be patient.

        - AllSettingsCount: 111
        - DisabledCount: 0
        - MissingCount: 31
        - UnsuccessfullCount: 0


Missing Settings: 
CustomerFrontend::Module###CustomerFAQExplorer
Frontend::Module###AdminImportExport
Frontend::Module###AgentITSMConfigItemSearch
Frontend::Module###AgentITSMConfigItemZoom
Frontend::Module###AgentSurveyAdd
Frontend::Module###AgentSurveyEdit
Frontend::Module###AgentSurveyEditQuestions
Frontend::Module###AgentSurveyStats
Frontend::Module###AgentSurveyZoom
Frontend::Output::FilterElementPost
GenericAgent::PreActionModules
OTRSTicketAllocation::BlockGroups
PostMaster::PreFilterModule###1-SystemMonitoring
PublicFrontend::Module###PublicFAQExplorer
Survey::AmountOfSurveysPer30Days
Survey::Hook
Survey::NotificationBody
Survey::NotificationSender
Survey::NotificationSubject
Survey::SendPeriod
SystemMonitoring::LinkTicketWithCI
Ticket::Frontend::AgentTicketPhone###ShowIncidentState
Ticket::Frontend::NeedSpellCheck
TicketAllocation::MaxTicketsPerQueue
TicketAllocation::QueuePriorities
TicketAllocation::ServiceTimeDecisionBase
TicketAllocation::ServiceTimeTopPriority
TimeAccounting::MaxAllowedInsertDays
Ticket::Frontend::MenuModule###317-ITSMChangeAdd
PreferencesGroups###SpellDict
NodeID
    Step 10 of 44: Refresh configuration cache after migration of OTRS 5 settings ...
    Step 11 of 44: Migrating ticket storage configuration ...
    Step 12 of 44: Migrating article search index configuration ...

        - Setting 'Ticket::SearchIndexModule' is already modified in the system skipping...

    Step 13 of 44: Migrating ticket zoom customer information widget configuration ...
    Step 14 of 44: Drop deprecated table gi_object_lock_state ...
    Step 15 of 44: Migrate PossibleNextActions setting ...
    Step 16 of 44: Migrate ZoomExpand setting ...

    There is no modified ZoomExpand config value, skipping migration... 
    Step 17 of 44: Migrating time zone configuration ...
    Step 18 of 44: Migrating modified settings ...


    Step 19 of 44: Create appointment calendar tables ...
    Step 20 of 44: Create ticket number counter tables ...

        - Table 'ticket_number_counter' already exists, skipping...

    Step 21 of 44: Update calendar appointment future tasks ...
    Step 22 of 44: Add basic appointment notification for reminders ...
    Step 23 of 44: Create Form Draft tables ...
    Step 24 of 44: Clean and drop group_user permission_value column ...
    Step 25 of 44: Migrate GenericAgent jobs configuration ...
    Step 26 of 44: Migrate TicketAppointment rules configuration ...
    Step 27 of 44: Migrate Merged Ticket history name values ...
    Step 28 of 44: Migrate ticket statistics ...
    Step 29 of 44: Migrate ticket notifications ...
    Step 30 of 44: Create entries in new article table ...
    Step 31 of 44: Post changes on article related tables ...

        - Reseting auto-incremental if needed for article table.
        - Performing needed actions on article_data_mime table.
[Wed Jun 10 11:52:38 2020] DBUpdate-to-6.pl: DBD::mysql::db do failed: Lost connection to MySQL server during query at /data/otrs/Kernel/System/DB.pm line 470.
ERROR: OTRS-otrs.Console.pl-Dev::Code::CPANAudit-11 Perl: 5.28.1 OS: linux Time: Wed Jun 10 11:52:38 2020

 Message: Lost connection to MySQL server during query, SQL: 'ALTER TABLE article_data_mime DROP article_type_id'

 Traceback (28380): 
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 394
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 342
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_UpdateArticleDataMimeTable Line: 286
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 52
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /data/otrs/scripts/DBUpdate-to-6.pl Line: 87


ERROR: OTRS-otrs.Console.pl-Dev::Code::CPANAudit-11 Perl: 5.28.1 OS: linux Time: Wed Jun 10 11:52:38 2020

 Message: Error during execution of 'ALTER TABLE article_data_mime DROP article_type_id'!

 Traceback (28380): 
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBString Line: 397
   Module: scripts::DBUpdateTo6::Base::ExecuteXMLDBArray Line: 342
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::_UpdateArticleDataMimeTable Line: 286
   Module: scripts::DBUpdateTo6::PostArticleTableStructureChanges::Run Line: 52
   Module: scripts::DBUpdateTo6::_ExecuteComponent Line: 157
   Module: scripts::DBUpdateTo6::Run Line: 69
   Module: /data/otrs/scripts/DBUpdate-to-6.pl Line: 87




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

MariaDB hat dazu im Log (sonst keine weiteren Indikatoren):

Code: Select all

2020-06-10 11:07:29 140228915439360 [Warning] Aborted connection 8835 to db: 'otrs' user: 'otrs' host: 'otrs-p01' (Got timeout reading communication packets)
2020-06-10 11:07:29 140228915439360 [Warning] Aborted connection 8835 to db: 'otrs' user: 'otrs' host: 'otrs-p01' (CLOSE_CONNECTION)

Timeout-Settings:

Code: Select all

MariaDB [(none)]> SHOW VARIABLES LIKE '%timeout%';
+-------------------------------------+----------+
| Variable_name                       | Value    |
+-------------------------------------+----------+
| connect_timeout                     | 10       |
| deadlock_timeout_long               | 50000000 |
| deadlock_timeout_short              | 10000    |
| delayed_insert_timeout              | 300      |
| innodb_flush_log_at_timeout         | 1        |
| innodb_lock_wait_timeout            | 50       |
| innodb_print_lock_wait_timeout_info | OFF      |
| innodb_rollback_on_timeout          | OFF      |
| interactive_timeout                 | 28800    |
| lock_wait_timeout                   | 31536000 |
| net_read_timeout                    | 30       |
| net_write_timeout                   | 60       |
| slave_net_timeout                   | 3600     |
| thread_pool_idle_timeout            | 60       |
| wait_timeout                        | 28800    |
+-------------------------------------+----------+

haproxy war hier nicht das Problem, wobei wir hier jetzt erstmal nicht weiterkommen. Die beiden Hosts laufen jeweils als VMs auf dem selben VSphere-Cluster, Konnektivitätsprobleme können wir ausschließen.
Gibt es sonst evtl. noch weitere Ideen?

[zzz]

Wenn es serverseitig nicht gelöst werden kann, würde ich die SQL-Befehle manuell ausführen und die entsprechenden Zeilen aus dem Migrationsskript auskommentieren; idealerweise auch in der richtigen Reihenfolge.

— Emin