How We Accidentally Declared War on Our Own Database
Boopathi

Boopathi @programmerraja

About: Programmer with curious to learn different technologies and develop cool product from that

Location:
India
Joined:
Jul 13, 2020

How We Accidentally Declared War on Our Own Database

Publish Date: Feb 15
134 44

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 foolish we were.

Our team did some research (aka Googling) and found a potential solution. That’s when our senior teammate our so-called MongoDB expert stepped in. We called him that because he had slightly more experience than the rest of us.

Anyway, he found The Command a magical piece of code that would generate the hash for the collection

db.runCommand({ dbHash: 1, collections: [] }).md5  
Enter fullscreen mode Exit fullscreen mode

He was thrilled! Excited! Practically bouncing in his chair! His master plan? Run this command on both databases on each collection, compare the hashed, and if they didn’t match boom! Data inconsistency detected!

First, he tested it on a small database. It worked. Beautiful. Perfect. No issues at all. So, naturally, he did what any overconfident engineer would do:

"Let’s try this on the live database with 200 million records!"

This, my friends, was the moment it all went horribly, terribly wrong.

The Moment of Doom

At first, everything seemed fine. He ran the command. He waited. And waited. And waited.

Then he got impatient and thought, Huh, maybe I should stop this command? So he tried to kill it.

Plot twist: The command refused to die.

mongodb connection

Seconds later, all our database connections spiked to 2,900%. Every single query stopped working. The app crashed. Users were probably screaming at their screens.

At this point, chaos erupted. Alarms were ringing (in our heads). People were yelling. Our team was frantically Googling like hackers in a bad Hollywood movie.

But no matter what we tried, nothing worked. But to reduce the connection in mongodb we were stoped some not crucial service and we try to keep the connection as low as possible

Our one innocent looking command had completely paralyzed the entire database. It was like throwing one small rock into a river and somehow causing a tsunami.

The Horrifying Truth

Then, finally, our MongoDB expert (who, at this point, had aged 10 years in stress) decided to read the official documentation. And there, hidden like a villain’s evil plot, was this small but deadly sentence:

The dbHash command locks the database and doesn’t allow any changes until it finishes.  
Enter fullscreen mode Exit fullscreen mode

Translation: "HAHA, YOU CAN’T DO ANYTHING UNTIL I’M DONE. GOOD LUCK, LOSERS!"

At this point, we had two choices:

  1. Sit there and hope for a miracle.
  2. Find a way to forcefully wake up our poor, frozen database.

Luckily, our DevOps teammate had an idea. "Let’s scale up the database. That’ll force a restart and kill the stuck command!"

We nodded furiously and watched as he logged into MongoDB Atlas, cranked up the database size like turning up the heat on a broken stove, and hit the magic button.

The Resurrection

For the next five minutes, we sat there in complete silence, watching the screen, praying to the database gods.

Then BAM! The database restarted! The stuck command was gone! The app was alive again!

We cheered. We cried. We swore to never, ever, EVER run random commands on a live database again.

Lesson Learned:

Always read the instructions before trying something new. And maybe just maybe don’t test experimental ideas on a live system unless you enjoy heart attacks.

Finally, if the article was helpful, please clap 👏and follow, thank you!

Comments 44 total

  • Safin Ahmed
    Safin AhmedFeb 15, 2025

    That's one hell of a story dude

  • bakir claude-01
    bakir claude-01Feb 15, 2025

    Yes That's one hell of a story dude

  • Kevin Naidoo
    Kevin NaidooFeb 15, 2025

    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.

  • Madhurima Rawat
    Madhurima RawatFeb 15, 2025

    That’s quite a story! I really loved the way you wrote it, though. Also, thanks—I learned a new command from this.

  • NoobDev
    NoobDevFeb 15, 2025

    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!

  • Aditya R Pai
    Aditya R PaiFeb 16, 2025

    I was having a stomach pain while reading. BTW Good narration

  • Srikanth Venkata Kapila
    Srikanth Venkata KapilaFeb 16, 2025

    This is crazy. Never seen someone do this on a production database. Hope the senior fellow had a good laugh after some time

    • Boopathi
      BoopathiFeb 16, 2025

      Yeah we have lot of fun and learning after that 😁

  • Rense Bakker
    Rense BakkerFeb 16, 2025

    Well written hahaha, I can feel the pain and the stress of the mongodb expert 😁

  • Shrijal Acharya
    Shrijal AcharyaFeb 16, 2025

    The dbHash command locks the database and doesn’t allow any changes until it finishes.

    Didn't know this stuff. Thanks for this.

  • Shawn Monteiro
    Shawn MonteiroFeb 16, 2025

    Damn that was a roller coaster. But comparing the hash was a curious idea that had to be tested 🙃.

    • Boopathi
      BoopathiFeb 16, 2025

      Yeah that's what he did in live DB :)

  • Ddhruv
    DdhruvFeb 16, 2025

    Tip: Even experts are not trustable!

  • Gaurav Verma
    Gaurav VermaFeb 16, 2025

    You had to make that mistake on live production to learn you shouldn't do it?

    Someone should be dipped in tar and have feathers put on them

    • Boopathi
      BoopathiFeb 16, 2025

      Whoa, that’s a bit extreme, don’t you think? We all make mistakes, and it’s how we handle them that counts. Let’s just chalk it up to a learning experience and focus on making sure it doesn’t happen again. No need for anyone to be tarred and feathered over it!

      • Gaurav Verma
        Gaurav VermaFeb 17, 2025

        The tar dipping and feathers were proverbial, but someone should have gotten a slap on the wrist and a big lecture why we do not run analytics on live DB

        No its not extreme, there are times when yelling is justified.

      • Gaurav Verma
        Gaurav VermaFeb 17, 2025

        There are acceptable mistakes and then these

  • saurabh rawat
    saurabh rawatFeb 16, 2025

    🫢🫢🫢

  • Akhil Srivastava
    Akhil SrivastavaFeb 16, 2025

    Any suggestions for serverless database of MySQL

    • Boopathi
      BoopathiFeb 16, 2025

      Sorry I don't not have expereince with MYSQL

  • Franklin Strube
    Franklin StrubeFeb 17, 2025

    👏 Yikes! Glad your team was able to recover. That would give me a heart attack!

  • mbienvenu
    mbienvenuFeb 17, 2025

    Good share.. expecting much more content from you

    • Boopathi
      BoopathiFeb 17, 2025

      Thank you for your kind words. sure will share more my experience

  • Trumps Ear
    Trumps EarFeb 17, 2025

    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.

  • Nhật Trường Nguyễn Hữu
    Nhật Trường Nguyễn HữuFeb 17, 2025

    8 hours of coding and crying saves 5 minutes of reading the document.

  • Swati Mishra
    Swati MishraFeb 17, 2025

    Awesome story. 🤭🙌

  • Emiliano
    Emiliano Feb 17, 2025

    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 :)

  • Humayon Khan
    Humayon KhanFeb 17, 2025

    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.

  • ianstigator
    ianstigatorFeb 17, 2025

    "Change management" is the concept your company is looking for.

  • Stanley Sathler
    Stanley SathlerFeb 18, 2025

    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?

    • Boopathi
      BoopathiFeb 18, 2025

      We doing some migration. after migration we would like to check data consistency between two db

    • TheCodingBam
      TheCodingBamFeb 21, 2025

      Lol 😂.... Like what the hell for? 🙄 😏 😂

  • Shmuel
    ShmuelFeb 18, 2025

    Thank you for sharing

  • Michael Phillips
    Michael PhillipsFeb 20, 2025

    Accidentally locking up your entire production database, that's got to be every engineer's worst nightmare.

  • TheCodingBam
    TheCodingBamFeb 21, 2025

    Lmao 😁 😂

    This made my day 🌹 😆

Add comment