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

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

failover ของ DB Database failover

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

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

ระหว่างที่ DB หลักล่มและสลับไปใช้ DB สำรอง จะเขียนข้อมูลไม่ได้ และข้อมูลช่วงท้ายที่ยัง replicate ไม่ทันอาจหายไป

ทำไม DB หลักขัดข้อง DB สำรองจึงถูกยกขึ้นเป็นตัวหลัก (promote) → ผลคือ ระหว่างสลับ เขียนไม่ได้หลายวินาทีถึงไม่กี่นาที ถ้าเป็น asynchronous replication ข้อมูลที่ยังไม่ได้ replicate อาจหาย → บนหน้าจอ เซฟไม่สำเร็จทั้งหมดชั่วครู่, ไอเทมและค่าประสบการณ์ถูกโรลแบ็ค

อาการ
กดไม่ติด/โรลแบ็ค, ค้าง, หลุด, เข้าเกมไม่ได้/โหลดไม่จบ
ปัจจัย
การหยุดชะงัก, แพ็กเก็ตหาย
ใครเจอ
ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร
สุ่มเป็นครั้งคราว
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก อินฟรา DB (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม
ทำให้การเซฟลองใหม่ได้, ตั้งค่าให้ทิ้งการเชื่อมต่อที่ขาดอย่างรวดเร็วแล้วเชื่อมต่อใหม่ไปยังที่อยู่ใหม่ (connection pool, DNS cache), ตรวจการเชื่อมต่อใหม่ตอนซ้อม failover
งานฝั่งทีมอินฟรา
ใช้ synchronous หรือ semi-synchronous replication (แลกกับดีเลย์การเขียน), ซ้อม failover, มอนิเตอร์เวลา failover และ replication lag
ตัวเลขที่ควรรู้
การ failover อัตโนมัติของ managed DB ปกติใช้เวลาหลายสิบวินาทีถึง 2 นาที ถ้าเป็น asynchronous replication อาจเสียการเซฟล่าสุดไปเท่ากับ replication lag (ไม่ถึง 1 วินาทีถึงหลายวินาที)
บนกราฟ
การเชื่อมต่อหลุดพร้อมกัน · จำนวนการเชื่อมต่อ DB, จำนวนข้อผิดพลาดในการเขียน
จุดที่ต้องดู
วางบันทึก failover ฝั่ง DB (RDS คืออีเวนต์ RDS-EVENT-0013 เริ่ม failover และ RDS-EVENT-0049 failover เสร็จ ส่วน DB ที่ดูแลเองคือ log การ promote) กับจำนวนการเชื่อมต่อ DB และจำนวนข้อผิดพลาดในการเชื่อมต่อของเซิร์ฟเวอร์เกมไว้บนกราฟเดียวกัน ถ้าเป็น asynchronous replication ให้ดู replication lag ก่อนเกิดเหตุด้วย (RDS ReplicaLag, replay_lag ใน pg_stat_replication ของ PostgreSQL)
สัญญาณว่าใช่
เซฟไม่สำเร็จกระจุกอยู่ในช่วงหนึ่ง และช่วงนั้นอยู่ระหว่างเวลาเริ่มและเวลาเสร็จ failover ปริมาณที่ย้อนกลับใกล้เคียงกับ replication lag ก่อนเกิดเหตุ เซิร์ฟเวอร์เกมที่ยัง error ต่อหลัง failover เสร็จ คือยังใช้การเชื่อมต่อที่ต่อไว้กับที่อยู่เดิม
สัญญาณว่าไม่ใช่
การเชื่อมต่อขาดในช่วงที่ไม่มีบันทึก failover: น่าจะเป็นเครือข่ายหรือ DB โหลดเกิน
วิธีตรวจ
ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
กรณีจริง
Riot Games 2021: League of Legends EUW ขัดข้อง 5 ชั่วโมง: DB เสริมตัวเดียวทำให้ทั้งเซิร์ฟเวอร์หยุด

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

  1. Failing over a Multi-AZ DB instance for Amazon RDS AWS
    Multi-AZ failover ปกติใช้ 60–120 วินาที, หลัง failover ต้องเชื่อมต่อใหม่ และแนะนำให้ตั้ง TTL ของ DNS cache ใน JVM ไม่เกิน 60 วินาที
  2. High availability for Amazon Aurora AWS
    ระหว่างขัดข้อง การอ่านและเขียนล้มเหลว ปกติกลับมาภายใน 60 วินาที (ส่วนใหญ่ภายใน 30 วินาที)
  3. Semisynchronous Replication MySQL
    asynchronous replication ถ้า DB หลักล่ม ทรานแซกชันที่ commit แล้วอาจไม่มีบน replica, semi-synchronous ลดปัญหานี้ด้วยการรอให้ replica หนึ่งตัวยืนยันว่าได้รับแล้ว แต่ดีเลย์จะเพิ่มขึ้น
  4. Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
    log shipping เป็นแบบ asynchronous ถ้าเซิร์ฟเวอร์หลักล่ม ทรานแซกชันที่ยังส่งไม่ทันจะหาย, ดีเลย์ของ streaming replication ปกติไม่ถึง 1 วินาที
  5. Amazon RDS event categories and event messages AWS
    RDS-EVENT-0013: เริ่ม Multi-AZ failover, RDS-EVENT-0049: Multi-AZ failover เสร็จ
  6. Amazon CloudWatch metrics for Amazon RDS AWS
    ReplicaLag: เวลาที่ read replica ตามหลังต้นทาง (วินาที)
  7. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    replay_lag ใน pg_stat_replication: เวลาตั้งแต่เซิร์ฟเวอร์หลักเขียน WAL จนถึงตอนที่ replica แจ้งว่า apply แล้ว

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

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

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

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