ฉันใช้ MySQL-5.1.50 ด้วยการตั้งค่าการจำลองแบบ Master-slave

ส่วนใหญ่เวลาที่ทาสล้าหลังนาย

เมื่อฉันเรียกใช้show processlist;ไม่มีการสืบค้นที่ใช้เวลานาน ฉันเปิดใช้งานslow_logเช่นกัน อย่างไรก็ตามไม่พบการสืบค้นที่ทำงานช้า

Slave จะส่งการแจ้งเตือนอย่างต่อเนื่องว่าการเรพลิเคทเป็นวินาทีหลังต้นแบบ บางครั้งเวลาล่าช้าจะเพิ่มขึ้น

ฉันจะวินิจฉัยสาเหตุของปัญหาได้อย่างไร

ฉันต้องการความช่วยเหลือเร่งด่วนเนื่องจากปัญหานี้ยังคงมีอยู่ในช่วง 20 วันที่ผ่านมา

Seconds_Behind_Master เป็นเหมือนการดูอดีตผ่านการเดินทางข้ามเวลา

ลองวิธีนี้ดู:

• ดวงอาทิตย์อยู่ห่างจากโลก 93,000,000 ไมล์
• ความเร็วของแสงคือ 186,000 ไมล์ / วินาที
• การแบ่งอย่างง่ายแสดงให้เห็นว่าใช้เวลาประมาณ 500 วินาที (8 นาที 20 วินาที) เพื่อให้แสงจากดวงอาทิตย์ไปถึงโลก
• เมื่อคุณมองดูดวงอาทิตย์คุณจะไม่เห็นดวงอาทิตย์จริงๆ คุณเห็นว่ามันอยู่ที่ไหน 8 นาที 20 วินาทีก่อน

ในทำนองเดียวกันดูเหมือนว่าอาจารย์กำลังประมวลผลข้อความค้นหาจำนวนมากในเวลาเดียวกัน

คุณมองกลับไปที่ทาสวิ่งSHOW SLAVE STATUS\Gและกล่าวว่า Seconds_Behind_Master200 ตัวเลขนั้นคำนวณอย่างไร? เวลานาฬิกาของ Slave (UNIX_TIMESTAMP (NOW ())) TIMESTAMP ของ Query เมื่อสร้างเสร็จแล้วและบันทึกลงใน Binary Log ของ Master

มีตัวชี้วัดอื่นให้ดูนอกเหนือจากSeconds_Behind_Masterนี้ Relay_Log_Spaceตัวชี้วัดที่เรียกว่า นั่นหมายถึงผลรวมของไบต์ทั้งหมดสำหรับไฟล์รีเลย์ทั้งหมดใน Slave โดยค่าเริ่มต้นบันทึกการถ่ายทอดเดียวที่ใหญ่ที่สุดจะถูก จำกัด ที่ 1GB หากRelay_Log_Spaceน้อยกว่า 1GB แสดงว่ามีการสืบค้นที่ใช้เวลานานจำนวนมากดำเนินการบน Master พร้อมกัน น่าเสียดายเนื่องจากเธรด SQL ของการเรพลิเคตแบบเธรดเดียวมีการดำเนินการคิวรีหนึ่ง

ตัวอย่างเช่นสมมติว่าคุณมีสถานการณ์จำลองต่อไปนี้ใน Master:

• เปิดใช้งานบันทึกข้อความค้นหาช้า
• 20 แบบสอบถามดำเนินการในแบบคู่ขนานบนปริญญาโท
• แต่ละแบบสอบถามใช้เวลา 3 วินาที
• แบบสอบถามแต่ละรายการจะได้รับการบันทึกใน Master Binary Log ด้วยเวลาประทับเดียวกัน

เมื่อ Slave อ่านข้อความค้นหาเหล่านั้นจากบันทึกการถ่ายทอดของมันและประมวลผลพวกเขาทีละคน

• นาฬิกาของ Slave จะเคลื่อนไหว
• TIMESTAMP สำหรับแต่ละแบบสอบถาม 20 รายการจะเหมือนกัน
• ความแตกต่างจะเพิ่มขึ้น 3 วินาทีจะแล้วเสร็จแบบสอบถาม
• ผลลัพธ์นี้ใน 60 วินาทีสำหรับ Seconds_Behind_Master

สำหรับ Log ช้านี้ค่าเริ่มต้นสำหรับlong_query_timeคือ 10 วินาที หากการสอบถามของคุณทั้งหมดในบันทึกการถ่ายทอดมีค่าน้อยกว่า 10 วินาทีคุณจะไม่พบสิ่งใดในบันทึกการสืบค้นที่ช้า

ฉันมีคำแนะนำต่อไปนี้สำหรับเซิร์ฟเวอร์ Master และ Slave

• คำแนะนำ # 1 : อัพเกรดเป็น 5.5 ภายใต้ MySQL 5.5 และ Percona Server 5.1.38+ คุณสามารถปรับแต่ง InnoDB เพื่อเข้าถึง CPU หลายตัว ฉันได้เขียนโพสต์ที่ผ่านมาเกี่ยวกับเรื่องนี้
  • Apr 26, 2012: ประสิทธิภาพของ CPU เกี่ยวข้องกับเซิร์ฟเวอร์ฐานข้อมูลหรือไม่
  • Sep 20, 2011: หลายคอร์และประสิทธิภาพ MySQL
  • Sep 12, 2011: เป็นไปได้ไหมที่ทำให้ MySQL ใช้มากกว่าหนึ่งคอร์?
  • May 26, 2011: เกี่ยวกับประสิทธิภาพของฐานข้อมูลแบบเธรดเดี่ยวและแบบมัลติเธรด
• คำแนะนำ # 2 : ใช้ InnoDB สำหรับตารางทั้งหมด InnoDB เก็บข้อมูลและดัชนีใน RAM, MyISAM จะทำดัชนีแคชเท่านั้น
• คำแนะนำ # 3 : การเพิ่มแรม คุณต้องแคชข้อมูลและดัชนีมากขึ้นใน Slave และ Master
• RECOMMENDATION # 4 : ปรับแต่งคำค้นหาทั้งหมด การลดมิลลิวินาทีจากข้อความค้นหาที่เรียกใช้หลายร้อยครั้งเป็นวิธีที่ลดลงSeconds_Behind_Masterได้นาน

การแก้ไขปัญหาต่อไปอื่น ๆ

ถ้าคุณต้องการดูคิวรีที่ก่อให้เกิดความล่าช้าในการทำซ้ำให้ทำดังต่อไปนี้:

• SHOW SLAVE STATUS\G
• รับชื่อบันทึกการถ่ายทอดจาก Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• ในระบบปฏิบัติการcd /var/lib/mysqlหรือที่ใดก็ตามที่มีการบันทึกล็อกรีเลย์
• ดัมพ์บันทึกการส่งต่อไปยังไฟล์ข้อความ

ตัวอย่างเช่นมาทำกัน SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1024035856
              Relay_Log_Space: 794732271
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451149

ถ้าฉันเรียกใช้STOP SLAVE; START SLAVE;ล็อกรีเลย์จะปิดและเปิดใหม่ relay-bin.000030แต่คุณต้องการ

ทิ้งเนื้อหาดังต่อไปนี้:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

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

คุณใช้รูปแบบแฟ้มบันทึกไบนารีอะไร คุณกำลังใช้ ROW หรือคำชี้แจง?
"SHOW GLOBAL VARIABLES LIKE 'binlog_format'; "

หากคุณใช้ ROW เป็นรูปแบบ binlog ตรวจสอบให้แน่ใจว่าตารางทั้งหมดของคุณมีคีย์หลักหรือคีย์เฉพาะ:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

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

ค่า seconds_behind_master ใน SHOW SLAVE STATUS คือความแตกต่างระหว่างเวลาของระบบบนต้นแบบซึ่งถูกเก็บไว้เมื่อเหตุการณ์ถูกเรียกใช้และบันทึกในไบนารีล็อก ... และเวลาระบบบนสลาฟเมื่อเหตุการณ์ถูกเรียกใช้ที่นั่น

วินาทีที่อยู่เบื้องหลังต้นแบบจะให้ค่าที่ไม่ถูกต้องหากนาฬิกาทั้งสองระบบไม่ได้ซิงค์กัน