On Wed, Apr 01, 2009 at 09:42:30PM -0400, Sheeri K. Cabral wrote: > More specifically, CHECK TABLE doesn't do [significant? any?] writes like > REPAIR, OPTIMIZE and ANALYZE do. Although I'd argue that ANALYZE doesn't do > significant writes, because it's just updating the processor stats.
If we look at the pessimistic side of "all software is really broken" (as I do), then anything that's going to go through all your table and potentially kill it (e.g. repair table) should be executed with much caution. Which is why I don't like the idea of it being (by default) replicated beyond a single machine. Perhaps we should insert a commented out one though, so for forensic analysis you can see that weird stuff happenned after the master ran REPAIR TABLE ? So the REPLICATE keyword would just mean that it's stored non-commented in the replication stream. > It's also very useful for forensic purposes. I've used the binary logs many > times to see when lots of data was deleted, or when a table was dropped. > There's no other place to get that kind of information (unless, heaven save > you, you have a general log). For the paranoid, if we implemented an option to store reversable binlogs (whole rows, not just keys... so updates become inverted, insert becomes delete, delete becomes insert) you could then (easily) rollback to before REPAIR TABLE was done on master that screwed up your data. -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
