3 ms·
No offense taken, the reason he went this path is the web sites involved seemed to be non-responsive. The core issue was actually a deadlock but he wasn't trai
by kator 12y ago
No offense taken, the reason he went this path is the web sites involved seemed to be non-responsive.
The core issue was actually a deadlock but he wasn't trained in detecting that and in the past just restarting the db "fixed it". Because of course all the sessions dropped and dead locks were resolved.
This was very much a high visibility production environment and yes we all make mistakes sometimes.. How else can we learn.. Trust me he never did that again! :-)
Remember, all of use were a doofus at one time and even worse many of us are every day.
It matters very little to me how people screw up, it matters how they recover, learn and avoid doing it again in the future.
My favorite saying "Originality in mistakes" if you're going to screw up make it big, creative and interesting. And please, don't repeat it.
- xxs 12y agoresolving deadlocks, other locks: log on via mysql, show processlist and kill the few long standing queries. It's an ugly solution and should not be used freely, yet a lot better than database restart.
- kator 12y agoExactly, but my partner wasn't the most patient person and in all fairness it was typical to 3,000 or more connections active to the database. With that many queries outstanding and the dead locks it was always a bit hairy trying to find them.. Meanwhile every teenager on the planet was hitting their refresh button trying to figure out why the site was down.. :-)