
It all started with a simple task: "Hey, let’s check if two databases have the same data over time!" Sounds harmless, right? Oh, how young and fool...
For further actions, you may consider blocking this person and/or reporting abuse
That's one hell of a story dude
Yep. Wait for upcoming similar incideint where we accidently deleted our production cluster
😳👀
omg, gotta hear this. giving you a follow.
Thank you :)
right
What a story, haha! If we think for a second, it actually makes total sense for such command to lock the database, but we never think these things when we have to 🤣
I'm curious tho - why you had to check if the two databases had the same data?
We doing some migration. after migration we would like to check data consistency between two db
Lol 😂.... Like what the hell for? 🙄 😏 😂
Nicely written! I am always scared of database migrations, so because of this paranoia, I double-triple check documentation to make sure everything is correct or not, and also have some backup plan ready in case something goes wrong. LMAO!
Well written hahaha, I can feel the pain and the stress of the mongodb expert 😁
😂
8 hours of coding and crying saves 5 minutes of reading the document.
Tip: Even experts are not trustable!
Yes That's one hell of a story dude
Didn't know this stuff. Thanks for this.
Your welcome :)
Ah! Being young and stupid. We all have to go through one of these "oh crap!"moments.
Well done on finding out what, to me at least, seems obvious :)
Thank you for sharing
👏 Yikes! Glad your team was able to recover. That would give me a heart attack!
Good share.. expecting much more content from you
Thank you for your kind words. sure will share more my experience
Awesome story. 🤭🙌
This is crazy. Never seen someone do this on a production database. Hope the senior fellow had a good laugh after some time
Yeah we have lot of fun and learning after that 😁
Interesting, very well written! Reminds me of dark days 😃. Had my fair share of DB servers go down, most were related to hardware failures or scaling issues and legacy DBs.
That’s quite a story! I really loved the way you wrote it, though. Also, thanks—I learned a new command from this.
Accidentally locking up your entire production database, that's got to be every engineer's worst nightmare.
"Change management" is the concept your company is looking for.
Too much useless (pathetic) code in this article.
Instead of a simple: "RTFM before executing something unknown in prod env".
I didn't like the presentation.
Thank you :)
Any suggestions for serverless database of MySQL
Sorry I don't not have expereince with MYSQL
Hey,
Its a great read, being a DEV head keeps spinning and reading this was something soothing to relax and joyous for a few mins.
Thank you for kind words.
below few articels that will also give you the same feeling
Damn that was a roller coaster. But comparing the hash was a curious idea that had to be tested 🙃.
Yeah that's what he did in live DB :)
I was having a stomach pain while reading. BTW Good narration
Lmao 😁 😂
This made my day 🌹 😆
🫢🫢🫢