आपका मुख्य डेटाबेस रात 3 बजे failover करता है और write एरर देने लगती हैं। आपके पहले कदम क्या होंगे?

पक्का करें कि नया primary सच में promote हुआ है और write ले रहा है, फिर देखें कि एप्लिकेशन दोबारा जुड़ीं या नहीं। सेहतमंद failover के बाद भी एरर बने रहने की आम वजह बासी connection pool और कैश हुई DNS होती है। replication lag जांचें और यह भी कि आपके RPO के मुकाबले कोई commit हुई write खोई तो नहीं। write ट्रैफिक बहाल करें, पुराने primary के fence होने की पुष्टि करके split brain खारिज करें, फिर पोस्टमॉर्टम में यह सवाल उठाएं कि failover पारदर्शी क्यों नहीं था।

पहला कदम है सच्चाई की पुष्टि: नए primary से सीधे जुड़ें और देखें कि वह recovery से बाहर है और write ले रहा है। अगर डेटाबेस सेहतमंद है और एप्लिकेशन अब भी एरर दे रही हैं, तो दिक्कत हमारी तरफ है, और मेरे अनुभव में वह आम तौर पर वहीं होती है। connection pool ऐसे पते के socket पकड़े रहते हैं जो अब write सर्व नहीं करता, या JVM ने DNS एंट्री हमेशा के लिए कैश कर ली, तो हल है rolling restart या ऐसा pool जो ठीक से validation करे। हमारे साथ एक बार ऐसा हुआ कि driver 30 सेकंड का TTL मानता था पर pool निष्क्रिय कनेक्शन कभी दोबारा जांचता ही नहीं था, तो रिकवरी में जरूरत से बीस मिनट ज्यादा लगे। फिर मैं promotion के पल का replication lag जांचता हूं यह देखने को कि हमने commit हुई write खोई तो नहीं, क्योंकि इससे बदल जाता है कि मुझे किसे बताना है। मैं यह पुष्टि भी चाहता हूं कि पुराना primary fence है और वापस आ जाए तो भी write नहीं ले सकता। एक बार write बहने लगें, तो पोस्टमॉर्टम का सवाल यह है कि यह अपने आप क्यों नहीं हुआ।