HAProxy ใช้เป็นจุดเข้าใช้งานที่คงที่ (stable entry point) และกระจาย connection ไปยัง backend ที่เหมาะสมได้ แต่ traffic ของฐานข้อมูลต้องระวังมากกว่า traffic เว็บทั่วไป เพราะบทบาทอ่าน/เขียน transaction และการ failover มีผลต่อความถูกต้องของข้อมูล ไม่ใช่แค่ประสิทธิภาพ

บทความนี้สำหรับ IT Manager และทีม infrastructure ที่กำลังพิจารณาวาง HAProxy หน้า database cluster หรือกำลังปรับจูนระบบที่ใช้อยู่ โดยเน้นสิ่งที่ควรตรวจก่อนแก้ค่า configuration

สรุปสั้น: ก่อนปรับจูน HAProxy สำหรับฐานข้อมูล ให้กำหนดก่อนว่า node ไหนรับงานแบบใดได้ ทำ health check ที่สะท้อนบทบาทของฐานข้อมูล เข้าใจพฤติกรรมของ connection วัดผลทั้งเส้นทางของ request และซ้อมกรณี backend ล้มและกลับมา ค่าที่ใช้ต้องอิงเวอร์ชัน HAProxy และสถาปัตยกรรมฐานข้อมูลของระบบนั้น ไม่ใช่คัดลอกจากระบบอื่น

HAProxy ช่วยอะไรกับฐานข้อมูลได้ และช่วยอะไรไม่ได้

HAProxy ช่วยให้แอปพลิเคชันเชื่อมต่อผ่านปลายทางเดียว และส่ง connection ไปยัง backend ที่ผ่านการตรวจสอบแล้ว แต่ proxy ไม่ได้ตัดสินใจเรื่อง replication หรือการ promote node ใหม่แทนฐานข้อมูล และแก้ปัญหา query ที่ไม่มีประสิทธิภาพหรือฐานข้อมูลที่ใช้ทรัพยากรจนเต็ม (saturated) ไม่ได้

ดังนั้นการออกแบบ routing ควรทำคู่กับสถาปัตยกรรมฐานข้อมูล เช่น แบบ primary/replica หรือแบบ cluster ที่ใช้อยู่ ไม่ควรมอง proxy เป็นเครื่องมือเพิ่มประสิทธิภาพแยกจากส่วนอื่น

จะรู้ได้อย่างไรว่า backend ตัวไหนพร้อมรับงาน

การที่เชื่อมต่อพอร์ตได้ยังไม่ได้ยืนยันว่า database node นั้นพร้อมให้บริการงานที่ต้องการ health check จึงควรสะท้อนบทบาทของฐานข้อมูลและการออกแบบ routing ไม่ใช่แค่เช็กว่า TCP port เปิดอยู่

ตัวอย่างสิ่งที่อาจต้องตรวจ ได้แก่ node นั้นเป็นตัวที่รับการเขียนได้หรืออยู่ในสถานะ read-only และ replica ตามข้อมูลทันพอสำหรับงานอ่านที่ส่งไปหรือไม่ วิธีตรวจที่เหมาะสมขึ้นกับระบบฐานข้อมูลและเวอร์ชันที่ใช้ ส่วนการตัดสินใจเรื่อง replication และ promotion ยังเป็นหน้าที่ของสถาปัตยกรรมฐานข้อมูล

หากออกแบบให้แยกเส้นทางอ่านและเขียน เช่น แยก frontend สำหรับงานเขียนไปยัง primary และงานอ่านไปยังกลุ่ม replica แอปพลิเคชันต้องรู้ว่าการอ่านใดยอมรับข้อมูลที่อาจยังไม่อัปเดตได้ และการอ่านใดต้องไปที่ primary

ควรตรวจพฤติกรรมของ connection เรื่องใดบ้าง

ทบทวน connection pool ฝั่งแอปพลิเคชัน ขีดจำกัดจำนวน connection ทั้งที่ proxy และที่ฐานข้อมูล ค่า timeout และพฤติกรรมของ session ที่เปิดค้างไว้นานเมื่อมีการเปลี่ยนแปลง ค่าเหล่านี้ต้องสอดคล้องกันทั้งเส้นทาง

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

ต้องวัดอะไรก่อนและหลังปรับจูน

วัดทั้งเส้นทางของ request ได้แก่ อัตราการเปิด connection, queueing, error, latency ของ backend และการใช้ทรัพยากรของทั้ง proxy และฐานข้อมูล แล้วเทียบกับพฤติกรรมที่แอปพลิเคชันเห็นจริง

บันทึก baseline ช่วงเวลา และลักษณะ workload ไว้ เพื่อให้การเปรียบเทียบหลังเปลี่ยนค่ามีความหมาย หากปัญหาอยู่ที่ query หรือฐานข้อมูลที่ใช้ทรัพยากรจนเต็ม การเปลี่ยนค่าใน proxy จะไม่แก้ต้นเหตุ สรุปเครื่องมือหา bottleneck ฝั่ง Linux ดูได้ที่ Linux Performance Tools สำหรับ Performance Tuning

ทดสอบกรณี backend ล้มและกลับมาอย่างไร

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

กำหนดเงื่อนไขการ rollback ไว้ก่อนเปลี่ยน routing บน production เพื่อให้ทีมรู้ว่าเมื่อใดต้องย้อนกลับ และย้อนกลับด้วยขั้นตอนใด

ใช้ค่า configuration จากระบบอื่นได้หรือไม่

ไม่ควร ตัวเลือกและค่าเริ่มต้นของ configuration ขึ้นกับเวอร์ชันของ HAProxy และการออกแบบฐานข้อมูล ค่า maxconn หรือ timeout ขนาดใหญ่ที่ยกมาจากระบบอื่นอาจไม่เหมาะกับขีดจำกัดของฐานข้อมูลหรือพฤติกรรมของแอปพลิเคชันในระบบของคุณ

ใช้ เอกสารทางการของ HAProxy ตรงกับ release ที่ติดตั้งอยู่ ส่วนการปรับค่า kernel network ของเครื่องที่รัน proxy ก็ควรทำเมื่อมีหลักฐานจากการวัดว่าจำเป็น และทดสอบก่อนใช้กับ production

ก่อนเปลี่ยนการตั้งค่า HAProxy สำหรับฐานข้อมูล ควรตรวจอะไรบ้าง (checklist)

  • ระบุว่า backend แต่ละกลุ่มรับงานอ่าน งานเขียน หรือทั้งสองแบบ
  • health check ตรวจบทบาทของฐานข้อมูล ไม่ใช่แค่พอร์ตที่เชื่อมต่อได้
  • ค่า connection pool, ขีดจำกัด connection และ timeout สอดคล้องกันตั้งแต่แอปพลิเคชันถึงฐานข้อมูล
  • ทราบว่ามีการ retry ที่ชั้นใดบ้าง และ retry คำสั่งเขียนอย่างไร
  • มี baseline ของ connection, queue, error, latency และทรัพยากร ก่อนเปลี่ยนค่า
  • ซ้อมกรณี backend ล้มและกลับมาแล้ว และกำหนดเงื่อนไข rollback ไว้
  • อ้างอิงเอกสารของ HAProxy เวอร์ชันที่ติดตั้งจริง

หากต้องการให้ทบทวน routing, monitoring และการดูแลระบบ ดู บริการ DevOps และดูแลระบบ Server องค์กร ทั้งนี้ความรับผิดชอบฝั่งแอปพลิเคชันและฝั่งฐานข้อมูลควรตกลงร่วมกันตั้งแต่ต้น อ่านเพิ่มเรื่องการดูแลประสิทธิภาพระบบต่อเนื่องได้ที่ การดูแลประสิทธิภาพระบบ

ปรึกษาการทบทวนระบบ HAProxy และฐานข้อมูล →

บทความโดย UNIXDEV Team · ปรับปรุง 23 ตุลาคม 2026

คำถามที่พบบ่อย

HAProxy ช่วยเพิ่มประสิทธิภาพฐานข้อมูลได้เองหรือไม่?

ไม่ได้โดยตรง HAProxy เป็นจุดเข้าใช้งานที่คงที่และกระจาย connection ไปยัง backend ที่เหมาะสม แต่แก้ query ที่ไม่มีประสิทธิภาพหรือฐานข้อมูลที่ใช้ทรัพยากรจนเต็มไม่ได้ และไม่ได้ตัดสินใจเรื่อง replication หรือ promotion แทนสถาปัตยกรรมฐานข้อมูล

health check แบบเช็กพอร์ตเพียงพอสำหรับฐานข้อมูลหรือไม่?

ไม่เพียงพอ การที่เชื่อมต่อพอร์ตได้ยังไม่ได้ยืนยันว่า node พร้อมให้บริการงานที่ต้องการ health check ควรสะท้อนบทบาทของฐานข้อมูล เช่น node รับการเขียนได้หรืออยู่ในสถานะ read-only และ replica ตามข้อมูลทันพอสำหรับงานอ่านหรือไม่

ให้ proxy retry คำสั่งฐานข้อมูลอัตโนมัติได้หรือไม่?

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

ควรวัดอะไรก่อนและหลังปรับจูน HAProxy?

วัดอัตราการเปิด connection, queueing, error, latency ของ backend และการใช้ทรัพยากรของทั้ง proxy และฐานข้อมูล เทียบกับพฤติกรรมที่แอปพลิเคชันเห็นจริง และบันทึก baseline ช่วงเวลา และลักษณะ workload ไว้เปรียบเทียบ

นำค่า maxconn หรือ timeout จากระบบอื่นมาใช้ได้หรือไม่?

ไม่ควร ตัวเลือกและค่าเริ่มต้นขึ้นกับเวอร์ชัน HAProxy และการออกแบบฐานข้อมูล ควรอ้างอิงเอกสารทางการของ HAProxy ตรงกับ release ที่ติดตั้ง และบันทึก baseline ก่อนเปลี่ยนค่าเพื่อเปรียบเทียบผล