Question

I have designed a mechanism for deleting old data from MySQL tables.

Each row in a table includes current date measurement, and i am deleting chunks of records that are to old relatively to the current date.

Our product is planned to be deployed and be part of a bigger system. is it reasonable to assume that the clock of the computer will be consistent with it self(I am using current_date() as a function to retrieve the current date) in a production???

I do support small changes in the clock due to summer / winter time changing, although, bigger changes (more then a week) may cause the deletion of different data and not the oldest (even the current data could be deleted if the clock will be moved backwards below the minimum date)

Was it helpful?

Solution

The clock should be somewhat reliable assuming you have standard safeguards, such as syncing with a time server, and locked down to prevent accidental changes.

However, to mitigate any potential damage, consider adding another table that records each date that the records are deleted.

If your process runs weekly, then it would check this table to ensure that the current date is within a week of the last time it ran. This ensures that you won't skip any weeks, limiting potential "accidental" loss to a week. Adjust your window as needed.

If the check fails, require user intervention to get things back on track.

OTHER TIPS

I think this is a bad idea, you shouldn't rely on the users system time, what if they change it for example.

A better idea would be to take the MySQL server's time as a "central source of truth", as in always store based on current time (now()) on the MySQL server, and then prune also based on that time.

This means that even if the time of the server is set wrong, all query's will be out by an offset, representing the same period of time, instead of not matching.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top