2 ms·

That seems like a strange anecdote to me. The only reason I can think of to shutdown a production SQL database would be to do maintenance. In which case any s

by na85 12y ago

That seems like a strange anecdote to me. The only reason I can think of to shutdown a production SQL database would be to do maintenance. In which case any sane admin should be taking a backup in advance. That should be the first step. If the database is not a production server, does it matter if data was lost? If the production database crashed/bugged out and therefore needed to be halted, was it really ready for production in the first place? I don't mean to offend, but it sounds like your partner is a bit of a doofus.

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 ago
  resolving 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 ago
    Exactly, 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.. :-)

by na85 12y ago

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 ago
resolving 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 ago
  Exactly, 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.. :-)