AWS RDS पर MySQL के एक नियमित उन्नयन ने हरी प्रतिकृति को पदोन्नत करने पर silenzieux डेटा क्षति का कारण बना। प्रतिकृति के उन्नयन और कार्यक्षमता की पुष्टि करने के बाद, लेखक ने ट्रैफ़िक स्विच कर दिया। एक घंटे बाद, एक गंभीर बग उभरा: एक तालिका (तालिका X) में इसके ऑटो-इन्क्रीमेंट IDs स्रोत और प्रतिकृति पर अलग क्रम में आवंटित किए गए थे। पहले ID 1 रखने वाली पंक्ति अब ID 26 रखती थी।

मूल कारण एक पहले के माइग्रेशन तक जाता है जिसने `ALTER TABLE X ADD COLUMN id INT NOT NULL AUTO_INCREMENT PRIMARY KEY` के माध्यम से तालिका X में एक AUTO_INCREMENT प्राथमिक कुंजी जोड़ी थी। छह संबंधित तालिकाओं को JOIN-आधारित UPDATE कथनों के माध्यम से इस नए ID को संदर्भित करने के लिए अपडेट किया गया था। हालाँकि, MySQL दस्तावेज़ चेतावनी देता है कि प्रतिकृत तालिकाओं में AUTO_INCREMENT कॉलम जोड़ने से स्रोत और प्रतिकृति पर पंक्ति क्रम भिन्न हो सकता है, जो भंडारण इंजन और प्रसंस्करण क्रम पर निर्भर करता है।

असंगति स्रोत डेटाबेस के `binlog_format=MIXED` के कारण प्रकट हुई। पाँच तालिकाओं ने अपने UPDATE कथनों को STATEMENT मोड में प्रतिकृत किया, जिससे प्रतिकृति ने अपने स्थानीय (विभिन्न) ID मानों के खिलाफ JOIN को फिर से निष्पादित किया — संदर्भों को सही ढंग से मैप किया। लेकिन छठी तालिका, जिसमें भी एक AUTO_INCREMENT कॉलम था, को स्टेटमेंट-आधारित प्रतिकृति के लिए असुरक्षित माना गया और इसे ROW मोड में लॉग किया गया। प्रतिकृति ने स्रोत से कच्ची पंक्ति परिवर्तन लागू किए, स्रोत-जनित `x_id` मानों की प्रतिलिपि बनाई जो अब प्रतिकृति पर गलत पंक्तियों की ओर इशारा करते थे।

AUTO_INCREMENT असाइनमेंट क्रम, MIXED बाइनरी लॉगिंग और असुरक्षित कथन पता लगाने के बीच इस सूक्ष्म अंतर्क्रिया ने silenzieux संदर्भात्मक अखंडता विफलता का कारण बना। लेखक चेतावनी देता है कि ऐसी समस्याएँ उन्नयन के दौरान आसानी से छूट जाती हैं लेकिन डेटा को तेज़ी से क्षति पहुँचा सकती हैं।

मुख्य इकाइयाँ: कंपनियाँ: AWS, MySQL