27 ms·
I have a slightly higher threshold for considering something refreshing. It took several levels of basic mistakes for this to happen AND for the restore to be
by chesser 16y ago
I have a slightly higher threshold for considering something refreshing.
It took several levels of basic mistakes for this to happen AND for the restore to be as slow as it is.
Using MySQL with no transactions, no binary backups, no way to do a quick restore, and no separation of dev/production. DROP as opposed to DELETE cannot be rolled back and is therefore scary -- unless you aren't using transactions in the first place, in which case, WHEE!
- matwood 16y agoI don't have much MySQL experience, but have lots of experience with other RDBMSs. Large restores take a long time no matter what. They shouldn't take days, but since we don't know how large the events table was we have no way of knowing if a faster restore was possible. A hot restore which it sounds like what they are doing may take longer by simple fact that it's restoring while the table is in use. And DROPs (or truncates) are almost always used if the goal is to remove all the data in a table like you would want if rebuilding the entire system. Something like 100M record transaction is not generally considered a good thing.
- chesser 16y agoThey take a long time if you have to rebuild the indexes, which is what you have to do if you only have a text dump. For MySQL, using the standard format (MyISAM), you can just do a file copy if you bothered to do a proper backup of the binary files.