ฉันควรใช้วิธีการมิเรอร์ MySQL แบบใด


2

ฉันใช้บริการโฮสต์เว็บแอปพลิเคชัน (โดยทั่วไปจะโฮสต์ฟอรัมฟรี) และฉันมีเซิร์ฟเวอร์ระยะไกลสองตัวที่ให้บริการ รหัสสำหรับแอปพลิเคชันถูกเก็บไว้บนเซิร์ฟเวอร์ทั้งสองและไม่ใช่ปัญหา แต่ฉันสงสัยว่าจะจัดการกับฐานข้อมูลได้อย่างไร

เมื่อมีคนเข้าสู่ไซต์ * .example-host.com พวกเขาจะถูกส่งไปยังหนึ่งในสองเซิร์ฟเวอร์และทั้งสองจะต้องสามารถโหลดฟอรัมจากฐานข้อมูล ฐานข้อมูลจะต้องมีการเข้าถึงเพื่อเขียนสำหรับเมื่อสมาชิกใหม่ลงทะเบียนหรือโพสต์หัวข้อ ฯลฯ

ข้อกำหนดหลักคือความเร็ว แต่สถานะการออนไลน์ก็มีความสำคัญเช่นกัน (หากเซิร์ฟเวอร์หมดไซต์ควรทำงานต่อไป)

ฉันมีตัวเลือกน้อย แต่ฉันไม่มีประสบการณ์และไม่แน่ใจว่าจะไปกับ:

1) [PHP]แบ่งฟอรัมบันทึก 50:50 ระหว่างสองเซิร์ฟเวอร์ หากเซิร์ฟเวอร์ไม่มีเร็กคอร์ดสำหรับฟอรัมที่ร้องขอก็สามารถร้องขอได้จากอีกอันหนึ่งโดย MySQL ระยะไกลและโหลด แนวคิดนี้ฟังดูโอเคจนกระทั่งฉันรู้ว่า 50% ของเวลาผู้ใช้จะต้องรออีกต่อไปเพื่อให้โหลดหน้าเว็บ ฉันยังตระหนักว่าหากเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งล่มฟอรัมครึ่งหนึ่งจะไม่สามารถเข้าถึงได้และการลงทะเบียนจะต้องถูกปิดใช้งาน

2) [MySQL]การจำลองแบบต้นแบบคู่ สิ่งนี้จะพยายามสะท้อนสองฐานข้อมูลและฟังดูสมบูรณ์แบบ แต่ฉันได้ยินมาว่าอาจเป็นปัญหาได้ ฉันไม่รู้ว่านี่เร็วแค่ไหน

3) [MySQL]ใช้การจำลองแบบมาตรฐานแจกจ่ายแบบสอบถามแบบอ่านอย่างเดียวบนทั้งสองโหนดและแบบสอบถามแบบอ่าน / เขียนไปยังต้นแบบ ฟังดูเหมือนตัวเลือกที่ดี แต่ฉันไม่แน่ใจเรื่องความเร็วอีก ฉันก็ไม่รู้เหมือนกันว่าจะเกิดอะไรขึ้นถ้าเซิร์ฟเวอร์หลักล่ม

หากคุณมีข้อเสนอแนะอื่น ๆ โปรดโพสต์พวกเขา :)

คำตอบ:


3

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

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

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

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

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

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

ฉันกำลังวางหลักเกณฑ์ทั่วไปตาม LAMP stack และมุ่งเน้นไปที่เว็บแอปพลิเคชัน แอปพลิเคชั่นโปรโตคอลและเทคโนโลยีที่แตกต่างกันมีการเปลี่ยนแปลงเล็กน้อย แต่ในส่วนที่เกี่ยวกับเว็บเซิร์ฟเวอร์และฐานข้อมูลสิ่งที่ฉันอธิบายนั้นใช้โดยทั่วไปได้มากกว่า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.