Aurora RDS में race condition मिलने का मामला

• AWS Aurora RDS में हुई race condition bug की एक ऐसी घटना, जिसे प्रयोग के जरिए सत्यापित किया गया और AWS से उसके कारण की पुष्टि भी मिली
• Hightouch ने event processing system को scale करते समय Aurora के failover के दौरान write instance switch fail होने की समस्या देखी
• लॉग विश्लेषण से पता चला कि दो instances ने एक साथ write operations किए, जिससे storage layer conflict और process termination हुआ
• AWS ने आधिकारिक रूप से पुष्टि की कि internal signal processing issue के कारण पुराने writer का demotion पूरा होने से पहले ही नए writer को promote कर दिया गया
• यह मामला बड़े distributed systems में concurrency control के महत्व और failover के समय write pause प्रक्रिया की आवश्यकता को रेखांकित करता है

---

पृष्ठभूमि

• 20 अक्टूबर 2025 को AWS के us-east-1 region में DNS management system के race condition bug के कारण outage हुआ
• इसकी वजह से Hightouch में event processing backlog तेज़ी से बढ़ा और सिस्टम अपनी सीमा तक पहुँच गया
• throughput सुनिश्चित करने के लिए 23 अक्टूबर को Aurora RDS instance upgrade किया गया, और इसी प्रक्रिया में एक नया race condition bug मिला

Hightouch event system की संरचना

• event collection और delivery संभालने वाला सिस्टम Kubernetes, Kafka, Postgres(Aurora) से बना है
• Postgres का उपयोग batch metadata queue के रूप में होता है, और यह प्रति सेकंड 5 लाख events को 1 सेकंड के भीतर process करता है
• Aurora PostgreSQL में write-only(primary) instance, read-only(replica) instances, और एक shared storage layer शामिल है

upgrade योजना

• read instance जोड़ना → मौजूदा reader को upgrade करना और failover priority देना → failover चलाना → मौजूदा writer को upgrade करना → अस्थायी reader हटाना
• यह प्रक्रिया AWS documentation में बताई गई है, और staging environment में load test के जरिए सत्यापित प्रक्रिया थी

upgrade प्रयास और समस्या

• 23 अक्टूबर को 16:39 EDT पर failover चलाने के बाद पुराना writer फिर से primary बनकर लौट आया
• दोनों प्रयासों में यही परिणाम मिला, और कुछ services में write failure error (DatabaseError: cannot execute UPDATE in a read-only transaction) आया
• लॉग विश्लेषण से ऐसे logs मिले जिनसे पता चला कि दो instances एक साथ write operations कर रहे थे और storage conflict के कारण terminate हो गए

race condition का कारण

• Aurora के failover process के step 3 (पुराने writer का demotion) और step 4 (नए writer का promotion) के बीच race condition हुई
• इसके कारण दोनों instances को एक साथ write permission मिल गई और conflict हुआ
• write traffic हटाकर दोबारा प्रयास करने पर failover सामान्य रूप से पूरा हुआ, जिससे race condition वाली परिकल्पना सिद्ध हुई

AWS की पुष्टि और प्रतिक्रिया

• AWS ने internal review के बाद पुष्टि की कि कारण writer demotion signal processing error था, और इसका Hightouch की configuration या traffic pattern से कोई संबंध नहीं था
• fix roadmap में शामिल है, और अस्थायी उपाय के तौर पर failover के दौरान writes रोकने की सिफारिश की गई

अंतिम कदम

• Hightouch ने cluster upgrade पूरा किया, और
  • planned failover से पहले write pause प्रक्रिया जोड़ी
  • writer role change monitoring को मज़बूत किया
  • operations manual (playbook) को update किया

मुख्य सीख

1. migration के दौरान अप्रत्याशित state transitions के लिए recovery तैयारी ज़रूरी है
2. observability सुनिश्चित करना समस्या पहचानने की कुंजी है
3. distributed system components के बीच प्रभाव को न्यूनतम रखने वाली design महत्वपूर्ण है
4. test environment और production environment के अंतर को समझना चाहिए

मूल लेख में इससे अतिरिक्त जानकारी नहीं है

[GN⁺]

Hacker News टिप्पणियाँ

• इस लेख को देखकर लगता है कि manual failover के दौरान भी अगर application सामान्य रूप से write traffic बनाए रखने की कोशिश करे, तो वह हमेशा fail हो जाता है
  लेकिन इससे कुछ सवाल उठते हैं। दूसरे Aurora users को यह समस्या हमेशा क्यों नहीं होती, AWS को इसका पता न हो ऐसा कैसे हो सकता है, और अगर पता है तो इसे P0-स्तर के emergency issue की तरह क्यों नहीं लिया जाता
  यह भी लग सकता है कि शायद in-flight transaction state या timeout जैसी सूक्ष्म conditions काम कर रही हों

  • Azure में इसी तरह की समस्या देखने के अनुभव से कहूँ तो, बहुत लोग इससे गुजरते हैं लेकिन restart से ठीक हो जाता है, इसलिए इसे अनदेखा कर देते हैं। root cause ढूँढना मुश्किल होता है, और vendor के साथ analysis की प्रक्रिया इतनी कष्टदायक होती है कि ज़्यादातर लोग बीच में छोड़ देते हैं
  • हमने भी AWS के साथ काम करते हुए यही समस्या confirm की थी। traffic pattern कोई असामान्य नहीं था, और दूसरे regions में यह reproduce नहीं हुआ। संभव है कि यह Aurora के fundamental failover mechanism defect का मामला हो
  • पहले Python + MySQL संयोजन में मैंने एक bug देखा था जहाँ SELECT ... FOR UPDATE चुपचाप fail हो जाता था और transaction autocommit mode में switch हो जाता था। किसी ने ध्यान नहीं दिया, तो मैं अकेला ही इसकी बात करता रहा, फिर कुछ महीनों बाद किसी और ने संपर्क किया कि उसे भी यही समस्या हुई। आखिरकार यह fix हुआ, लेकिन तब तक मेरी दिलचस्पी खत्म हो चुकी थी
    संबंधित लिंक: Stack Overflow प्रश्न
  • AWS अंदरूनी जानकारी लगभग साझा नहीं करता। API level से ऊपर की details नहीं दी जातीं, इसलिए अक्सर लगता है कि ऐसी समस्याओं को rare case मानकर आगे बढ़ जाते हैं
  • समस्या का एक हिस्सा इस बात से भी जुड़ा हो सकता है कि application ने reverted failover पर कैसे प्रतिक्रिया दी। लगता है cache टूट गया था और वह लगातार गलत primary पर write करने की कोशिश करता रहा। यह भी संभव है कि ऐसा failure कभी-कभी होता हो, लेकिन retry पर success मिल जाने से users AWS को report ही नहीं करते, इसलिए AWS को पता नहीं चलता

• Aurora PostgreSQL में मैंने कई बार unexpected behavior देखा है
  खासकर Zero Downtime Patching (ZDP) के दौरान session state गलत तरीके से बनी रही, जिसके कारण साधारण query भी statement_timeout से बहुत पहले cancel हो जाती थी
  मेरा अंदाज़ा है कि client के reconnect होने पर Aurora पिछले session की पुरानी timer state को ही carry forward कर देता है, और इस वजह से query तुरंत cancel हो जाती है

• हम भी बहुत high write traffic वाले environment में नियमित रूप से failover करते हैं, लेकिन AWS JDBC wrapper का उपयोग करके automated process के ज़रिए इसे स्थिर रूप से चला रहे हैं

  • वास्तव में Aurora की storage layer ने ACID violation को रोका, यानी data integrity बनी रही

• हम पैसे इसलिए देते हैं कि Aurora ऐसी बुनियादी invariants बनाए रखेगा, इसलिए ऐसी समस्या देखकर हैरानी होती है

  • लेकिन storage layer ने खुद concurrent writes को block करके सही काम किया

• logs और AWS की व्याख्या देखकर लगता है कि मूल लेखक की hypothesis गलत है
  ऐसा प्रतीत होता है कि promotion failure के बाद किसी external watchdog process ने cluster state mismatch पकड़ लिया और forcefully terminate (kill -9) कर दिया। storage subsystem से जुड़े messages उसके बाद आए

• मैं Aurora और RDS Postgres की performance comparison के बारे में पूछना चाहता हूँ।
  अगर multi-AZ या fast failover की ज़रूरत न हो, तो क्या RDS में gp3 64k IOPS configuration के साथ बेहतर performance मिल सकती है? Aurora खासकर insert performance में धीमा और costlier लगता है। benchmarks भी RDS settings साफ़ नहीं बताते, इसलिए उन पर भरोसा करना मुश्किल है

  • हमने Aurora PG 14 में 1 writer + 1~2 reader configuration के साथ बेहतर performance और कम cost पाई। Aurora में storage billing instance के हिसाब से नहीं बल्कि cluster level पर होती है, इसलिए यह फायदेमंद है।
    साथ ही IOPS को सीधे provision करने की ज़रूरत नहीं पड़ती और लगभग 80k IOPS मिल जाता है।
    IO billing के भी दो तरीके हैं, जहाँ pay-per-IO कम load वाले environment के लिए ठीक है, और fixed pricing mode ज़्यादा IO वाले workload के लिए बेहतर है।
    और Serverless लगभग हमेशा गैर-आर्थिक साबित हुआ। यह सिर्फ़ तब उपयोगी है जब छोटे peak time हों
  • हमारी team ने Aurora Postgres RDS में I/O cost explosion झेला। सिर्फ़ कुछ fuzzy queries की वजह से monthly bill $3,000 से ऊपर चला गया, जबकि यह मूल रूप से $100 से कम होना चाहिए था
  • Aurora की cost, performance, latency तीनों से निराश होकर आखिरकार हमने on-premises PostgreSQL पर migrate कर लिया
  • Aurora MySQL के हिसाब से देखें, तो वही IOPS RDS पर match करने के लिए काफी ज़्यादा cost आती थी
  • Aurora EBS का उपयोग नहीं करता, और storage type या latency चुनने का विकल्प नहीं देता। केवल IO billing model चुना जा सकता है

• AWS engineers जिस “Lego block model” की बात करते हैं, वह यहाँ साफ़ दिखता है
  storage layer को पूरी तरह independent डिज़ाइन किया गया, ताकि upper service fail होने पर भी data consistency बनी रहे। मुझे यह AWS engineering का अच्छा उदाहरण लगता है

• कहा गया कि AWS ने “failover के दौरान writes रोक दो” जैसी recommendation दी थी, तो जानना चाहता हूँ कि क्या संबंधित case number साझा किया जा सकता है

  • हम भी Aurora MySQL इस्तेमाल करते हैं, इसलिए जानना चाहते हैं कि यह recommendation MySQL पर भी लागू होती है या नहीं

• यह जानकर राहत है कि ऐसी समस्या सिर्फ़ मेरे साथ नहीं हुई

  • AWS Support ने शुरुआत में यह कहकर असहमति जताई कि कारण replication lag था, लेकिन उन्होंने 24 घंटे पुराने metrics देखकर निष्कर्ष निकाला था। मैं सच में जानना चाहता हूँ कि आखिर कौन-सा failure हुआ था, और दूसरे region में यह reproduce क्यों नहीं हुआ

• Aurora की compute-storage separation architecture दिलचस्प लगती है
  MSSQL का Hyperscale भी इसी तरह की संरचना है, और Azure services में यह लगभग अकेला ऐसा product है जिसे मैं वास्तव में इस्तेमाल करने लायक मानता हूँ