AWS RDS-এ MySQL এর একটি রুটিন আপগ্রেড সবুজ প্রতিলিপি প্রমোশনের সময় নীরব ডেটা দূষণ তৈরি করেছিল। প্রতিলিপি আপগ্রেড করা এবং এর কার্যকারিতা যাচাই করার পর, লেখকটি ট্রাফিক স্যুইচ করেছিল। এক ঘন্টা পর, একটি গুরুতর বাগ উঠে এসেছে: একটি টেবিল (টেবিল X) এর অটো-ইনক্রিমেন্ট IDs উৎস এবং প্রতিলিপিতে ভিন্ন ক্রমে বরাদ্দ করা হয়েছিল। আগে ID 1 ধারণকারী সطر এখন ID 26 ধারণ করে।

মূল কারণ একটি আগের মাইগ্রেশনে ফিরে যায় যা `ALTER TABLE X ADD COLUMN id INT NOT NULL AUTO_INCREMENT PRIMARY KEY` এর মাধ্যমে টেবিল X-এ একটি AUTO_INCREMENT প্রাইমারি কী যোগ করেছিল। ছয় সম্পর্কিত টেবিলকে এই নতুন ID-কে রেফারেন্স করতে JOIN-ভিত্তিক UPDATE স্টেটমেন্ট ব্যবহার করে আপডেট করা হয়েছিল। তবে, MySQL ডকুমেন্টেশন চेतাবনী দেয় যে প্রতিলিপিত টেবিল들에 AUTO_INCREMENT কলাম যোগ করার ফলে উৎস এবং প্রতিলিপিতে সطر ক্রম ভিন্ন হতে পারে, যা স্টোরেজ ইঞ্জিন এবং প্রসেসিং অর্ডারের উপর নির্ভর করে।

অসামঞ্জস্য উৎস ডেটাবেসের `binlog_format=MIXED` এর কারণে প্রকাশ পেয়েছিল। পাঁচ টেবিল তাদের UPDATE স্টেটমেন্টগুলো STATEMENT মোডে প্রতিলিপি করেছিল, ফলে প্রতিলিপি তার স্থানীয় (ভিন্ন) ID মানগুলোর সাথে JOIN-কে পুনরায় চালাল — সঠিকভাবে রেফারেন্সগুলো ম্যাপ করল। কিন্তু ছটো টেবিল, যেটিও একটি AUTO_INCREMENT কলাম ছিল, স্টেটমেন্ট-ভিত্তিক প্রতিলিপির জন্য নিরাপদ না মনে করা হয়েছিল এবং ROW মোডে লগ করা হয়েছিল। প্রতিলিপি উৎস থেকে কাঁচা রো পরিবর্তন প্রয়োগ করেছিল, উৎস-উত্পন্ন `x_id` মান들의 কপি তৈরি করেছিল যা এখন প্রতিলিপিতে ভুল সطرগুলিকে নির্দেশ করত।

AUTO_INCREMENT অ্যাসাইনমেন্টের ক্রম, MIXED বাইনারি লগিং এবং নিরাপদ না স্টেটমেন্ট সনাক্ত করার মধ্যে এই সূক্ষ্ম মিথ্যাক্রিয়া নীরব রেফারেনশিয়াল ইন্টিগ্রিটি ব্যর্থতার কারণ বnega। লেখক সতর্ক করেন যে এই ধরনের সমस्यাগুলো আপগ্রেডের সময় সহজে চুকে যেতে পারে কিন্তু ডেটা দ্রুত দূষিত করতে পারে।

মुख্য 엔টিটি: কোম্পানিগুলো: AWS, MySQL