# Nextcloud oc\_filecache growing huge : too many rows (hence backup fails with : lost connection to MySQL)

**URL:** https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951
**Category:** Support apps
**Tags:** nextcloud, english
**Created:** [August 23, 2021, 8:31am UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951 "2021-08-23T08:31:14Z")
**Posts on this page:** 7
**Page:** 2

<div class="post-metadata">

### Author: ![Lapineige](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/l/bc79bd/32.png) [@Lapineige](https://forum.yunohost.org/u/Lapineige)
#### Post date: [October 2, 2021, 10:17pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/21 "2021-10-02T22:17:34Z")

</div>

truncate did run faster in my case too.  
But the first time, it took days to remove a few million lines, and ~1 day to truncate.  
Now truncating takes \<1min, removing lines is still as slow.  
I don’t know why. Maybe the storage is less overloaded.

---

<div class="post-metadata">

### Author: ![erdoukki](https://forum.yunohost.org/user_avatar/forum.yunohost.org/erdoukki/32/2373_2.png) [@erdoukki](https://forum.yunohost.org/u/erdoukki)
#### Post date: [October 3, 2021, 3:04am UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/22 "2021-10-03T03:04:26Z")

</div>

> [@erdoukki](#):
>
> I’ll give a try (actually is already in process…)

works fine !

I do the trick…

LXC was too long and I stop it (it was the old instance)…  
Docker look faster and the truncate take only some few seconds…

Thanks

---

<div class="post-metadata">

### Author: ![wbk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/w/e0b2c6/32.png) [@wbk](https://forum.yunohost.org/u/wbk)
#### Post date: [October 3, 2021, 3:23pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/23 "2021-10-03T15:23:18Z")

</div>

To conclude my story with the oc\_filecache:

```auto
YNH_APP_CURRENT_VERSION: 18.0.4~ynh1
YNH_APP_ID: nextcloud
YNH_APP_INSTANCE_NAME: nextcloud
YNH_APP_INSTANCE_NUMBER: '1'
YNH_APP_MANIFEST_VERSION: 22.1.1~ynh1
YNH_APP_UPGRADE_TYPE: UPGRADE_APP

....

2021-10-03 13:30:31,174: DEBUG - + echo '[####################] > Upgrade of nextcloud completed'
2021-10-03 13:30:31,174: DEBUG - + ynh_exit_properly
2021-10-03 13:30:31,174: DEBUG - + local exit_code=0
2021-10-03 13:30:31,175: DEBUG - + rm -rf /var/cache/yunohost/download/
2021-10-03 13:30:31,175: INFO - [####################] > Upgrade of nextcloud completed
2021-10-03 13:30:31,178: DEBUG - + '[' 0 -eq 0 ']'
2021-10-03 13:30:31,178: DEBUG - + exit 0
2021-10-03 13:30:32,180: DEBUG - Checking that required services are up and running...
2021-10-03 13:30:34,176: SUCCESS - nextcloud upgraded
success: true

```

Nextcloud did go into some kind of error mode after the upgrade (and did not recover yet), but that is a story for another thread 😉

---

<div class="post-metadata">

### Author: ![wbk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/w/e0b2c6/32.png) [@wbk](https://forum.yunohost.org/u/wbk)
#### Post date: [October 3, 2021, 3:41pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/24 "2021-10-03T15:41:03Z")

</div>

Nextcloud is running again, and I see I lost my shares.

I am quite sure the losing of shared files and directories is not a result of the upgrade, but of truncating oc\_filecache (I remember reading somewhere that oc\_filecache is needed for the sharing).

So, keep in mind: don’t truncate oc\_filecache when you just shared a bunch of party photo’s with your friends!

For the actual error after the upgrade, I found it in /var/log/daemon.log. Many lines of:

```auto

Oct 3 15:25:07 online mysqld[553]: 2021-10-03 15:25:07 106 [ERROR] mysqld: Out of sort memory, consider increasing server sort buffer size
Oct 3 15:25:07 online mysqld[553]: 2021-10-03 15:25:07 106 [Warning] Sort aborted, host: localhost, user: nextcloud, thread: 106, query: SELECT `share`.`id`, `share`.`share_type`, `share`.`share_with`, `share`.`uid_owner`, `share`.`uid_initiator`, `share`.`parent`, `share`.`item_type`, `share`.`item_source`, `share`.`item_target`, `share`.`file_source`, `share`.`file_target`, `share`.`permissions`, `share`.`stime`, `share`.`accepted`, `share`.`expiration`, `share`.`token`, `share`.`mail_send`, `share_circle`.`unique_id` AS `share_circle_unique_id`, `share_circle`.`name` AS `share_circle_name`, `share_circle`.`display_name` AS `share_circle_display_name`, `share_circle`.`sanitized_name` AS `share_circle_sanitized_name`, `share_circle`.`source` AS `share_circle_source`, `share_circle`.`description` AS `share_circle_description`, `share_circle`.`settings` AS `share_circle_settings`, `share_circle`.`config` AS `share_circle_config`, `share_circle`.`contact_addressbook` AS `share_circle_contact_addressbook`, `share_circle`.`contact_groupname` AS `share_circle_contact_groupname`, `

```

I changed the value of  
`mariadb.cnf:sort_buffer_size = 64K`  
to  
`mariadb.cnf:sort_buffer_size = 16M`  
and  
`service mysql restart`  
for good measure.

---

<div class="post-metadata">

### Author: ![Lapineige](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/l/bc79bd/32.png) [@Lapineige](https://forum.yunohost.org/u/Lapineige)
#### Post date: [October 3, 2021, 5:10pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/25 "2021-10-03T17:10:00Z")

</div>

> [@wbk](#):
>
> So, keep in mind: don’t truncate oc\_filecache when you just shared a bunch of party photo’s with your friends!

Oh ! I didn’t know that ! ☹  
But can it build the cache again ? (those files would not be available in the mid-time, but then… ?)

---

<div class="post-metadata">

### Author: ![wbk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/w/e0b2c6/32.png) [@wbk](https://forum.yunohost.org/u/wbk)
#### Post date: [October 3, 2021, 7:19pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/26 "2021-10-03T19:19:48Z")

</div>

> [@Lapineige](#):
>
> But can it build the cache again ? (those files would not be available in the mid-time, but then… ?)

I am not so sure about that. Shares are in oc\_share, and poin to a record in oc\_filecache by fileid.  
After truncating oc\_filecache, I was happy enough to be able to upgrade, and did not take time to check if anything changed. In theory it could be that the upgrade from NC18 to NC22 messed up shares, but I doubt that (there would have been outcry if an upgrade did that :-P)

With the current data base scheme there would be no point in keeping oc\_share-records after deleting records from oc\_filecache: there’s no way to guarantee the correct relation between the share indications and the actual file being shared after rebuilding the cache (with new fileid’s).

---

<div class="post-metadata">

### Author: ![system](https://forum.yunohost.org/uploads/default/original/2X/f/f59fe8e3ee6b100b4f574d30d6e30479c68b89f0.png) [@system](https://forum.yunohost.org/u/system)
#### Post date: [November 2, 2021, 7:20pm UTC](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951/27 "2021-11-02T19:20:37Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

[Previous page](https://forum.yunohost.org/t/nextcloud-oc-filecache-growing-huge-too-many-rows-hence-backup-fails-with-lost-connection-to-mysql/16951.md?page=1)
