In Kürze
- Beim Rückspielen eines Backups und anschließender Aktualisierung lies sich Nextcloud 32.0.8 nicht wieder in Betrieb nehmen, da der Updater mit dem Fehler SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'oc_jobs.PRIMARY' abgebrochen hat
- Schuld war am Ende in der Tabelle "oc_jobs" die fehlende Eigenschaft "AUTO_INCREMENT" für die Spalte "id", sprich den Primärschlüssel der Tabelle
Fehlerbeschreibung
Beim Update von Nextcloud 32.0.8 auf 32.0.13 und anschließend 33 mittels CLI schlug das Update fehl, nach einiger Recherche ist ein sicheres Update mit den verfügbaren PHP-Versionen erst ab PHP 8.4 möglich. Da dies beim Hoster über die CLI noch nicht verfügbar war, blieb nichts anderes übrig, als Datenbank und Daten aus dem Backup wiederherzustellen.
Die anschließenden Inbetriebnahme schlug jedoch fehl. Nextcloud erwartete, dass die installierten Apps mit dem "occ upgrade" Befehl aktualisiert werden. Soweit so gut. Der Upgrade-Befehl schlug jedoch fehl, aufgrund doppelt gemeldeter Einträge für den Index "0" in der Tabelle "oc_jobs".
OC\DB\Exceptions\DbalException: An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'oc_jobs.PRIMARY'Komplette Ausgabe im Update-Vorgang:
php82 occ upgrade
The current PHP memory limit is below the recommended value of 512MB.
Setting log level to debug
Updating database schema
Updated database
Updating <privacy> ...
OC\DB\Exceptions\DbalException: An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'oc_jobs.PRIMARY'
Update failed
Maintenance mode is kept active
Resetting log levelDa die Datenbank direkt aus dem Backup kam und Nextcloud vor einspielen des Backups und des versuchten Upgrade-Vorgangs funktionierte, konnte ich mir den Fehler beim besten Willen nicht erklären.
Auf Fehlersuche
Ein Blick in die Tabelle "oc_jobs" zeigte am Index 0, den folgenden Wert:
| id (PK) | class | argument | last_run | last_checked | reserved_at | execution_duration | argument_hash | time_sensitive |
| 0 | OCA\\UpdateNotification\\BackgroundJob\\AppUpdatedNotifications | null | 0 | 1785215487 | 0 | 0 | langer Hash-Wert | 1 |
Da sich hier über doppelte Werte beschwert wurde, war meine erste Vermutung, dass der Updater hier versucht, doppelte Einträge anzulegen, was aufgrund der zwingenden Eindeutigkeit durch den Primärschlüssel nicht möglich ist. Deshalb habe ich erst mal die Zeile gesichert und gelöscht und dann den Update-Vorgang erneut angestoßen, um zu sehen was passiert.
Erstes Ergebnis, der Updater liefert den gleichen Fehler. Verwunderung! Ein erneuter Blick in die Tabelle zeigte, am Index 0 wurde die Zeile erneut angelegt. Nach einigen weiteren Tests und auch das Ausführen des Reparaturbefehls mit "php82 occ maintenance:repair" brachten keine Erfolge.
Zeit sich die Tabellenstruktur genauer anzuschauen und mit anderen Installationen zu vergleichen...
Hierbei wurde sehr schnell ersichtlich, dass für den Primärschlüssel im Vergleich zu anderen Installationen die Eigenschaft "AUTO_INCREMENT" nicht gesetzt wurde, sprich das sich die "id" beim Anlegen eines neuen Datensatzes immer automatisch erhöht. Nach Änderung der Spalte mit AUTO_INCREMENT, lief dann auch die Aktualisierung anstandslos durch.
Warum die Eigenschaft "AUTO_INCREMENT" für die Spalte "id" nicht gesetzt war, bleibt jedoch für mich absolut unklar, da die Installation vor dem Rückspielen des Backups keine derartigen Fehler erzeugt hat. Auch hatte ich vorsorglich zwei unterschiedliche Backup-Stände der Datenbank probierte, beide lieferten jedoch das gleiche Ergebnis. Möglich also, dass die Struktur durch ein voriges Update bereits Fehler aufwies und erst durch die gezwungene Aktualisierung der Apps vor Inbetriebnahme hier diesen Fehler sichtbar gemacht hat.