Skip to content

Commit 312ed6a

Browse files
authored
Merge pull request #15481 from nextcloud/jtr/docs-admin-db-ch-64bitIDs
docs(admin): clarify purpose of 64-bit database identifiers
2 parents 04caf13 + ecf2922 commit 312ed6a

1 file changed

Lines changed: 11 additions & 8 deletions

File tree

admin_manual/configuration_database/bigint_identifiers.rst

Lines changed: 11 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,15 @@
1-
======================================
2-
Convert to 64-bit database identifiers
3-
======================================
1+
================================================
2+
Prevent identifier exhaustion in large databases
3+
================================================
44

5-
Nextcloud uses big integers to store identifiers and auto-increment keys in the database.
6-
Because changing columns on huge tables can take quite a while (up to hours or days)
7-
depending on the number of files in the Nextcloud instance, this migration on the filecache
8-
and activity table has to be triggered manually by a console command.
5+
Database identifiers stored as 32-bit integers have a limited range. Larger Nextcloud
6+
installations can exhaust this range in heavily used tables, preventing new records from
7+
being created. Converting these identifiers and their auto-increment keys to 64-bit
8+
integers provides more capacity for future growth.
9+
10+
Changing columns in large tables can take several hours or even days, depending on the
11+
number of files in the Nextcloud instance. For this reason, conversion of the
12+
``filecache`` and activity tables must be triggered manually with a console command.
913

1014
The command can safely be executed. It will show a success message when there is nothing to do::
1115

@@ -22,6 +26,5 @@ to suppress the confirmation message append ``--no-interaction`` to the argument
2226

2327
sudo -E -u www-data php occ db:convert-filecache-bigint --no-interaction
2428

25-
2629
.. note:: Similar to a normal update, you should shutdown your Apache or nginx server or enable maintenance
2730
mode before running the command to avoid issues with your sync clients.

0 commit comments

Comments
 (0)