sigaloid
commented
2 years ago For issues of syncing I have found my best (and only) option is just sending the document.db directly.
Closed sigaloid closed 2 years ago
sigaloid
commented
2 years ago For issues of syncing I have found my best (and only) option is just sending the document.db directly.
zadam
commented
2 years ago Table counts: notes: 0, note_revisions: 28, branches: 0, attributes: 0, api_tokens: 0
Hi, it looks like there's 0 notes in your document which is quite strange and should not happen.
Do you know how did this happen?
sigaloid
commented
2 years ago I was using the server version in the browser for very long but installed the desktop version finally, I simply set up syncing on the local version by logging in.
On the server, I clicked fill entity changes records, fix consistency issues, and vaccum'd the database before syncing.
sigaloid
commented
2 years ago This is really weird - it seems like when it's done syncing, it starts pushing changes out (despite no local changes being made)
Pulled 1000 changes in 456 KB, starting at entityChangeId=212716 in 313ms and applied them in 2835ms, 498 outstanding pulls
Returning sync stats: {"initialized":false,"outstandingPullCount":498}
200 GET /api/sync/stats with 48 bytes took 0ms
Returning sync stats: {"initialized":false,"outstandingPullCount":498}
304 GET /api/sync/stats with 48 bytes took 1ms
Returning sync stats: {"initialized":false,"outstandingPullCount":498}
304 GET /api/sync/stats with 48 bytes took 1ms
Pulled 498 changes in 224 KB, starting at entityChangeId=213716 in 271ms and applied them in 1505ms, 0 outstanding pulls
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
200 GET /api/sync/stats with 46 bytes took 1ms
Finished pull
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms
Sending message to all clients: {"type":"sync-push-in-progress","lastSyncedPush":0}
***// Begins pushing out changes...***
Pushing 1000 sync changes in 545ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms
Sending message to all clients: {"type":"sync-push-in-progress","lastSyncedPush":1014}
Pushing 1000 sync changes in 656ms
Sending message to all clients: {"type":"sync-push-in-progress","lastSyncedPush":2014}
Pushing 1000 sync changes in 598ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms
Sending message to all clients: {"type":"sync-push-in-progress","lastSyncedPush":3014}
Pushing 1000 sync changes in 509msI think every time I clear local data and retry syncing, the total changes count increases (I think it's doubled since last time). Like, syncing causes the total sync count to double, as if there's a problem locally causing the changes to be considered "different" so it re-pushes them back out. I've never seen this happen before while syncing though
sigaloid
commented
2 years ago Okay, so the syncing has finished completely except the logs are filled with
It does indeed sync completely now, though, and the application runs as expected.
zadam
commented
2 years ago Could you please share full desktop client log to zadam.apps@gmail.com?
I'd like to understand how it got to that 0 notes. That doesn't seem right. Thanks.
sigaloid
commented
2 years ago I can't replicate the zero notes, but here's a log from a brand new sync, clean 0.48.3 version, nothing locally:
It started pushing changes out for some reason, I cancelled it in the middle of it. I'm going to restart the docker container in a blank folder and start from scratch.
Manually moving the .db file didn't fix it either :upside_down_face: I must be doing something wrong with my sync setup
zadam
commented
2 years ago Hi, this is actually expected. The client pulls the changes, but when it comes to pushing, it sees the new changes in the database but doesn't remember they actually come from the same server, so it sends them back to their source. Server will then ignore them since they were already applied before.
So this is an inefficiency issue where each change will be sent needlessly twice. It is certainly fixable, but the sync protocol is quite tricky and so far I was putting more emphasis on making sure the sync will end correctly.
But it should be addressed at some point.
sigaloid
commented
2 years ago Ah. I saw the server document.db doubling in size at some point when it was doing that and I assumed that if it starts doing that, it means it got confused and starts saving each change separately (and this was happening every new device I added, so I was thinking it would exponentially increase for every new device). I just reset and reimported serverside and clientside, and it did indeed do the same thing. Apologies! At least now I did some well-needed cleaning out of my database :p thank you so much for the help!
Trilium Version
0.49.1-beta
What operating system are you using?
Other Linux
What is your setup?
Local + server sync
Operating System Version
Fedora
Description
I tried syncing locally from a server instance