Contao 4.7 Installation kopieren

[tab]

Ich habe gerade eine Kopie einer Contao 4.7 Installation erstellt, die ab morgen eine alte 3.5 Installation ersetzen soll. Dabei ist etwas passiert, was ich nicht verstehe, aber die Kopie sieht erst mal gut aus. Gemacht habe ich Folgendes:

1. Datenbankbackup mit BackupDB
2. In einer etwas älteren DB alle Tabellen einer Contao 3.5 Installation gelöscht
3. Mit phpMyAdmin das DB-Backup importiert
4. Alle Dateien der bestehenden Contao 4.7 Installation mit rsync -av in ein anderes Unterverzeichnis kopiert
5. In der Kopie die Datenbankzugangsdaten geändert
6. Andere Subdomain ins web-Verzeichnis der Kopie geleitet
7. Contao-Manager der Kopie aufgerufen
8. Cache gelöscht mit Contao-Manager
9. Pakete aktualisiert, mehr als 40 Updates
10. Installtool aufgerufen über Manager.

Soweit alles erwartungsgemäß verlaufen, aber jetzt bekam ich eine Unmenge an notwendigen Aktualisierungen der Datenbank angezeigt. Ich dachte schon es ist die falsche Datenbank eingebunden, aber war nicht so. Hauptsächlich waren es Änderungen der Collation, drop index aber wohl auch andere Änderungen. Ich weiss es leider nicht mehr genau. Woher kann so etwas kommen? In der Datenbank waren vor dem Import alle Tabellen gelöscht. Von den unerwartet vielen Updates kam es auch nicht, ich habe danach ein Update der Originalinstallation gemacht, danach wurde an der Original-DB nichts geändert vom Installtool. Beides MySQL Datenbanken, keine MariaDB. PHP-Versionen sind identisch identisch (geht bei Webgo eh nicht anders, aber auch im Contao-Manager jeweils gecheckt). Ich verstehe das nicht wirklich. Aber immerhin scheint die Kopie perfekt zu funktionieren.

Werde heute nachmittag nochmal die Datenbanken vergleichen zwecks Kollation und eventuell auch in der DB der Kopie nochmal alle Tabellen löschen und das Backup nochmal einspielen um zu sehen ob es vielleicht daran liegt.

[mlweb]

War die für die ein DB in der config.yml vielleicht noch was eingetragen wegen nicht vorhandenem innodb_large?

[Spooky]

Läuft die Kopie am selben Server wie das Original?

[tab]

War die für die ein DB in der config.yml vielleicht noch was eingetragen wegen nicht vorhandenem innodb_large?

Nein.

Läuft die Kopie am selben Server wie das Original?

Ja, beide bei Webgo im selben Platin-Paket. Die Datenbank für die Kopie ist allerdings deutlich älter als die des Originals. Die gibt es bestimmt schon seit mehr als einem Jahr. Und sie wurde zuvor von einer Contao 3.5 Installation benutzt. Nach der ganzen Aktion haben beide Datenbanken dieselbe komische Kollation (latin1_swedish_ci?), da scheint man auch nichts daran machen zu können. Alle Tabellen sind aber bei beiden DBs jetzt InnoDB mit Kollation utf8mb4_unicode_ci. Ich spiele mal das Backup des Originals nochmal ein und schaue mir dann die Tabellen an vor Lauf des Installtools, habe da einen leisen Verdacht.

Edit: Done, Verdacht bestätigt. Nach dem Import des mit BackupDB erstellten Dumps haben die Tabellen eine Kollation utf8mb4_general_ci. Das wird dann wohl vom Installtool in utf8mb4_unicode_ci geändert. Also Installtool gestartet und tatsächlich:

DROP INDEX alias ON tl_article
DROP INDEX start_stop_published_sorting ON tl_article
ALTER TABLE tl_article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
...

Der von BackupDB erzeugte Dump des Originals dazu sieht so aus:

... 
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;

#---------------------------------------------------------
# Table structure for table 'tl_article'
#---------------------------------------------------------
CREATE TABLE `tl_article` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `pid` int(10) unsigned NOT NULL default '0',
  `sorting` int(10) unsigned NOT NULL default '0',
  `tstamp` int(10) unsigned NOT NULL default '0',
  `title` varchar(255) NOT NULL default '',
  `alias` varchar(128) COLLATE utf8mb4_bin NOT NULL default '',
  `author` int(10) unsigned NOT NULL default '0',
  `inColumn` varchar(32) NOT NULL default '',
  `keywords` mediumtext NULL,
  `showTeaser` char(1) NOT NULL default '',
  `teaserCssID` varchar(255) NOT NULL default '',
  `teaser` mediumtext NULL,
  `printable` varchar(255) NOT NULL default '',
  `cssID` varchar(255) NOT NULL default '',
  `published` char(1) NOT NULL default '',
  `start` varchar(10) NOT NULL default '',
  `stop` varchar(10) NOT NULL default '',
  `protected` char(1) NOT NULL default '',
  `groups` blob NULL,
  `guests` char(1) NOT NULL default '',
  `customTpl` varchar(64) NOT NULL default '',
  PRIMARY KEY  (`id`),
  KEY `alias` (`alias`),
  KEY `pid_start_stop_published_sorting` (`pid`, `start`, `stop`, `published`, `sorting`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=56;
...

Ist das jetzt ein Fehler in BackupDB, der Hosting-Konfiguration oder geht das einfach nicht anders?