Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DB error when running migration [...] collides with the constraint [...] #41253

Closed
5 of 8 tasks
Miyamoto72 opened this issue Nov 3, 2023 · 87 comments · Fixed by #43357
Closed
5 of 8 tasks

DB error when running migration [...] collides with the constraint [...] #41253

Miyamoto72 opened this issue Nov 3, 2023 · 87 comments · Fixed by #43357

Comments

@Miyamoto72
Copy link

⚠️ This issue respects the following points: ⚠️

Bug description

Just found NC 28.0.0 beta available and started the update on the command line. Here's the output of the upgrade process:

Nextcloud Updater - version: v27.1.0rc3-15-gfa7af53

Current version is 27.1.3.

Update to Nextcloud 28.0.0 beta 1 available. (channel: "beta")
Following file will be downloaded automatically: https://download.nextcloud.com/server/prereleases/nextcloud-28.0.0beta1.zip

Steps that will be executed:
[ ] Check for expected files
[ ] Check for write permissions
[ ] Create backup
[ ] Downloading
[ ] Verify integrity
[ ] Extracting
[ ] Enable maintenance mode
[ ] Replace entry points
[ ] Delete old files
[ ] Move new files in place
[ ] Done

Start update? [y/N] y

Info: Pressing Ctrl-C will finish the currently running step and then stops the updater.

[✔] Check for expected files
[✔] Check for write permissions
[✔] Create backup
[✔] Downloading
[✔] Verify integrity
[✔] Extracting
[✔] Enable maintenance mode
[✔] Replace entry points
[✔] Delete old files
[✔] Move new files in place
[✔] Done

Update of code successful.

Should the "occ upgrade" command be executed? [Y/n] y
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Repair step: Repair MySQL collation
Repair info: All tables already have the correct collation -> nothing to do
Repair step: Copy data from accounts table when migrating from ownCloud
Repair step: Drop account terms table when migrating from ownCloud
Updating database schema
Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "ts_session" for table "oc_talk_sessions" collides with the constraint on table "oc_text_steps".
Update failed
Maintenance mode is kept active
Resetting log level

Keep maintenance mode active? [y/N]
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Maintenance mode disabled

Maintenance mode is disabled

Steps to reproduce

  1. have an update date NC 27 installation running
  2. be on beta channel
  3. start the upgrade once you find the notice

Expected behavior

Upgrade running smootly without errors

Installation method

None

Nextcloud Server version

27

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 22 to 23)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "example.org",
            "cloud.example.org",
            "192.168.1.*",
            "nextcloud.example.org"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.1.3.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "activity_expire_days": 14,
        "auth.bruteforce.protection.enabled": true,
        "blacklisted_files": [
            ".htaccess",
            "Thumbs.db",
            "thumbs.db"
        ],
        "cron_log": true,
        "enable_previews": true,
        "enabledPreviewProviders": [
            "OC\\Preview\\PNG",
            "OC\\Preview\\JPEG",
            "OC\\Preview\\GIF",
            "OC\\Preview\\BMP",
            "OC\\Preview\\XBitmap",
            "OC\\Preview\\Movie",
            "OC\\Preview\\PDF",
            "OC\\Preview\\MP3",
            "OC\\Preview\\TXT",
            "OC\\Preview\\MarkDown"
        ],
        "filesystem_check_changes": 1,
        "filelocking.enabled": "true",
        "htaccess.RewriteBase": "\/",
        "integrity.check.disabled": false,
        "knowledgebaseenabled": false,
        "logfile": "\/mnt\/STOR\/logs\/nextcloud.log",
        "loglevel": 0,
        "logtimezone": "Europe\/Berlin",
        "log_rotate_size": 104857600,
        "maintenance": false,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0
        },
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "overwriteprotocol": "https",
        "preview_max_x": 1024,
        "preview_max_y": 768,
        "preview_max_scale_factor": 1,
        "quota_include_external_storage": false,
        "share_folder": "\/Shares",
        "skeletondirectory": "",
        "theme": "",
        "trashbin_retention_obligation": "auto, 7",
        "updater.release.channel": "beta",
        "mail_smtpmode": "sendmail",
        "mail_sendmailmode": "pipe",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpsecure": "tls",
        "default_phone_region": "DE",
        "app_install_overwrite": [
            "dicomviewer",
            "files_mindmap",
            "carnet",
            "onlyoffice",
            "richdocuments",
            "richdocumentscode",
            "documentserver_community",
            "files_photospheres",
            "telephoneprovider",
            "audioplayer",
            "audioplayer_editor",
            "extract",
            "tasks",
            "ocsms",
            "files_trackdownloads",
            "ocdownloader",
            "twofactor_u2f",
            "checksum",
            "event_update_notification",
            "mindmap_app",
            "contacts",
            "deck",
            "spreed",
            "twofactor_webauthn",
            "maps"
        ],
        "has_rebuilt_cache": true
    }
}

List of activated Apps

Enabled:
  - activity: 2.19.0
  - admin_audit: 1.17.0
  - audioplayer: 3.4.0
  - bruteforcesettings: 2.7.0
  - calendar: 4.6.0-beta.1
  - carnet: 0.25.2
  - checksum: 1.2.2
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contacts: 5.5.0-beta.3
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - deck: 1.11.0
  - documentserver_community: 0.1.13
  - event_update_notification: 2.2.0
  - extract: 1.3.6
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_external: 1.19.0
  - files_mindmap: 0.0.29
  - files_pdfviewer: 2.8.0
  - files_photospheres: 1.27.0
  - files_reminders: 1.0.0
  - files_sharing: 1.19.0
  - files_trackdownloads: 1.11.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - impersonate: 1.14.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - mail: 3.5.0-beta.1
  - maps: 1.2.0
  - nextcloud_announcements: 1.16.0
  - notes: 4.8.1
  - notifications: 2.15.0
  - oauth2: 1.15.1
  - ocdownloader: 1.9.1
  - password_policy: 1.17.0
  - photos: 2.3.0
  - previewgenerator: 5.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - richdocuments: 8.2.2
  - richdocumentscode: 23.5.503
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - sociallogin: 5.5.4
  - spreed: 17.1.2
  - support: 1.10.0
  - survey_client: 1.15.0
  - suspicious_login: 5.0.0
  - systemtags: 1.17.0
  - tasks: 0.15.0
  - telephoneprovider: 1.0.3
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - twofactor_totp: 9.0.0
  - twofactor_webauthn: 1.2.0
  - updatenotification: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - encryption: 2.16.0
  - firstrunwizard: 2.17.0 (installed 2.7.0)
  - user_ldap: 1.19.0

Nextcloud Signing status

No response

Nextcloud Logs

none available

Additional info

No response

@Miyamoto72 Miyamoto72 added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Nov 3, 2023
@axeljerabek
Copy link

Enter your mysql console -> use nextcloud; (or whatever your database is called) -> drop index 'ts_session' from 'oc_text_steps';
-> occ upgrade -> occ add missing-indices.

@kesselb
Copy link
Contributor

kesselb commented Nov 3, 2023

The code is already changed: nextcloud/text#4553

Apparently an existing index was not renamed: nextcloud/text#4958

@joshtrichards joshtrichards changed the title [Bug]: Upgrade to NC 28.0.0-beta fails because of DB problems [Bug]: Upgrade to NC 28.0.0-beta fails because of DB: Index name "ts_session" for table "oc_talk_sessions" collides with the constraint on table "oc_text_steps" Nov 11, 2023
@march42
Copy link
Contributor

march42 commented Nov 15, 2023

I have an similar issue, with the tables switched, updating from 27.1.3.2 to 28 beta3

Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "ts_session" for table "oc_text_steps" collides with the constraint on table "oc_talk_sessions".

I dropped the index from oc_talk_sessions (drop index ts_session on oc_talk_sessions;) because i don't have Talk installed and the occ upgrade went smooth.

@solracsf solracsf changed the title [Bug]: Upgrade to NC 28.0.0-beta fails because of DB: Index name "ts_session" for table "oc_talk_sessions" collides with the constraint on table "oc_text_steps" [Bug]: Upgrade to v28 - Database error when running migration 28000Date20230906104802 Nov 27, 2023
@solracsf
Copy link
Member

Another report:

Exception: Database error when running migration 28000Date20230906104802 for app core Index name "afoa" for table "oc_social_follow" collides with the constraint on table "oc_social_3_follow".

@FahrJo
Copy link

FahrJo commented Dec 12, 2023

Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "rd_wopi_token_idx" for table "oc_officeonline_wopi" collides with the constraint on table "oc_richdocuments_wopi".

(Upgrade 27.7.4 to 28.0.0)

@JanSchnacki
Copy link

After successfully upgrading from 27.7.3 to 27.7.4 I then proceeded to upgrade to 28.0.0 and also got this error, but also with another index:

Database error when running migration 28000Date20230906104802 for app core Index name "nid" for table "oc_social_3_stream" collides with the constraint on table "oc_social_3_cache_actor".

I have no idea what to do now. I guess I'll see how to restore my site.

@JanSchnacki
Copy link

Other seem to have been able to just delete the offending index. Unfortunately, this "nid" index is the AUTO_INCREMENT column. That index is mandatory.

@Killerjoe
Copy link

Killerjoe commented Dec 12, 2023

I also have the same issue with different index and table:
Exception: Database error when running migration 28000Date20230906104802 for app core Index name "fs_storage_mimepart" for table "oc_filecache" collides with the constraint on table "oc_oc_filecache_wkiceckq6l6vf". Update failed.
What I can do here to finish the upgrade?

@Killerjoe
Copy link

I now have dropped the empty table "oc_oc_filecache_wkiceckq6l6vf" and was restarting the upgrade in the console with occ upgrade and the upgrade was running further.
I don´t know which sideeffects this will have, but as the table was empty, maybe not that much. We will see.

@joshtrichards
Copy link
Member

joshtrichards commented Dec 13, 2023

Related to this PR: #39506 for #39488

This new check is for postgres, but it runs against all dbs. That's fine because it should be fixed across the board.

The original report's issue was a legit new bug fixed in nextcloud/text#4998 due to the beta (people upgrading from the beta may be impacted).

But now this new check is catching a lot of ancient (e.g. unused/uninstalled/disabled) app db tables maybe? That would explain why these aren't already cleaned up. The reason I suspect this is because otherwise every one of these environments would have already been broken prior to this change.

@piojan
Copy link

piojan commented Dec 13, 2023

In my case on 28.0.0 release:

Exception: Database error when running migration 28000Date20230906104802 for app core Index name "activity_filter_app" for table "oc_activity" collides with the constraint on table "oc_oc_activity_zsczy1np8xz63".

Using the above suggestion, this has helped:
MariaDB [nextcloud]> drop index activity_filter_app ON oc_activity;

@joshtrichards
Copy link
Member

joshtrichards commented Dec 13, 2023

Alright been analyzing the reports so far and here's what I've got:

Index name "ts_session" for table "oc_talk_sessions" collides with the constraint on table "oc_text_steps".

Resulting from beta NC28. Fixed previously and was the original issue this report was about. However out of that a new check was added to proactively prevent that problem in the future (which is what all these new follow-on reports are actually about now that NC28 is out with this check in place). In theory that should have been fine, but a lot of existing installations have tables left from no-longer-installed apps as well as transient tables created for various reasons over the years long forgotten about... and there's where the below come in:

Index name "afoa" for table "oc_social_follow" collides with the constraint on table "oc_social_3_follow".

social_3 was an ancient table named used by the social app. That table is likely stale (unused) in this person's environment. Hence it was never fixed. Could/should just be dropped, but not really something we should do in Server for an app that may not even be installed anymore.

Index name "rd_wopi_token_idx" for table "oc_officeonline_wopi" collides with the constraint on table "oc_richdocuments_wopi".

Ditto. Educated guess is this person's environment has had both Office Online and Nextcloud Office installed, but currently only one - or neither - is in-use.

Index name "nid" for table "oc_social_3_stream" collides with the constraint on table "oc_social_3_cache_actor".

Ditto.

Index name "fs_storage_mimepart" for table "oc_filecache" collides with the constraint on table "oc_oc_filecache_wkiceckq6l6vf".

oc_oc_filecache_wkiceckq6l6vf sounds like a bogus table. Maybe something left around from some manually performed migration a long time ago or a partial restore or something.

Index name "activity_filter_app" for table "oc_activity" collides with the constraint on table "oc_oc_activity_zsczy1np8xz63".

Same situation as the last one.

Since we (in server that is) can't (well shouldn't) arbitrarily drop tables/indexes/etc for apps that may not even be installed anymore we should probably:

and/or

  • add logic in it to only check tables for apps that are currently installed and active so that we don't pick up dormant stuff that will never be fixed by their respective app (though this kinda defeats the purpose and doesn't fix the underlying problem)

Edit: There also might be some apps that don't support postgresql and thus ignore these constraints. So possibly a third block of people, but I'm not sure how many apps fall into that category these days.

@JanSchnacki
Copy link

Thank you @joshtrichards, while I'm comfortable with a lot of IT systems, I wouldn't be comfortable with doing such an analysis. I took your research result regarding "oc_social_3" and just removed all of those tables. The upgrade then finished successfully. (Now I have funny "Zend OPcache can't be temporary enabled" messages, that are flooding the logs, but I'll research that separately.)

@Neurozone
Copy link

I had the same issue for oc_social_3_* tables.
I dropped all the tables :
drop table oc_social_3_action; drop table oc_social_3_actor; drop table oc_social_3_cache_actor; drop table oc_social_3_cache_doc; drop table oc_social_3_client; drop table oc_social_3_follow; drop table oc_social_3_hashtag; drop table oc_social_3_instance; drop table oc_social_3_req_queue; drop table oc_social_3_stream; drop table oc_social_3_stream_act ; drop table oc_social_3_stream_dest; drop table oc_social_3_stream_queue; drop table oc_social_3_stream_tag;

And the upgrade went fine.
What is strange is I don't use the social app and I don't really remember installing it in the past, but I'm not sure, maybe I installed a really old version and had theses tables installed.

At least, after dropping it, upgrade worked without issue.

After looking in the code of the social app, I found no table name like that BUT this:
nextcloud/social#1250

Quite old.
So I suppose it belong to and older version of the app, that I tested and removed, but the tables were never removed and stayed in the db.

So @joshtrichards I think you are right on your analysis about these orphaned tables.

Thank you for that

@expressrussian
Copy link

expressrussian commented Feb 2, 2024

Yes, there are tables in the database that shouldn't be there. But this is not the fault of the Nextcloud user, nor is it under any circumstances the fault of the sysadmin.
Some of them are.

  • How do you handle tables created by users outside of the CMS that you have zero knowledge of? [I presume you don't blindly drop them since that could result in data loss]
    How do you handle tables created by users outside of the CMS?

You don't. Just leave them, maybe throw warning messages about foreign (not used) tables. Propose the admin to delete them, if they are surely not used by nextcloud.

Index name "fs_mtime" for table "oc_filecache" collides with the constraint on table "oc_filecache_temp".

  • Not from Server.

OK, i took some courage and dropped the "oc_filecache_temp" table.
The restarted occ upgrage went OK (a dozen of disabled apps).
Then as usual, Administration settings told me to recreate some indices (cli command provided).
Now in the Administration settings i have 2 warnings:
75 errors in the logs since 26 January 2024.
Server has no maintenance window start time configured. This means resource intensive daily background jobs will also be executed during your main usage time. We recommend to set it to a time of low usage, so users are less impacted by the load caused from these heavy tasks. For more details see the documentation ↗.

Well, what to do with these 75 errors? Just wait?
And for the maintenance window : the documentation URL does NOT provide a correctly spelled example for this specially syntaxed config/config.php. How to test the correctness of this config file?

@jurgenhaas
Copy link
Contributor

The cases that we experienced with our clients have always been old apps, that had been installed in the past and no longer exist or have been disabled or uninstalled.

A few have been, yes, but definitely not all[1].

My comment was about, what "we" experienced. And ours had all been from apps provided by the NC app store.

Speak as a maintainer of a huge CMS platform that comes with update hooks as well, I strongly want to state, that this is a showstopper and a terrible bug - if not a bug, it's a badly designed update function.

How do you handle tables created by users outside of the CMS that you have zero knowledge of? [I presume you don't blindly drop them since that could result in data loss]

Update hooks need to be provided by maintainers, either of core or from apps, and they address database tables explicitly by their name (plus optional prefix, something we do have as well). While I haven't looked into the update script from NC, the fact that it runs into issues with unknown tables must come from the fact, that it does something with all tables of the current database. Don't see how that should ever help. Just update the tables explicitly and leave all others untouched.

@joshtrichards
Copy link
Member

@expressrussian Glad to hear you got it working.

You don't. Just leave them, maybe throw warning messages about foreign (not used) tables. Propose the admin to delete them, if they are surely not used by nextcloud.

We're not triggering this check on every unused/unknown table. Only ones where there is already a conflict (see #39506). The messaging could use improvement as I already said. I agree. But the check is still going to be triggered where there are conflicts. Otherwise it just leads to later bug reports or help requests when things fail on their own in a different way.

I'll leave the rest of your questions, which are unrelated to this Issue, for the Nextcloud Help Forum, but you can look up the syntax elsewhere in the manual or in the config.sample.php. If you have suggestions, feel free to click the "Edit" button in the manual and/or send an issue into the documentation repository - https://github.com/nextcloud/documentation

@joshtrichards
Copy link
Member

joshtrichards commented Feb 2, 2024

While I haven't looked into the update script from NC, the fact that it runs into issues with unknown tables must come from the fact, that it does something with all tables of the current database. Don't see how that should ever help. Just update the tables explicitly and leave all others untouched.

@jurgenhaas Unfortunately not an option with some databases. For example, in PostgreSQL index names have to be unique inside the same database, not only per table. Since we support multiple database types, we have to keep things consistent even if someone is using, say, MySQL/MariaDB (which doesn't care as long as they're different tables).

EDIT: Oops forgot to follow-up on your other part:

My comment was about, what "we" experienced. And ours had all been from apps provided by the NC app store.

Okay, fair enough. Do you recall what apps? That would be useful to know.

@joshtrichards
Copy link
Member

joshtrichards commented Feb 2, 2024

Quick summary from my perspective: This Issue overall is tracking an error message that gets triggered by about 2-4 different root causes. Unfortunately, the correct response isn't the same for each of them and we can only handle some of them. At least half of the sample so far we can't do much about on our own.

We can:

  • improve the error message
  • fix any bugs in apps that are creating the situation (or encourage maintainers of those apps to do so)
  • revisit app removal data handling (I think for the most part we keep data around to permit easy re-enabling/re-installing)
  • provide some documentation to help people fix the situations we can't do anything about
  • suggest people ask for help through whatever the appropriate channels are for them if they're sure what to do / how to clean up their database

So for some this is a bug or, at the very least, an area of improvement here in server (or the docs!). But for other situations this is a local cleanup matter.

@FahrJo
Copy link

FahrJo commented Feb 2, 2024

We can:

  • improve the error message
  • fix any bugs in apps that are creating the situation (or encourage maintainers of those apps to do so)
  • revisit app removal data handling (I think for the most part we keep data around to permit easy re-enabling/re-installing)
  • provide some documentation to help people fix the situations we can't do anything about
  • suggest people ask for help through whatever the appropriate channels are for them if they're sure what to do / how to clean up their database

As I proposed as an idea in #42753, I would add to that list that this check should not be performed in the middle of the update process, potentially causing unexpected long downtime plus a lot stress as proven in this conversation, but as a pre-check (e.g. in the "Verify integrity" step), before the update can be started at all. Then an admin could without any time pressure investigate how to resolve the (upcoming) conflict. I'm guessing many users are waiting for some minor updates to upgrade their instance to 28.x.x, so I would expect more complaints to come in if the process stays like it currently is.

@sargreal
Copy link

sargreal commented Feb 2, 2024

Hi together,

I'm joining the discussion with another example of this migration failing in a (as i can see it) different way to the other problems. This time it is the mail app and the table oc_mail_recipients:

Exception: Database error when running migration 28000Date20230906104802 for app core
Foreign key name "FK_715DB7E31594979" for table "oc_mail_recipients" collides with the constraint on table "oc_mail_recipients".

Investigating this further I have found that it is maybe impossible to resolve this without just dropping all mail tables and reinstalling it?

Since the database schema for that table includes the key/index and the foreign key constraint, but I cannot drop the key, and it makes no sense to drop the foreign key:

  KEY `FK_715DB7E31594979` (`local_message_id`),
  CONSTRAINT `FK_715DB7E31594979` FOREIGN KEY (`local_message_id`) REFERENCES `oc_mail_local_messages` (`id`) ON DELETE CASCADE

MariaDB [nextcloud]> ALTER TABLE oc_mail_recipients DROP KEY `FK_715DB7E31594979`;
ERROR 1553 (HY000): Cannot drop index 'FK_715DB7E31594979': needed in a foreign key constraint

Edit: I remembered that there was a migration error with the mail app some years ago. I could fix it by manually doing those migrations in the database and creating arandomly named key for the local_message_id column.

@jurgenhaas
Copy link
Contributor

My comment was about, what "we" experienced. And ours had all been from apps provided by the NC app store.

Okay, fair enough. Do you recall what apps? That would be useful to know.

@joshtrichards it was social in our case. See #42173

@waja
Copy link

waja commented Feb 3, 2024

Here it was also related to the social app. As we didn't use them (anymore) and the app was removed anyway, I decided to run in my MySQL/MariaDB container to remove any related (and not needed) tables of the app:

mysql -u $MYSQL_USER --password=$MYSQL_PASSWORD $MYSQL_DATABASE -e "show tables" -s | grep "social" | xargs -I "@@" mysql -u $MYSQL_USER --password=$MYSQL_PASSWORD $MYSQL_DATABASE -e "DROP TABLE @@"

Maybe it's a good idea to check if there is nothing related to anything beside the social app:

mysql -u $MYSQL_USER --password=$MYSQL_PASSWORD $MYSQL_DATABASE -e "show tables" -s | grep "social" | xargs -I "@@" echo "@@"

@fwpml69
Copy link

fwpml69 commented Feb 4, 2024

Here is another error example, upgrade from 27.1.6 to 28.0.2.

Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "rd_wopi_token_idx" for table "oc_officeonline_wopi" collides with the constraint on table oc_richdocuments_wopi".

Deleted the oc_officeonline tables, upgrade completed. Side note, the app using these table was removed previously.

@szaimen szaimen added 2. developing Work in progress and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Feb 5, 2024
@szaimen szaimen assigned szaimen and unassigned juliushaertl Feb 5, 2024
@theorangepotato
Copy link

theorangepotato commented Feb 6, 2024

I also received this error, this time with Nextcloud News:

Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "news_items_starred_feed_id" for table "oc_news_items" collides with the constraint on table "oc_news_items_old".
Update failed

I do not believe I ever manually created this table. More analysis is available at nextcloud/news#2582.


EDIT: I now believe it is possible that I created the table, though I am still not sure. Anyway, deleting the table worked, and does not seem to have caused any other issues.

@joshtrichards
Copy link
Member

joshtrichards commented Feb 6, 2024

Index name "rd_wopi_token_idx" for table "oc_officeonline_wopi" collides with the constraint on table oc_richdocuments_wopi".

Looked into this one since it's popped up a couple times here. It's a long ago fixed bug. The MS OO integration app was using rd_wopi_token_idx and the rd stands for richdocuments so it was clearly wrong for that app. :-)

Any active deployment today uses oon_wopi_token_idx.

It should only be popping up in environments where an early version of OO app installed then removed during the first month or so if it's existence (and therefore never received the db migration updates that addressed this in nextcloud/officeonline#6 back in 2020).

If OO isn't in use, just drop the oc_officeonline_* tables.

@solracsf solracsf unpinned this issue Feb 17, 2024
@logopk
Copy link

logopk commented Mar 1, 2024

New try with docker nextcloud:28-apache

nextcloud  | Initializing nextcloud 28.0.2.5 ...
nextcloud  | Upgrading nextcloud from 27.1.6.2 ...
nextcloud  | => Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-upgrade
nextcloud  | Nextcloud or one of the apps require upgrade - only a limited number of commands are available
nextcloud  | You may use your browser or the occ upgrade command to do the upgrade
nextcloud  | Setting log level to debug
nextcloud  | Turned on maintenance mode
nextcloud  | Updating database schema
nextcloud  | Exception: Database error when running migration 28000Date20230906104802 for app core
nextcloud  | Index name "appconfig_config_key_index" for table "appconfig" collides with the constraint on table "oc_appconfig".
nextcloud  | Update failed
nextcloud  | Maintenance mode is kept active
nextcloud  | Resetting log level

Can I fix this myself?

@joshtrichards
Copy link
Member

@logopk:

Unfortunately #43357 is in v28.0.3 not v28.0.2. That is, the fix that makes this a soft fail during an upgrade. But either way you will have to fix this yourself, yes.

nextcloud | Index name "appconfig_config_key_index" for table "appconfig" collides with the constraint on table "oc_appconfig".

Is your dbtableprefix parameter value (in your config.php) set to '' by chance?

The error itself suggests you have appconfig (the live table - at least from that running container's perspective) and also another table called oc_appconfig (not the live one being used - at least not by that container's instance of Server). These are in conflict.

It looks a bit like you have two Nextcloud installations pointed at the same database? Or perhaps you did once in the past or something. Or maybe you changed your dbtableprefix or any number of other possibilities. Any of those ring a bell by chance?

If you don't have multiple Nextcloud instances using the same database...

  • Check your config.php for your dbtableprefix parameter value. If it's '' then you can probably safely eliminate the oc_appconfig table (be careful here though because oc_ is the more typical value... so probably for most people the oc_* would an indicator of the live table)
  • Make a backup of your database
  • Drop the not-in-use table (oc_appconfig if the above checks out in your case)

AGAIN: Backup your database before doing anything. See https://docs.nextcloud.com for database backup instructions.

If you need help verifying your setup because you're not sure about the above - or want a deeper inspection or just need help doing the drop - I suggest taking your query to the Help Forum - https://help.nextcloud.com

@logopk
Copy link

logopk commented Mar 2, 2024

Wow, that was a tough road.

Looking at your advice I saw almost all tables doubled with the prefix oc_ but without any data (except for oc_migrations with records dating back to 2017 (?)). dbtableprefix is empty. Never ever have I fiddled with the database before. So I have no idea where the oc_-tables come from.

After a dump I dropped all of them, ran the upgrade without errors, followed by a repair and disabled maintenance mode.

28.0.2.5 (newer is still not available as docker image) is running fine - well I hope so 😅.

Thank you for your help and giving me confidence to drop the tables in question.

Peter

PS: the upgrade tool did not always mention the oc_-table as conflicting. Sometimes the "real" table was mentioned as the one. So you must not go with the order in the message!

▶ docker exec -ti -u 33 nextcloud php occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Updating database schema
Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "profile_config_user_id_idx" for table "oc_profile_config" collides with the constraint on table "profile_config".
Update failed
Maintenance mode is kept active
Resetting log level

▶ docker exec -ti -u 33 nextcloud php occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Updating database schema
Exception: Database error when running migration 28000Date20230906104802 for app core
Index name "jobs_time_sensitive" for table "jobs" collides with the constraint on table "oc_jobs".
Update failed
Maintenance mode is kept active
Resetting log level

@nivekznews
Copy link

While updating from nextcloud 28 to 29 I do get the following error:
InvalidArgumentException: Index name "appconfig_config_key_index" for table "duyN_duyN_appconfig_mlvqw57nn8420" collides with the constraint on table "duyN_duyN_appconfig_bsstsbru9p9r6".

As a database I use mariadb.

In my database both tables 'duyN_duyN_appconfig_mlvqw57nn8420' and 'duyN_duyN_appconfig_bsstsbru9p9r6' do not exist. Are these intermediate tables for the upgrading process?
It only has the table duyN_appconfig, which does not have an index called appconfig_config_key_index and a table 0TSGD_appconfig (which has the index).

Bildschirmfoto vom 2024-06-19 10-17-15

@nivekznews
Copy link

I was able to resolve the issue by myself.
Basically I was able to rename the indices of one of the tables (with mysql queries the tables were accessible)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.