Sync Services: Periodic Tombstone Cleanup
One of the important topics in data synchronization is managing metadata used to track changes on the store. Just a quick reminder of the different kinds of metadata used in the demos so far:
- Adding inline columns to each table we plan to synchronize. Sync services runtime along with database triggers maintains the values for theses metadata columns.
- Adding tombstone table to track deletes
As time goes by the deletes accumulate in the tombstone table and the size of that table grows. This is a problem and you should be concerned about it. Pretty much all sync systems have to deal with this problem in one way or another; sync services is no exception. So the question now is how can we manage the size of the tombstone tables?
A common approach for tombstone cleanup is setting up an “expiration policy”. Simply add a datetime column to the tombstone table and setup a job that runs every couple of hours (or at non peak times) to cleanup all records that are older than a couple of weeks for example. This is one of the knobs that you would expose to your system admins to tweak based on their environment workload.
The tombstone expiration policy has some side effects though. Consider this; what happened to a client synchronizes with the server after a period longer than that of the expiration policy? Basically, deletes for some of the rows are gone. There is only two options here, either fail the client sync request and ask the client to reinitialize its local database, or let it proceed without synchronizing the deletes. Most sync solutions fails the client sync request thus force it to reinitialize. This option guarantees conversion.
Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews . See examples: Romantic Hotels in Myrtle Beach , Best Hotels in Seattle , Top 10 Hotels in Miami , Hotels with in-room hot tub and Kid friendly hotels in San Francisco . Your feedback is welcome on twitter.com/raveable, raveable blog.