Hi
After 2 years of using Realm db, My database storage exceeds 250GB . I deeply investigate and see that there is another database name “__realm_sync” that takes a lot of storage.
So i want to delete this db, or the collections in this db like “history” for reducing storage.
But i don’t know the correct way to delete it.
Could u help me to give step by step for this?
Also what happens to the clients after i delete this db? For example in the mobile (client) user turn off wifi (offline mode) and update something to realm db. At that time, i terminate the sync of realm to delete the __realm_sync db, and re-enable it again. What happens when the user turn the wifi one (online mode) ?
Please do not delete that database. Sync is “history based”, and the history collection is how we send deltas, resolve conflicts, catch up clients after some time. Dropping that collection would result in sync just not working any more (you would need to terminate and re-enable)
Terminate sync and re-enable it: this is one way to immediately remove all history and re-create it. Note that in some cases (for older SDK’s) this can result in writes on devices that have not yet been synced to be “lost”. On newer versions of the SDK the default Client Reset logic should prevent this: https://www.mongodb.com/docs/atlas/app-services/sync/error-handling/client-resets/
Please let me know which route you would like to go and I would be happy to continue discussing this with you.
I’ve also seen what happens when someone deletes history lol, it’s not pretty.
But my recommendation would be Option 1, moving to Flexible Sync, it’s so much nicer and is honestly the main version of Sync I recommend to anyone that looks at Device Sync or asks me about it. Especially the performance improvement and it’s inability to over or under fetch because of underlying tech.
Thank you, @Tyler_Kaye
Yes please prioritize my app App Services.
Another question.
If i move to Flexible Sync, so we have to config it on backend and on the app, also release a new version of app. What happens to old app? old app is still using config of Partition Based sync. Should i force user to update to the new one ?
It seems like you terminated and re-enabled sync, so I will hold off on prioritizing any compaction processes. This should limit the amount of history for now which is great.
I did take a peek at your compactions and we were performing a lot of compactions on your application (about 30,000 partitions compacted in the last 3 days). Most of the compactions were successful at reducing the size by about 80%. This is with the exception of a single partition you have that is 62 GB and was only being partially compacted due to its size. We do have the ability to set more aggressive limits for this on-demand, so I can check back in in a few days to see if you still have a large partition.
As for migrating to Flexible Sync, we are planning on releasing a solution very soon that will allow you to upgrade the version of your SDK, release it to your applications, and then migrate the backend to use Flexible Sync instead of Partition Sync.
Will try to poke in to see if the initial sync completes soon,
Tyler
Thank @Tyler_Kaye
Yeah i terminated and re-enabled sync.
I’m intending to inform u haha.
“As for migrating to Flexible Sync, we are planning on releasing a solution very soon that will allow you to upgrade the version of your SDK, release it to your applications, and then migrate the backend to use Flexible Sync instead of Partition Sync.”
Hi, just took a look at your initial sync and looks like it is all done. IF you are curious here are some stats on how long things took (all collections are synced in parallel):
Worker completed initial sync for namespace "DetailActivityData" (214804945 docs scanned) in 12m52.625842952s
Worker completed initial sync for namespace "StaticHR" (321890108 docs scanned) in 1h21m50.33524404s
Worker completed initial sync for namespace "TotalActivityData" (9426129 docs scanned) in 27m50.944153949s
Worker completed initial sync for namespace "HRVData2" (1741170 docs scanned) in 10m8.47805795s
Worker completed initial sync for namespace "Spo2Data" (1251942 docs scanned) in 10m7.047377981s
Worker completed initial sync for namespace "ActivityModeData" (837124 docs scanned) in 10m4.935638082s
Worker completed initial sync for namespace "TemperatureData" (954323 docs scanned) in 10m2.879689105s
Worker completed initial sync for namespace "ScaleData" (62854 docs scanned) in 1m46.092303562s
Anonymizing the collection names above a bit.
As a warning, writes made by devices might be a little delayed in going to MongoDB for an hour or 2 as it churns through the backlog of writes. This is another thing that was very much improved and avoided in Flexible Sync. Either way, your app should return to normal within an hour or 2.
Just want to add, Flexible sync is so nice! It really is an upgrade from the older Partition based designs, I do highly encourage moving to it asap and just see how much nicer it is both on your data storage, and on the speed of the transactions!
All clients etc. I do consults for, I honestly push flexible sync when they want Realm as an option. Flexible sync is definitely a great long-term choice.
@Phuong_Dao_Quang You would definitely not regret going to Flexible sync. Even if you manually made the changes yourself, or waited for this new migration tool. It’s well worth it.
After hear that i want to move to Flexible sync asap haha.
Could you give me step by step to move to do that ? @Brock
If it’s too complex so i will wait for the migration tool from @Tyler_Kaye
