มันไม่ฉลาดที่จะเรียกใช้การจำลองแบบบนเซิร์ฟเวอร์จริงหรือไม่?

ฉันใคร่ครวญการตั้งค่าการจำลองแบบ Master-Slave สำหรับฐานข้อมูลของฉัน เซิร์ฟเวอร์ทาสจะใช้สำหรับความซ้ำซ้อนและอาจเป็นเซิร์ฟเวอร์รายงาน อย่างไรก็ตามหนึ่งในปัญหาที่ใหญ่ที่สุดที่ฉันพบคือเราได้ใช้พลังงานอย่างเต็มประสิทธิภาพที่ดาต้าเซ็นเตอร์แล้ว ดังนั้นการเพิ่มเซิร์ฟเวอร์ทางกายภาพอื่นไม่ใช่ตัวเลือก

เซิร์ฟเวอร์ฐานข้อมูลที่มีอยู่ของเรานั้นมีการใช้งานไม่เพียงพอเท่าที่ cpu (ค่าเฉลี่ยการโหลดไม่เคยสูงกว่า 1 ใน quad-core) ดังนั้นแนวคิดที่สำคัญคือการโยนในไดรฟ์ใหม่และเพิ่มหน่วยความจำเป็นสองเท่า (จาก 8GB ถึง 16) และเรียกใช้อินสแตนซ์ mysql ที่สองบนเครื่องทางกายภาพเดียวกัน แต่ละอินสแตนซ์จะมีดิสก์แยกต่างหากสำหรับฐานข้อมูล

มีอะไรผิดปกติกับความคิดนี้หรือไม่?

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

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

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

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

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

แก้ไข: ตามที่ DTest ระบุไว้ในความคิดเห็นของเขาด้านล่างประโยชน์อื่น ๆ ที่เป็นไปได้อีกประการหนึ่งของ DB DB (แม้ว่าจะอยู่บนไดรฟ์เดียวกันกับมาสเตอร์) คือข้อความค้นหาที่ซับซ้อนที่ใช้เวลานานในทาสซึ่งอาจทำให้เกิดปัญหาการล็อค คำสั่งที่ทำงานกลางวันในต้นแบบนั้นปลอดภัยกว่า แม้ว่าคุณจะยังดีกว่าการมีทาสในไดรฟ์ที่แตกต่างกันเช่นการค้นหาที่สำคัญเช่นนั้นอาจทำให้เกิดปัญหาการขัดแย้งของ IO

ยังไม่ชัดเจนสำหรับฉันว่าวิธีนี้ช่วยแก้ปัญหาของคุณได้อย่างไร ไม่มีความซ้ำซ้อนเนื่องจากมันอยู่บนฮาร์ดแวร์ทางกายภาพเดียวกันเคอร์เนลระบบปฏิบัติการเดียวกันไบนารีของ MySQL ที่เหมือนกันอาจเป็นดิสก์ที่แตกต่างกัน แต่อยู่ในคอนโทรลเลอร์หน่วยเก็บข้อมูลเดียวกัน ฯลฯ และเหตุผลสำหรับการรายงาน DB คือเพื่อลดการสืบค้นจาก OLTP DB และ ทุกอย่างอยู่ในชุดเดียวกันพลังพิเศษมาจากไหน? หรือมีอย่างอื่นที่คุณพยายามรับจากการตั้งค่านี้หรือไม่?

หนึ่งใช้ไปได้สำหรับเรื่องนี้จะเป็นกับผู้ใช้งานแยกอย่างใดบางที GRANTแต่อีกครั้งผมจะมีความคิดที่จะได้รับการดำเนินการกับ

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

(โพสต์เป็นคำตอบไม่ใช่ความคิดเห็นเพื่อเน้นเธรดการสนทนาไว้)

นี่อาจเป็นดาบสองคม

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

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

ฉันจะข้ามการจำลองแบบบนเซิร์ฟเวอร์ที่แตกต่างกันเช่นทาสของ A ในทาสของ B และ B ใน A. เราทำงานหลายครั้งบนเซิร์ฟเวอร์ของเราและไม่มีปัญหาเพราะเซิร์ฟเวอร์ MySQL ของเราไม่ได้มีความจุ การล้มเหลวไปยังเซิร์ฟเวอร์ที่ทำงานอยู่นั้นเร็วกว่าการกู้คืนจากข้อมูลสำรอง