เราสามารถทำอะไรใน MySQL 5.0 Replication เพื่อจัดการกับปัญหาแบนด์วิดท์?

ฉันกำลังพัฒนาแอพพลิเคชั่นให้ทำงานบนไคลเอนต์พีซี (Win) ซึ่งได้รับการกำหนดค่าด้วยอินสแตนซ์ของเซิร์ฟเวอร์ MySQL 5.1 ที่จะทำหน้าที่เป็นสลาฟแบบอ่านอย่างเดียวไปยังต้นแบบระยะไกล ต้นแบบระยะไกลมีสกีมาหลายสิบ แต่ฉันต้องการเพียงหนึ่งต่อไคลเอนต์ดังนั้นฉันให้การตั้งค่าการจำลองแบบ - do-dbใน my.ini เพื่อทำซ้ำสคีมาที่ลูกค้าต้องการเท่านั้น การจำลองแบบใช้งานได้ แต่เมื่อลูกค้าของเราเข้าสู่ภูมิภาคต่างๆของโลกที่มีการเข้าถึงอินเทอร์เน็ตผ่านเครือข่ายไร้สาย 3G เท่านั้นซึ่งเรียกเก็บตามการใช้ข้อมูลลูกค้าจะเกินขีด จำกัด แผนข้อมูลของพวกเขาอย่างรวดเร็วและประสบปัญหาราคาแพง

ดังที่ฉันเข้าใจแล้ว MySQL จะเขียนธุรกรรมทั้งหมดสำหรับสกีมาทั้งหมดลงในไฟล์ binlog ไฟล์เดียวซึ่งหมายความว่าไคลเอนต์แต่ละคนจะต้องดาวน์โหลดธุรกรรมทั้งหมดที่ดำเนินการกับทุกสกีมาบนมาสเตอร์แล้วดาวน์โหลดเมื่อใช้ตัวกรองฐานข้อมูลต่อการจำลองแบบการตั้งค่าdo-dbในไฟล์ my.ini ของลูกค้า

เพื่อลดความไร้ประสิทธิภาพนี้ฉันได้ใช้การตั้งค่าslave_compressed_protocol = 1ซึ่งดูเหมือนว่าจะลดข้อมูลที่ส่งลง 50% แต่ก็ยังทำให้ลูกค้าของเราเกินขีด จำกัด ข้อมูลที่รวดเร็วขึ้นในบิล 3G

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

จนถึงตอนนี้นี่เป็นความคิดของฉันในการแก้ปัญหาที่เป็นไปได้โปรดให้ข้อเสนอแนะหรือเส้นทางอื่น:

1. ตั้งค่าทาส "พร็อกซี" สำหรับแต่ละสคีมา (ในกล่องอื่นหรือกล่องเดียวกันกับอินสแตนซ์ / พอร์ต MySQL อื่น)
2. กำหนดค่าพร็อกซี slave เพื่อทำซ้ำ-do-db เฉพาะฐานข้อมูลเดียวที่ไคลเอนต์ต้องการทำซ้ำ
3. กำหนดค่าอินสแตนซ์ MySQL ของลูกค้าเป็นทาสให้กับพร็อกซีทาสที่เหมาะสม

สิ่งนี้จะส่งผลให้ลูกค้าดึงข้อมูล binlog สำหรับสคีมาของพวกเขาเท่านั้น ข้อเสีย (เท่าที่ฉันสามารถบอกได้) ก็คือมันเพิ่มความซับซ้อนของการตั้งค่าของเราได้อย่างมาก

คิด? วิธีการนี้จะใช้งานได้หรือไม่

หมายเหตุเรากำลังเรียกใช้เซิร์ฟเวอร์ MySQL 5.0 บน RedHat แต่เราสามารถอัพเกรดเป็น 5.5 ได้ถ้ามันเป็นทางออก

คำแนะนำ # 1: ใช้ผู้เชี่ยวชาญการกระจาย

โทจัดจำหน่ายเป็นทาส MySQL ด้วยการเข้าสู่ระบบถังเปิดใช้งานเข้าสู่ระบบทาสการปรับปรุงเปิดใช้งานและมีตารางเฉพาะกับBLACKHOLE เก็บโปรแกรม คุณสามารถนำ replicate-do-db ไปใช้กับ Distribution Master และสร้างไบนารีล็อกที่ Distribution Master ที่มีเฉพาะสกีมา DB ที่คุณต้องการ binlogged ด้วยวิธีนี้คุณจะลดขนาดของ binlogs ขาออกจาก Distribution Master

คุณสามารถตั้งค่าการกระจายหลักดังนี้:

1. mysqldump ฐานข้อมูลของคุณโดยใช้ตัวเลือก - no-data เพื่อสร้างดัมพ์สกีมาเท่านั้น
2. โหลดดัมพ์สกีมาเท่านั้นไปยัง Distribution Master
3. แปลงทุกตารางใน Distribution Master เป็นเอนจิ้นการจัดเก็บ BLACKHOLE
4. เซ็ตอัพการจำลองแบบการแจกจ่ายหลักจากต้นแบบที่มีข้อมูลจริง
5. เพิ่มตัวเลือก replicate-do-db ให้กับ /etc/my.cnf ของ Distribution Master

สำหรับขั้นตอนที่ 2 และ 3 คุณสามารถแก้ไขดัมพ์สกีมาเท่านั้นและแทนที่ ENGINE = MyISAM และ ENGINE = InnoDB ด้วย ENGINE = BLACKHOLE จากนั้นโหลดดัมพ์สกีมาที่แก้ไขเท่านั้นลงใน Distribution Master

ในขั้นตอนที่ 3 เท่านั้นถ้าคุณต้องการสคริปต์การแปลงของตาราง MyISAM และ InnoDB ทั้งหมดเป็น BLACKHOLE ใน Distribution Master ให้เรียกใช้แบบสอบถามต่อไปนี้และส่งออกไปยังไฟล์ข้อความ:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

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

ตราบใดที่คุณไม่ส่ง DDL ใด ๆ ไปยัง Distribution Master คุณสามารถส่ง DML ใด ๆ (INSERT, UPDATE, DELETE) ที่คุณต้องการก่อนที่จะให้ลูกค้าทำซ้ำข้อมูล DB ที่พวกเขาต้องการ

ฉันแล้วโพสต์ในเว็บไซต์ StackExchange อื่นที่กล่าวถึงในการใช้โทการจัดจำหน่าย

คำแนะนำ # 2: ใช้บันทึกไบนารีขนาดเล็กและบันทึกการถ่ายทอด

หากคุณตั้งค่าmax_binlog_sizeเป็นสิ่งเล็ก ๆ ขันขันถังขยะจะถูกรวบรวมและส่งออกเป็นชิ้นเล็ก ๆ นอกจากนี้ยังมีตัวเลือกที่แยกต่างหากเพื่อกำหนดขนาดของการบันทึกถ่ายทอดmax_relay_log_size ถ้า max_relay_log_size = 0 มันจะเริ่มต้นสิ่งที่ max_binlog_size ตั้งเป็น

คำแนะนำ # 3: ใช้การจำลองแบบแบบซิงโครนัส (MySQL 5.5 เท่านั้น)

ตั้งค่าฐานข้อมูลหลักของคุณและผู้เชี่ยวชาญการกระจายสินค้าหลายคนเป็น MySQL 5.5 เปิดใช้งานการจำลองแบบ Semisynchronous เพื่อให้ฐานข้อมูลหลักสามารถจัดส่ง binlogs ไปยัง Distribution Master ได้อย่างรวดเร็ว หากทาสของคุณทั้งหมดเป็นผู้เชี่ยวชาญการแจกจ่ายคุณอาจไม่จำเป็นต้องใช้การจำลองแบบกึ่งข้อมูลหรือ MySQL 5.5 หากทาสคนใดก็ตามที่นอกเหนือจาก Distribution Masters มีข้อมูลจริงสำหรับการรายงานความพร้อมใช้งานสูงสแตนบายแบบพาสซีฟหรือจุดประสงค์ในการสำรองข้อมูลให้ไปกับ MySQL 5.5 ร่วมกับ Semisynchronous Replication

คำแนะนำ # 4: ใช้การบันทึกตามคำสั่งไบนารีไม่อิงแถว

หากคำสั่ง SQL อัปเดตหลายแถวในตารางการบันทึกแบบไบนารีตามคำสั่ง (SBBL) จะเก็บเฉพาะคำสั่ง SQL คำสั่ง SQL ที่เหมือนกันโดยใช้การบันทึกไบนารีแถวบน (RBBL) จะบันทึกการเปลี่ยนแปลงแถวจริงสำหรับแต่ละแถว สิ่งนี้ทำให้เห็นได้ชัดว่าการส่งคำสั่ง SQL จะประหยัดพื้นที่ในการบันทึกแบบไบนารีที่ทำ SBBL ผ่าน RBBL

ปัญหาอีกประการหนึ่งคือการใช้ RBBL ร่วมกับ replicate-do-db โดยที่ชื่อตารางมีฐานข้อมูลต่อท้าย สิ่งนี้ไม่ดีสำหรับทาสโดยเฉพาะอย่างยิ่งสำหรับอาจารย์การแจกจ่าย ดังนั้นตรวจสอบให้แน่ใจว่า DML ทั้งหมดไม่มีฐานข้อมูล aa และจุดต่อหน้าชื่อตารางใด ๆ

max_binlog_size ไม่ควรเกี่ยวข้อง - ข้อมูล binlog จะถูกสตรีมอย่างต่อเนื่อง

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

SBR กับ RBR - ขึ้นอยู่กับแบบสอบถาม อาจจะดีกว่าหรือแย่กว่าอีก

วาง Masters การกระจายในเครื่องเดียวกับ Master จริงหรือบนเครื่อง "ใกล้" Master ใช้พอร์ตแยกเพื่อแยกอินสแตนซ์