รีพลิเคชัน MySQL หลัง VPN ขาด: อ่านทั้งสองขั้นตอนก่อน

การเฝ้าติดตามรีพลิเคชันกลายเป็นสีแดงเมื่อ VPN ล่ม และสัญชาตญาณแรกคือการรีเซ็ตตำแหน่ง สัญชาตญาณนั้นคือสิ่งที่ทำให้การขัดข้องของเครือข่ายกลายเป็นปัญหาข้อมูล เส้นทางที่ล่มไม่ได้บอกอะไรเกี่ยวกับสิ่งที่รีพลิกาได้รับหรือปรับใช้ และนั่นคือสองขั้นตอนที่มีสองสถานะ อ่านทั้งสองแยกกันก่อนจะเปลี่ยนแปลงสิ่งใด

สองขั้นตอน สองคำตอบแยกกัน

รีพลิกาแบบอะซิงโครนัสทั่วไปทำงานสองอย่าง ตัวรับเชื่อมต่อกับต้นทาง ดึงเหตุการณ์ และเขียนลงบันทึกส่งต่อภายในเครื่อง ตัวปรับใช้อ่านบันทึกนั้นและดำเนินการเหตุการณ์บนรีพลิกา เมื่อเส้นทางขาด ตัวรับจะหยุดทันที ในขณะที่ตัวปรับใช้ยังคงประมวลผลงานค้างที่มีอยู่แล้วบนดิสก์ ดังนั้นการขัดข้องหนึ่งครั้งจึงสร้างคำถามสองข้อที่ต่างกัน การเชื่อมต่อกลับมาแล้วหรือไม่ และงานที่สะสมไว้ถูกปรับใช้แล้วหรือไม่ การมองทั้งสองเป็นคำถามเดียวจะเฉลี่ยสองสถานะเป็นคำตอบที่ทำให้เข้าใจผิด

การที่ตัวรับฟื้นตัวบอกคุณว่าเส้นทางทำงานอยู่ แต่ไม่ได้บอกว่าตัวปรับใช้ตามหลังอยู่เท่าไร หรือพบข้อผิดพลาดระหว่างที่ถูกตัดการเชื่อมต่อหรือไม่

อ่านแชนเนลด้วยคำสั่งที่ถูกต้อง

ใน MySQL 8.4 SHOW REPLICA STATUS คืนค่าหนึ่งแถวต่อแชนเนลที่กำหนดค่าไว้ ดังนั้นจงอ่านแถวของแชนเนลที่คุณหมายถึง ไม่ใช่แถวแรกในรายการ Replica_IO_Running แยกตัวรับที่เชื่อมต่อแล้วออกจากตัวรับที่กำลังเชื่อมต่อหรือหยุดอยู่ และ Replica_SQL_Running อธิบายตัวปรับใช้ จงอ่านคอลัมน์ข้อผิดพลาดข้าง ๆ ด้วย เพราะตัวรับที่เชื่อมต่อใหม่แล้วล้มเหลวทันทีจะทิ้งข้อความที่ธงสถานะใดก็ไม่แสดง เวอร์ชันเก่าใช้ชื่อคอลัมน์ต่างกัน ดังนั้นอย่าแปลสูตรเก่าโดยเพียงเปลี่ยนชื่อคำสั่ง

ตรวจสอบตัวตนของต้นทางและตัวกรองที่กำหนดค่าไว้ด้วย รีพลิกาที่ชี้ไปยังต้นทางผิด หรือถูกกรองแคบกว่าที่คุณคิด จะรายงานว่าสุขภาพดีในขณะที่กำลังทำสำเนาสิ่งอื่นจากที่คุณคาดไว้

ทำไมตัวเลขความหน่วงศูนย์จึงโกหกได้

ค่าความหน่วงเปรียบเทียบเวลาของเหตุการณ์ล่าสุดที่ปรับใช้กับเวลาปัจจุบัน เมื่อตัวรับหยุดไปหนึ่งชั่วโมง ตัวปรับใช้อาจประมวลผลงานค้างจนถึงปลายของสิ่งที่ได้รับ และตัวเลขก็ลดลงเป็นศูนย์แม้ว่ารีพลิกาจะตามหลังต้นทางอยู่หนึ่งชั่วโมง เมตริกนี้วัดคิวของตัวปรับใช้ ไม่ใช่ความทันสมัยของรีพลิกา

จงเปรียบเทียบธุรกรรมที่ดำเนินการแล้วกับสิ่งที่ต้นทางมีอยู่แทน การเปรียบเทียบนั้นทนต่อตัวรับที่หยุดชะงัก

การเก็บรักษาเป็นตัวกำหนดหน้าต่างการกู้คืนที่แท้จริง

การตามให้ทันต้องให้ต้นทางยังเก็บธุรกรรมที่รีพลิกาต้องการไว้ เมื่อธุรกรรมเหล่านั้นถูก purge แล้ว รีพลิกาจะดึงมาไม่ได้ และการเชื่อมต่อใหม่กี่ครั้งก็ไม่เปลี่ยนสิ่งนั้น

ด้วยการกำหนดตำแหน่งอัตโนมัติแบบ GTID ความล้มเหลวชัดเจน รีพลิกาขอประวัติที่ต้นทางไม่มีแล้วและปฏิเสธที่จะดำเนินต่อ ทางเลือกคือดึงเหตุการณ์ที่ขาดหายจากต้นทางที่ยังมีอยู่ หรือสร้างใหม่จากข้อมูลสำรองแล้วปล่อยให้ตามทัน การข้ามช่องว่างไม่ใช่การตามทัน และมันทิ้งรีพลิกาที่ข้อมูลขาดหายอย่างเงียบ ๆ จงวางแผนหน้าต่างโดยเปรียบเทียบระยะเวลาขัดข้องที่คาดไว้กับการเก็บรักษาบันทึกไบนารีบนต้นทางและอัตราการเปลี่ยนแปลง เพราะตัวเลขสามตัวนั้นเป็นตัวตัดสินว่าการขัดข้องกู้คืนได้หรือไม่เลย

ตรวจสอบการตามทัน ไม่ใช่สีของตัวชี้วัด

คืนเส้นทาง รวมถึงการแปลงชื่อและความปลอดภัยของการขนส่ง แล้วสังเกตว่าแชนเนลที่มีอยู่เชื่อมต่อใหม่ตามนโยบายของตัวเองหรือไม่ ให้ช่วงเวลาที่กำหนดไว้ก่อนเข้าแทรกแซง และบันทึกความคืบหน้าของการรับและการปรับใช้ที่ปลายทั้งสองของช่วงเวลานั้น แชนเนลที่รีสตาร์ตและแชนเนลที่ทันสมัยเป็นการค้นพบที่ต่างกัน

ยืนยันว่าตัวปรับใช้ไปถึงตำแหน่งปัจจุบันของต้นทาง ไม่ใช่แค่ปลายของงานค้างเก่า ตรวจสอบว่าไม่มีข้อผิดพลาดรออยู่ในตัวปรับใช้ เพราะเหตุการณ์ที่ล้มเหลวเพียงหนึ่งรายการจะหยุดความคืบหน้าในขณะที่ตัวรับยังรายงานว่าเชื่อมต่ออยู่ จากนั้นบันทึกหลักฐาน ชื่อแชนเนล สถานะของทั้งสองขั้นตอน ตำแหน่งที่ดำเนินการแล้ว และเวลา ตัวชี้วัดสีเขียวคือคำกล่าวอ้าง ตำแหน่งคือข้อเท็จจริง