I have two Unraid servers running Syncthing, and then have both been on the “Migrating old-style database to SQLite; this may take a while” step for a long time. One has been going since August 14, the other since the 17th (today is the 22nd). They both have very large databases; they aren’t exactly the same size, but they are both over 17,000 files and over 32 TB. Based on other posts I’ve seen on here and Reddit, it sounds like that amount of time is not out of the question for that large of a database.
However, both of them got interrupted during the migration the first time they started. I have an Appdata Backup plugin on Unraid that stops all my containers, backs up their appdata folders, and starts them again, and it automatically runs once a week. I forgot about that originally, and I have since disabled the scheduled backup job, so Syncthing is able to run uninterrupted now, but I don’t know if it’s actually still running or if it broke when the containers stopped mid-migration.
Where should I look for logs to see if it’s still actually migrating the DB? If I click the Logs button in the Unraid GUI it just gives me the “Migrating old-style database to SQLite; this may take a while” message with the timestamp it started. I poked around in the folder that’s mapped to /config in the container, but I didn’t see anything in there, although I could have missed it.
Since I have backups of the containers data folder from before the upgrade, I could theoretically restore the old folder and DB and start the migration again if it did get stuck/hung, but if it is actually still running I don’t want to interrupt it again.
Both servers don’t have much CPU or disk activity, so I don’t think system resources is the issue. That’s also why I wonder if it’s stuck. They both have plenty of free disk space on the volume the DB is on.
I’m running the Linuxserver.io container from the Unraid Community Apps, if that makes a difference.
The logs should look something like those you can see at Syncthing on SQLite -- help test! - #93 by calmh with reports after migrating each folder, so unless you have all that 32 TB of data located in a single folder, it does seem like the migration simply isn’t running.
Are you able to modify Syncthing’s command line options? If yes, you could add --log-file=default, which will then write logs to the Syncthing’s home folder (where the config, key, and certificate files are located).
I was able to add the --log-file=default option successfully (or at least, the container started correctly after I added it), but I don’t see a new log file in the main Syncthing config folder.
Can you check if there are syncthing processes actually running?
Edit:
I’ve also just noticed that your Syncthing version has been compiled with modernc-sqlite, which is slower than the C implementation of SQLite and basically untested, as the official releases of Syncthing don’t use it (see https://forum.syncthing.net/t/syncthing-on-sqlite-help-test/23981/59).
Well that’s odd. I didn’t do that, so apparently the version that Linuxserver.io is including in their docker image is using that version.
Also, interesting update…There was an update available for my container on Unraid, so I installed it. Figured at this point it can’t hurt, and maybe it switches to the correct version of SQLite. For whatever reason the “–log-file=default” option no longer works (the container instantly stops if I start it with the option added), but now if I open the web UI it shows me the migrating messages, and it’s is updating. If I refresh periodically it adds a line, so I guess it’s actually migrating correctly now. It’s doing it on both servers, and I didn’t need to restore the old copy of the DB.
Not worried, but it’s not optimal. It’s there as a valid fallback so it’s supposed to work and I don’t think it’s very much slower. The build process is a little bit more involved to get the standard/C version of SQLite compiled in.
