한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

คู่มือเกมแลค › L12 ฐานข้อมูล

การทำสำเนาข้อมูลล่าช้า Replication lag

ID สาเหตุ db-replica-lag · ผู้รับผิดชอบหลัก อินฟรา DB (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

การเขียนไปที่ DB หลัก ส่วนการอ่านทำจาก replica ถ้า replica ตามไม่ทัน ข้อมูลที่เพิ่งเขียนจะยังมองไม่เห็น

ทำไม การเขียนกระจุกที่ DB หลักจน replica ตามหลังไปหลายวินาที → ผลคือ อ่านข้อมูลที่เพิ่งเซฟจาก replica แล้วยังไม่มี → บนหน้าจอ ไอเทมที่เพิ่งซื้อไม่ขึ้น, ราคาในตลาดซื้อขายเป็นค่าเก่า, บั๊กแจกของซ้ำ

อาการ
กดไม่ติด/โรลแบ็ค
ปัจจัย
ความหน่วง
ใครเจอ
เฉพาะบางฟีเจอร์
เกิดเมื่อไร
ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก อินฟรา DB (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม
อ่านข้อมูลที่เพิ่งเขียนจาก DB หลัก, ตรวจว่าแจกไปแล้วหรือยังและแจกของใน DB หลักภายในทรานแซกชันเดียว (กันการแจกซ้ำด้วย unique key หรือ UPDATE แบบมีเงื่อนไข)
งานฝั่งทีมอินฟรา
ตั้ง alert replication lag, ให้ replica มีสเปกเท่า DB หลักหรือสูงกว่าและใช้ parallel replication, แบ่งการลบข้อมูลจำนวนมากเป็นชุดเล็ก ๆ, ดูแลคิวรีสรุปผลที่รันนานบน replica
บนกราฟ
สูงตามจำนวนคนและโหลด · replication lag (วินาที)
จุดที่ต้องดู
MySQL ดู Seconds_Behind_Source ของ SHOW REPLICA STATUS บน replica (เวอร์ชันก่อน 8.0.22 ใช้ SHOW SLAVE STATUS) PostgreSQL ดู write_lag, flush_lag และ replay_lag ใน pg_stat_replication บนเซิร์ฟเวอร์หลัก ส่วน RDS ดู ReplicaLag
สัญญาณว่าใช่
ช่วงที่มีคนแจ้งว่า “มองไม่เห็น” ค่า lag อยู่ที่หลายวินาทีขึ้นไป และเมื่อ lag หายแล้วดูอีกครั้งก็ปกติ lag เพิ่มขึ้นช่วงที่การเขียนทะลัก ลบข้อมูลจำนวนมาก หรือมีคิวรีสรุปผลยาว ๆ บน replica
สัญญาณว่าไม่ใช่
lag ใกล้ 0 แต่ยังมองไม่เห็น: น่าจะเป็นแคชของเซิร์ฟเวอร์เกมหรือการซิงก์
วิธีตรวจ
ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม
แม้การเขียนไม่มาก replica ก็ตามหลังได้ การลบข้อมูลจำนวนมากครั้งเดียวที่ใช้เวลา 10 นาทีบน DB หลัก จะทำให้ replica ตามหลังไปนานเท่ากันระหว่างที่รันซ้ำบน replica และคิวรีสรุปผลที่รันนานบน replica ก็ทำให้ตามช้าลงด้วย

แหล่งอ้างอิง

  1. SHOW REPLICA STATUS Statement MySQL
    Seconds_Behind_Source: ส่วนต่างเทียบกับเวลาที่ DB หลักบันทึกอีเวนต์ซึ่ง replica กำลัง apply อยู่ (replication lag)
  2. Replica Server Options and Variables MySQL
    replica_parallel_workers ให้หลายเธรด apply ทรานแซกชันแบบขนาน (ค่าเริ่มต้น 4, ถ้าเป็น 0 จะใช้เธรดเดียวไล่ตามลำดับ)
  3. Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
    streaming replication เป็นแบบ asynchronous ตามค่าเริ่มต้น จึงมีดีเลย์ระหว่าง commit กับการสะท้อนบน replica (ถ้า replica ตามทัน ปกติไม่ถึง 1 วินาที)
  4. MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
    ตั้งแต่ 8.0.22 ใช้ SHOW REPLICA STATUS แทน SHOW SLAVE STATUS เวอร์ชันก่อนหน้านั้นใช้ SHOW SLAVE STATUS
  5. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    write_lag, flush_lag และ replay_lag ใน pg_stat_replication: เวลาตั้งแต่เซิร์ฟเวอร์หลักเขียน WAL จนถึงตอนที่ replica แจ้งว่าเขียนแล้ว, flush ลงดิสก์แล้ว และ apply แล้ว
  6. Amazon CloudWatch metrics for Amazon RDS AWS
    ReplicaLag: เวลาที่ read replica ตามหลังต้นทาง (วินาที)

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L12 ฐานข้อมูล

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กดไม่ติด/โรลแบ็ค)

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง