Quote: "Note that host is hardcoded to localhost. This means it should never connect to any machine other than the developer machine. Also: of course we use different passwords and users for development and production. We’re too tired to figure it out right now. The gremlins won this time." No they didn't. Instead one of your gremlins ran this function directly on the production machine. This isn't rocket science, ju…
We deleted the production database by accident
201–210 of 456 posts
Re: We deleted the production database by accident
#202Quote: "Note that host is hardcoded to localhost. This means it should never connect to any machine other than the developer machine. Also: of course we use different passwords and users for development and production. We’re too tired to figure it out right now. The gremlins won this time." No they didn't. Instead one of your gremlins ran this function directly on the production machine. This isn't rocket science, ju…
Re: We deleted the production database by accident
#203> Computers are just too complex and there are days when the complexity gremlins win. Wow. But then again it's not like programmers handle dangerous infrastructure like trucks, military rockets or nuclear power plants. Those are reserved for adults
Yep, I hate when I'm dealing with a system literally comprised of logic and a magic gremlin shows up to ruin my day. Seems like they though a casual "everyman" type of explanation would suffice, but really who would trust them after this?
Re: We deleted the production database by accident
#204Earlier quoted context omitted.
Not original poster, but up to 2010, default MySQL table type was MyISAM, which does not support transactions.
When a server runs out of memory a lot of strange things can happen. It can even fail while in the middle of a transaction commit. So transactions won't fix this.
Edit: and another problem is disk drives/controller caches lying and reporting write completion when not all data has actually reached stable storage
Re: We deleted the production database by accident
#205Re: We deleted the production database by accident
#206Earlier quoted context omitted.
Or a blog on being unable to drive your kid to an emergency room because you just finished a glass of wine over dinner. A problem with devices of that type is that they only test for a potential source of inability to drive safely. What we want is to test for an inability to drive safely. And while one is easy and might give some quick wins, the drawbacks scare me too much.
Being unable to take your car when your child needs to go to the ER would be terrible. Actually getting in the car while under the influence such of stress and alcohol sounds worse. I know someone who had a glass of wine just before her daughter needed to be brought to the hospital. This was just two days ago. She simply concluded she could not drive. Luckily, she was able to get a taxi.
I'm sure that would save a lot of lives. An ambulatory medical service, if you will.
Re: We deleted the production database by accident
#207Re: We deleted the production database by accident
#208Earlier quoted context omitted.
Not original poster, but up to 2010, default MySQL table type was MyISAM, which does not support transactions.
When a server runs out of memory a lot of strange things can happen. It can even fail while in the middle of a transaction commit. So transactions won't fix this.
Re: We deleted the production database by accident
#209Quote: "Note that host is hardcoded to localhost. This means it should never connect to any machine other than the developer machine. Also: of course we use different passwords and users for development and production. We’re too tired to figure it out right now. The gremlins won this time." No they didn't. Instead one of your gremlins ran this function directly on the production machine. This isn't rocket science, ju…
2 cents his hosts file points localhost to the prod db IP
Re: We deleted the production database by accident
#210Earlier quoted context omitted.
This is why I am against the current trend of over-complicating stacks for political or marketing reasons. Every startup nowadays wants microservices and/or serverless and a mashup of dozens of different SaaS (some that can't easily be simulated locally) from day 1 while a "boring" monolithic app will get them running just fine.
Microservices are easy to build and throw away these days. In startups time to market is more important than future investment in devops. In terms of speed of delivery they are not worse than monolithic architecture (also not better). For similar reasons SaaS is and must be the default way to build IT infrastructure, because it has much lower costs and time to deploy, compared to custom software development.