Upd 15.0.8: MySQL wird als Datenbank verwendet, unterstützt jedoch keine 4-Byte-Zeichen

nextclouder · June 13, 2019, 4:23pm

Hallo,
nach dem Update auf v15.0.8 kommt folgende Warnung:
“MySQL wird als Datenbank verwendet, unterstützt jedoch keine 4-Byte-Zeichen. Um beispielsweise 4-Byte-Zeichen (wie Emojis) ohne Probleme mit Dateinamen oder Kommentaren verarbeiten zu können, wird empfohlen, die 4-Byte-Unterstützung in MySQL zu aktivieren. Für weitere Details lesen bitte die Dokumentationsseite hierzu.”

Der MySQL-Server läuft im hosted webpack bei HostEurope mit utf8mb4_unicode_ci .

Warum kommt diese Fehlermeldung trotzdem? Eine 4-Byte-Unterstützung sollt damit doch gewährleistet sein!?

Kann man nur den Zeichensatz/ die Kollation der MySQL-Verbindung auf
utf8mb4_gereral_ci
wie hier empfohlen umstellen?
Aufgrund des shared Webhosting habe ich nur Zugriff auf phpMyAdmin…

Danke und Gruß!

Crashandy · June 14, 2019, 5:57am

Hallo @nextclouder,

ich kann Dir hier nur meine Erfahrungen mitteilen.

Also grundsätzlich ja, aaaber:
Prüfe vorher welche MySQL-Version bei Dir vorliegt.

Da meine Datenbank schon etwas älter war, wurde sie damals mit der MySQL-Version 5.5.x angelegt. Damit gab es nur Fehler, da diese Version nicht mit der Konvertierung der Felder klar kam.

Ich habe nun eine neue Datenbank angelegt, welche nun als MySQL-Version 5.7.x läuft.
Festgestellt habe ich bei anderen Installationen, dass ab der MySQL-Version 5.6.x alles in Ordnung ist.
Die alten Daten habe ich im phpMyAdmin exportiert und in die neue Datenbank importiert.
Nun noch in der config.php die neuen Datenbankdaten eingetragen und schon lief alles weiter.

Wenn diese Voraussetzungen bei Dir erst einmal vorliegen, dann solltest Du erst in der config.php den Eintrag “‘mysql.utf8mb4’ => true,” eintragen und wenn Du dann noch den Eintrag “‘version’ => ‘15.0.8.1’,” in “‘version’ => ‘15.0.7.1’,” änderst, dann wird die Nextcloud neu installiert und die Tabellen werden automatisch konvertiert. Hierbei etwas Geduld, denn es kann bei einem größeren Datenbestand etwas dauern.

Gruß
Crashandy

nextclouder · June 18, 2019, 9:08am

Hallo,

danke für den Tipp.
Auf dem HostEurope-Webpack läuft ein MySQL-Server mit Datenbank 5.6.43-84.3-log.

Diese Nextcloud-Datenbank läuft mit utf8mb4_unicode_ci .

Damit sollte doch eine Unicode-Unterstützung inkl. 4-Byte schon aktiv sein, oder?
Warum mäkelt Nextcloud-15.0.8. trotzdem?

 -- phpMyAdmin SQL Dump
 -- version 4.9.0.1deb1
 -- https://www.phpmyadmin.net/
 --
 -- Host: webpack.hosteurope.de
 -- Erstellungszeit: 18. Jun 2019 um 11:10
 -- Server-Version: 5.6.43-84.3-log
 -- PHP-Version: 7.2.18-1+0~20190503103213.21+stretch~1.gbp101320
 
 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
 SET AUTOCOMMIT = 0;
 START TRANSACTION;
 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 utf8mb4 */;
 
 --
 -- Datenbank: `db`
 --
 CREATE DATABASE IF NOT EXISTS `db` DEFAULT CHARACTER SET latin1 COLLATE latin1_german2_ci;
 USE `db`;
 
 -- --------------------------------------------------------
 
 --
 -- Tabellenstruktur für Tabelle `oc_accounts`
 --
 
 CREATE TABLE `oc_accounts` (
   `uid` varchar(64) COLLATE utf8_bin NOT NULL DEFAULT '',
   `data` longtext COLLATE utf8_bin NOT NULL
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

 --
 -- Daten für Tabelle `oc_accounts`
 --

Kann ich einfach auf utf8mb4_general_ci umstellen und dann in der config.php den Eintrag “‘mysql.utf8mb4’ => true,” eintragen?

Und mit welchen 4-Byte-Einschränkungen muss ich leben, falls ich nichts ändere?

Anwort des HE-Supports, klingt kompliziert…

Wir haben Ihr Anliegen geprüft und können Ihnen mitteilen, dass wir prinzipiell Support für UTF-8 mit 4-Byte Support haben.
Allerdings gibt es da ein paar Dinge zu beachten, weil per Default UTF-8 mit 3-Byte genutzt wird.

1.) Das Character-Set für jede MySQL-Verbindung muss zu Anfang umgestellt werden:

SET NAMES utf8mb4

oder ggf. noch mit richtiger Kollation

SET NAMES utf8mb4 COLLATE utf8mb4_german2_ci

2.) In der Datenbank muss das Character-Set ebenfalls umgestellt werden, optional wieder mit zusätzlichem COLLATE Parameter hinten drin, wie zuvor beim SET NAMES Befehl, :

ALTER DATABASE database_name CHARACTER SET = utf8mb4

3.) Zu guter Letzt ist dann noch das Character-Set der entsprechenden Tabelle umzustellen, wobei es hier noch eine Besonderheit für die Felder dieser Tabelle gibt.

ALTER TABLE table_name CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4

Crashandy · June 19, 2019, 11:01am

Hallo @nextclouder,

Mit dieser Version habe ich es bei STRATO am laufen. Es sollte also auch bei Dir funktionieren.
Diese Besonderheit mit “VARCHAR(191)” gab es noch in der MySQL-Version 5.5.x, ab 5.6.x funktioniert es nun auch mit “VARCHAR(255)”.
Ich würde an Deiner Stelle einmal ausprobieren was passiert, wenn Du die Zeile “‘mysql.utf8mb4’ => true,” in Deiner config.php einträgst. Aber unbedingt auch die Versionsnummer herabsetzen, da die Reparatur bzw. die Konvertierung sonst nicht anläuft.
Bei Misserfolg einfach die eingefügte Zeile wieder löschen und es wird wieder auf utf8 konvertiert.

Meines Wissens, kannst Du dann z.B. keine Smilies verwenden.

Gruß
Crashandy

nextclouder · June 20, 2019, 8:40am

Wie/ wo sehe ich ‘funktionierende Smilies’?
(Bislang haben wir die wohl nicht verwendet, mir geht es eher um ein fehlerfreies Log auch im Hinblick auf die zukünftige Weiterentwicklung von NC…)

War mal mutig und habe in der config.php der 15.0.8 geändert:
‘mysql.utf8mb4’ => true,
‘version’ => ‘15.0.7.1’,

Beim Aufruf sollte dann auch auf 15.0.8 upgedated werden, aber es hagelte Fehler…

 Aktualisierung auf 15.0.8
 
 Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE `oc_addressbooks` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes
 Detaillierte Protokollmeldungen
 
 Update vorbereiten
 
 Log-Level auf "debug" gesetzt
 
 Wartungsmodus eingeschaltet
 
 Reparaturschritt: Repair MySQL collation
 
 Reparaturinformation: Change row format for oc_accounts ...
 
 Reparaturinformation: Change collation for oc_accounts ...
 
 Reparaturinformation: Change row format for oc_activity ...
 
 Reparaturinformation: Change collation for oc_activity ...
 
 Reparaturinformation: Change row format for oc_activity_mq ...
 
 Reparaturinformation: Change collation for oc_activity_mq ...
 
 Reparaturinformation: Change row format for oc_addressbookchanges ...
 
 Reparaturinformation: Change collation for oc_addressbookchanges ...
 
 Reparaturinformation: Change row format for oc_addressbooks ...
 
 Reparaturinformation: Change collation for oc_addressbooks ...
 
 Reparaturinformation: Change row format for oc_appconfig ...
 
 Reparaturinformation: Change collation for oc_appconfig ...
 
 Reparaturinformation: Change row format for oc_authtoken ...
 
 Reparaturinformation: Change collation for oc_authtoken ...
 
 Reparaturinformation: Change row format for oc_bruteforce_attempts ...
 
 Reparaturinformation: Change collation for oc_bruteforce_attempts ...
 
 Reparaturinformation: Change row format for oc_calendar_invitations ...
 
 Reparaturinformation: Change collation for oc_calendar_invitations ...
 
 Reparaturinformation: Change row format for oc_calendar_resources ...
 
 Reparaturinformation: Change collation for oc_calendar_resources ...
 
 Reparaturinformation: Change row format for oc_calendar_rooms ...
 
 Reparaturinformation: Change collation for oc_calendar_rooms ...
 
 Reparaturinformation: Change row format for oc_calendarchanges ...
 
 Reparaturinformation: Change collation for oc_calendarchanges ...
 
 Reparaturinformation: Change row format for oc_calendarobjects ...
 
 Reparaturinformation: Change collation for oc_calendarobjects ...
 
 Reparaturinformation: Change row format for oc_calendarobjects_props ...
 
 Reparaturinformation: Change collation for oc_calendarobjects_props ...
 
 Reparaturinformation: Change row format for oc_calendars ...
 
 Reparaturinformation: Change collation for oc_calendars ...
 
 Reparaturinformation: Change row format for oc_calendarsubscriptions ...
 
 Reparaturinformation: Change collation for oc_calendarsubscriptions ...
 
 Reparaturinformation: Change row format for oc_cards ...
 
 Reparaturinformation: Change collation for oc_cards ...
 
 Reparaturinformation: Change row format for oc_cards_properties ...
 
 Reparaturinformation: Change collation for oc_cards_properties ...
 
 Reparaturinformation: Change row format for oc_comments ...
 
 Reparaturinformation: Change collation for oc_comments ...
 
 Reparaturinformation: Change row format for oc_comments_read_markers ...
 
 Reparaturinformation: Change collation for oc_comments_read_markers ...
 
 Reparaturinformation: Change row format for oc_credentials ...
 
 Reparaturinformation: Change collation for oc_credentials ...
 
 Reparaturinformation: Change row format for oc_dav_shares ...
 
 Reparaturinformation: Change collation for oc_dav_shares ...
 
 Reparaturinformation: Change row format for oc_directlink ...
 
 Reparaturinformation: Change collation for oc_directlink ...
 
 Reparaturinformation: Change row format for oc_file_locks ...
 
 Reparaturinformation: Change collation for oc_file_locks ...
 
 Reparaturinformation: Change row format for oc_filecache ...
 
 Reparaturinformation: Change collation for oc_filecache ...
 
 Reparaturinformation: Change row format for oc_files_trash ...
 
 Reparaturinformation: Change collation for oc_files_trash ...
 
 Reparaturinformation: Change row format for oc_flow_checks ...
 
 Reparaturinformation: Change collation for oc_flow_checks ...
 
 Reparaturinformation: Change row format for oc_flow_operations ...
 
 Reparaturinformation: Change collation for oc_flow_operations ...
 
 Reparaturinformation: Change row format for oc_group_admin ...
 
 Reparaturinformation: Change collation for oc_group_admin ...
 
 Reparaturinformation: Change row format for oc_group_user ...
 
 Reparaturinformation: Change collation for oc_group_user ...
 
 Reparaturinformation: Change row format for oc_groups ...
 
 Reparaturinformation: Change collation for oc_groups ...
 
 Reparaturinformation: Change row format for oc_jobs ...
 
 Reparaturinformation: Change collation for oc_jobs ...
 
 Reparaturinformation: Change row format for oc_migrations ...
 
 Reparaturinformation: Change collation for oc_migrations ...
 
 Reparaturinformation: Change row format for oc_mimetypes ...
 
 Reparaturinformation: Change collation for oc_mimetypes ...
 
 Reparaturinformation: Change row format for oc_mounts ...
 
 Reparaturinformation: Change collation for oc_mounts ...
 
 Reparaturinformation: Change row format for oc_notifications ...
 
 Reparaturinformation: Change collation for oc_notifications ...
 
 Reparaturinformation: Change row format for oc_notifications_pushtokens ...
 
 Reparaturinformation: Change collation for oc_notifications_pushtokens ...
 
 Reparaturinformation: Change row format for oc_oauth2_access_tokens ...
 
 Reparaturinformation: Change collation for oc_oauth2_access_tokens ...
 
 Reparaturinformation: Change row format for oc_oauth2_clients ...
 
 Reparaturinformation: Change collation for oc_oauth2_clients ...
 
 Reparaturinformation: Change row format for oc_preferences ...
 
 Reparaturinformation: Change collation for oc_preferences ...
 
 Reparaturinformation: Change row format for oc_privatedata ...
 
 Reparaturinformation: Change collation for oc_privatedata ...
 
 Reparaturinformation: Change row format for oc_properties ...
 
 Reparaturinformation: Change collation for oc_properties ...
 
 Reparaturinformation: Change row format for oc_schedulingobjects ...
 
 Reparaturinformation: Change collation for oc_schedulingobjects ...
 
 Reparaturinformation: Change row format for oc_share ...
 
 Reparaturinformation: Change collation for oc_share ...
 
 Reparaturinformation: Change row format for oc_share_external ...
 
 Reparaturinformation: Change collation for oc_share_external ...
 
 Reparaturinformation: Change row format for oc_storages ...
 
 Reparaturinformation: Change collation for oc_storages ...
 
 Reparaturinformation: Change row format for oc_systemtag ...
 
 Reparaturinformation: Change collation for oc_systemtag ...
 
 Reparaturinformation: Change row format for oc_systemtag_group ...
 
 Reparaturinformation: Change collation for oc_systemtag_group ...
 
 Reparaturinformation: Change row format for oc_systemtag_object_mapping ...
 
 Reparaturinformation: Change collation for oc_systemtag_object_mapping ...
 
 Reparaturinformation: Change row format for oc_trusted_servers ...
 
 Reparaturinformation: Change collation for oc_trusted_servers ...
 
 Reparaturinformation: Change row format for oc_twofactor_backupcodes ...
 
 Reparaturinformation: Change collation for oc_twofactor_backupcodes ...
 
 Reparaturinformation: Change row format for oc_twofactor_providers ...
 
 Reparaturinformation: Change collation for oc_twofactor_providers ...
 
 Reparaturinformation: Change row format for oc_users ...
 
 Reparaturinformation: Change collation for oc_users ...
 
 Reparaturinformation: Change row format for oc_vcategory ...
 
 Reparaturinformation: Change collation for oc_vcategory ...
 
 Reparaturinformation: Change row format for oc_vcategory_to_object ...
 
 Reparaturinformation: Change collation for oc_vcategory_to_object ...
 
 Reparaturinformation: Change row format for oc_whats_new ...
 
 Reparaturinformation: Change collation for oc_whats_new ...
 
 Reparaturinformation: Change row format for oc_federated_reshares ...
 
 Reparaturinformation: Change collation for oc_federated_reshares ...
 
 Reparaturschritt: Repair SQLite autoincrement
 
 Reparaturschritt: Copy data from accounts table when migrating from ownCloud
 
 Reparaturschritt: Drop account terms table when migrating from ownCloud
 
 Das Datenbankschema wird aktualisiert
 
 Datenbank aktualisiert
 
 Suche nach einer Aktualisierung für die App "accessibility" im App-Store
 
 App-Store auf Aktualisierung für die App "accessibility" geprüft
 
 Suche nach ...
 Reparaturschritt: Repair MySQL collation
 
 Reparaturinformation: Change row format for oc_addressbooks ...
 
 Reparaturinformation: Change collation for oc_addressbooks ...
 
 Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE `oc_addressbooks` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes
 
 Das Update ist fehlgeschlagen. Bitte melde dieses Problem an die Nextcloud Community.

Danke + Gruß, UC

Crashandy · June 20, 2019, 11:10am

Hallo @nextclouder,

da scheint es wohl doch nicht bei Dir zu funktionieren.
Hast Du es auch schon im phpMyAdmin versucht?
Dort musst Du aber unbedingt vorher Deine Datenbank exportieren, da es auch einmal ganz schief gehen kann.

Ich habe auch schon bei älteren MySQL-Versionen Tabelle für Tabelle konvertiert und bei Bedarf den Varchar-Wert auf 191 gesetzt.
Die erste Tabelle an welcher man es erkennt, dass die Konvertierung fehl schlägt, ist die “oc-adressbooks”.

Sonst musst Du einfach diese Fehlermeldung ignorieren, so wie auch das fehlende PHP-Modul “imagick”.

Gruß
Crashandy

nextclouder · June 20, 2019, 5:52pm

Hmmm, Export und Import in phpMyAdmin schaffe ich noch, aber für das händische Konvertieren bräuchte ich eine Schritt-für-Schritt-Anleitung anhand einer oc_Tabelle, vielleicht unter Berücksichtigung der vorher notwendigen Änderungen, die HostEurope oben angegeben hat…
Nur, falls Du Lust und Zeit hast, wäre prima …

DANKE, UC

Crashandy · June 21, 2019, 7:14am

Hallo @nextclouder,

ich habe die MySQL-Server-Version: 5.6.42-log und da funktioniert es ohne die Feldlänge auf VARCHAR(191) zu ändern.

Gib mal im phpMyAdmin die folgenden SQL-Befehle ein und versuche die Konvertierung neu.

SET NAMES utf8mb4 COLLATE utf8mb4_general_ci;
ALTER DATABASE my_database DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

my_database = Deine Datenbank eintragen

Bei mir sieht die Tabelle dann so aus:

--
-- Table structure for table `oc_accounts`
--

DROP TABLE IF EXISTS `oc_accounts`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `oc_accounts` (
  `uid` varchar(64) COLLATE utf8mb4_bin NOT NULL DEFAULT '',
  `data` longtext COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;
/*!40101 SET character_set_client = @saved_cs_client */;

Gruß
Crashandy

nextclouder · June 21, 2019, 8:36am

Hallo,
danach gleicher Fehler wie bei letzten Versuch:

Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE oc_addressbooks CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

Versuche ich dann die Tabelle ‘oc_addressbooks’ mit:

ALTER TABLE oc_addressbooks CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4

zu bearbeiten, kommt als Fehler:

MySQL meldet:
#1054 - Unbekanntes Tabellenfeld 'column_name' in oc_addressbooks

Hmmm…

LG UC

Crashandy · June 21, 2019, 1:16pm

Hallo @nextclouder,

dann nimm mal die folgenden Befehle:

ALTER TABLE oc_addressbooks CHANGE principaluri principaluri VARCHAR(191);
ALTER TABLE oc_addressbooks CHANGE uri uri VARCHAR(191);

danach noch einmal

ALTER TABLE oc_addressbooks CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

weiter mit

ALTER TABLE oc_appconfig CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Analog so weiter, Tabelle für Tabelle, bis der nächste Fehler kommt.
Ist sehr aufwendig.

Gruß
Crashandy

nextclouder · June 23, 2019, 8:35am

Hallo,
habe weiter mit den gezeigten Befehle gebastelt, das folgende lief durch:
SET NAMES utf8mb4 COLLATE utf8mb4_general_ci;

 ALTER DATABASE `db1085127-ncw2` CHARACTER SET = utf8mb4 COLLATE utf8mb4_general_ci
 
 ALTER TABLE oc_addressbooks CHANGE principaluri principaluri VARCHAR(191);
 ALTER TABLE oc_addressbooks CHANGE uri uri VARCHAR(191);
 ALTER TABLE oc_addressbooks CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 
 ALTER TABLE oc_appconfig CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 
 ALTER TABLE oc_accounts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 ALTER TABLE oc_activity CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 ALTER TABLE oc_activity_mq CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 ALTER TABLE oc_addressbookchanges CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
 ALTER TABLE oc_appconfig CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Dann kamen Hänger, z.B.:
Fehler

 SQL-Befehl:
 
 ALTER TABLE oc_authtoken CHANGE principaluri principaluri VARCHAR(191)
 
 MySQL meldet: Dokumentation
 #1054 - Unbekanntes Tabellenfeld 'principaluri' in oc_authtoken

oder
MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 0.0152 Sekunden.)

ALTER TABLE oc_bruteforce_attempts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin*

[Inline bearbeiten] [ Bearbeiten ] [ PHP-Code erzeugen ]*

Warning: #1071 Schlüssel ist zu lang. Die maximale Schlüssellänge beträgt 767*

Warning: #1071 Schlüssel ist zu lang. Die maximale Schlüssellänge beträgt 767*

Warum und wie geht es hier weiter?

Danke + Gruß, UC

Crashandy · June 23, 2019, 8:31pm

Hallo @nextclouder,

ich dachte Du hast das Prinzip verstanden.

Warum? Weil in der Tabelle "oc_authtoken " die Spalte “token” zu lang ist, nämlich 255 an statt 191.
Nun darfst Du aber nicht in allen Spalten die Längen ändern, da manche auch mit 255 und mehr funktionieren. Das sagt Dir dann die Fehlermeldung nach dem Konvertierungsversuch.

Der nächste Befehl wäre dann

ALTER TABLE oc_authtoken CHANGE token token VARCHAR(191);

dann nochmals versuchen

ALTER TABLE oc_authtoken CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

bei Erfolg weiter mit den nächsten Tabellen

ALTER TABLE oc_bruteforce_attempts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE oc_calendarchanges CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE oc_calendarobjects CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE oc_calendarobjects CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

Hier wieder Fehlermeldung

**SQL-Befehl:**

ALTER TABLE oc_calendarobjects CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin

**MySQL meldet:** 

`#1071 - Schlüssel ist zu lang. Die maximale Schlüssellänge beträgt 767`

Dann musst Du in der Struktur der Tabelle nachschauen, welche Spalte es betreffen könnte. Es könnte die Spalt “uri” sein, da dort Indizes hinterlegt sind.
Also nun den folgenden Befehl

ALTER TABLE oc_calendarobjects CHANGE uri uri VARCHAR(191);

Danach wiederholen

ALTER TABLE oc_calendarobjects CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

und dieses Mal ist es erfolgreich.

Und nun weiter mit

ALTER TABLE oc_calendarobjects_props CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

usw.

Gruß
Crashandy

nextclouder · June 24, 2019, 9:46am

Hallo
und einmal mehr DANKE! Das Prinzip habe ich jetzt (hoffentlich) kapiert und mich bis oc_migrations durchgekämpft.
Dort kommt trotz der beschriebenen Umstellung mit
ALTER TABLE oc_migrations CHANGE app app VARCHAR(191);
ALTER TABLE oc_migrations CHANGE version version VARCHAR(191);
ALTER TABLE oc_migrations CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

folgender Fehler:

Reparaturschritt: Repair SQLite autoincrement
Reparaturschritt: Copy data from accounts table when migrating from ownCloud
Reparaturschritt: Drop account terms table when migrating from ownCloud
Das Datenbankschema wird aktualisiert
Doctrine\DBAL\Exception\DriverException: An exception occurred while executing ‘CREATE TABLE oc_migrations (app VARCHAR(255) NOT NULL, version VARCHAR(255) NOT NULL, PRIMARY KEY(app, version)) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin ENGINE = InnoDB ROW_FORMAT = compressed’: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

Die Tabelle wird daraufhin beim Aufruf von NC und dem Konvertierungslauf 15.0.7 >> 15.0.8 automatisch gelöscht (!).
Was mir auffällt: ownCloud… Falls ich das richtig in Erinnerung habe, wurde die Installation seinerzeit von ownCloud auf NextCloud umgestellt.
Screen-2019-06-24_12-26-41

Nebenbefundlich zeigt jede Umwandlung in phpMyAdmin folgende Warnung:

MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 0.0261 Sekunden.)
ALTER TABLE oc_calendarobjects CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin
Warning: #1478 InnoDB: ROW_FORMAT=COMPRESSED requires innodb_file_format > Antelope.
Warning: #1478 InnoDB: assuming ROW_FORMAT=COMPACT.

Wie geht’s weiter?

Danke + Gruß, UC

Crashandy · June 24, 2019, 2:00pm

Hallo @nextclouder,

eventuell hilft Dir dieser Beitrag hier bei Deinem Problem weiter:
https://help.nextcloud.com/t/update-von-15-0-7-auf-16-0-0-funktioniert-nicht-1071-specified-key-was-too-long-max-key-length-is-767-bytes/53340

Es wundert mich jedenfalls sehr, dass die Konvertierung bei Deiner MySQL-Version so viele Probleme macht. Ich kenn mich auch bei “HostEurope” nicht aus, was dort alles noch einzustellen geht.

Gruß
Crashandy

nextclouder · June 25, 2019, 6:23am

Guten Morgen,
das notwendige Barracuda-Format der DB für NC > 15.0.7 ist des Rätsels Lösung. Dazu der Auszug aus einer ‘Abbitte-Mail’ des HostEurope-Supports:

Bei der Überprüfung des Vorgangs hat Herr … festgestellt, dass unseren Kollegen bei der Bearbeitung Ihrer Anfrage bedauerlicherweise ein Fehler unterlaufen ist.

Es ist so: Aktuell wird das Barracuda-Format von unseren Datenbanken grundsätzlich nicht unterstützt. Und genau dieser Umstand ist bei der Bearbeitung Ihres Anliegens leider vollkommen übersehen worden.

Ich habe daraufhin Rücksprache mit unserer technischen Fachabteilung gehalten und habe erfahren, dass die Implementierung von Barracuda auf unseren Systemen in Planung ist und mit der Einführung von MYSQL 8 standardmäßig bei Ihrem Produkt verfügbar sein wird. Leider habe ich keine Auskunft zum voraussichtlichen Zeithorizont der geplanten Anpassung erhalten und kann Ihnen daher nicht sagen, wann Sie mit der eben erwähnten Einführung rechnen können.

Das bedeutet dann wohl, dass ich von weiteren NC-Updates ausgeschlossen bin. Trotzdem DANKE für die umfangreiche Hilfe, so konnten wir wenigstens den Grund für den Misserfolg finden.

Schönen Tag, Nextclouder

Crashandy · June 25, 2019, 7:33am

Hallo @nextclouder,

das ist ja mal eine gute (schlechte) Nachricht.

Bei mir laufen Nextcloud-Installationen sehr gut bei “1und1 IONOS” und bei “ALL-INKL.COM”, bei “STRATO” ist es eher befriedigend. Mein persönlicher Favorit ist aber die Nextcloud auf meiner Synology DS716+II mit 8 GB RAM.

Mal schauen was der Raspberry PI 4 mit 4 GB RAM so verspricht, da werde ich wohl doch noch schwach werden.

Viel Erfolg mit der baldigen Lösung für Dich.

Beste Grüße, Crashandy

Sanook · June 27, 2019, 1:15pm

Hier steht, wie man aufs Barracuda-Format umstellt:

https://www.allerstorfer.at/enabling-mysql-4-byte-support-for-nextcloud-on-ubuntu-18-04/

nextclouder · June 28, 2019, 5:41am

Danke, funktioniert aber nur, falls der Provider dies auch unterstützt, s.o.
Gruß NC

Sanook · June 29, 2019, 6:53am

Sag dem Provider, daß Barracuda und Antelope gleichzeitig funktieren. Also die Datenbanken, die nicht auf Barracuda umgestellt wurden trotzdem funktionieren.

nextclouder · July 1, 2019, 7:23am

Hmmmm, es geht wohl darum, dass seitens des Providers HostEurope die supportmäßig unterstützte Umstellung in Zukunft mit MySQL-8.x zu erwarten ist. Und wenn der Provider die INI-Einträge nicht setzt, kann man ihn bei SharedHosting nur schwer zwingen…