ล็อกการถ่ายทอด MySQL เสียหายฉันจะแก้ไขได้อย่างไร พยายาม แต่ล้มเหลว

รีเลย์ MySQL v5.1.61 เสียหายเมื่อเครื่องปิดตัวลงกะทันหัน ฉันพยายามแก้ไข แต่มันใช้งานไม่ได้
- ฉันจะแก้ไขได้อย่างไร ฉันทำอะไรผิดหรือเปล่า?

เท่าที่ฉันได้อ่านล็อกรีเลย์ MySQL เสียหายได้อย่างง่ายดายแก้ไข:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

ที่ไหนRelay_Master_Log_FileและExec_Master_Log_Posมีการระบุไว้โดย:
mysql> show slave status;

อย่างไรก็ตามเมื่อฉันทำchange master status ...ฉันได้รับข้อผิดพลาดการละเมิดคีย์หลัก เป็นไปได้อย่างไร? ขั้นตอนข้างต้นไม่ถูกต้องหรือมี +1 บางส่วนหายไปหรือไม่

_{(สำหรับตอนนี้ฉันเพิ่งนำเข้า mysqldump -master-data อีกครั้งจากต้นแบบไปยังทาสและสิ่งนี้แก้ปัญหาได้อย่างไรก็ตามในอนาคตการทำเช่นนั้นอาจไม่เหมาะสม)}

ต่อไปนี้เป็นรายละเอียดเกี่ยวกับปัญหาเฉพาะของฉัน:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

และนี่คือสิ่งที่ฉันทำ:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

และนี่คือสิ่งที่เกิดขึ้นข้อผิดพลาด PK:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

ฉันคิดว่าฉันทำตามขั้นตอนที่แนะนำ (ดูลิงก์ด้านล่าง) ยังคงมีข้อผิดพลาด PK :-(? http://bugs.mysql.com/bug.php?id=26489ค้นหา "การแก้ไขปัญหา" http: //mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

ข้อผิดพลาด: Last_SQL_Errno: 1594 Last_SQL_Error: ล้มเหลวในการอ่านบันทึกการถ่ายทอด: ไม่สามารถแยกรายการบันทึกเหตุการณ์การถ่ายทอด

ข้อผิดพลาดนี้หมายความว่าไฟล์บันทึกต้นแบบเสียหายหรือไฟล์บันทึกการถ่ายทอดเสียหาย

• ก่อนที่จะทำการสำรองข้อมูลฐานข้อมูลบันทึกเซิร์ฟเวอร์ภาพทำซ้ำหลาย ๆ ครั้งและดำเนินการต่อด้วยความเสี่ยงของคุณเอง

เรียกใช้ครั้งแรก "แสดงสถานะทาส \ G" บนทาสและหมายเหตุ:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

ก่อนอื่นเราต้องตรวจสอบให้แน่ใจว่าไฟล์บันทึกหลักยังคงอยู่ให้ข้ามไปที่เซิร์ฟเวอร์หลักและค้นหา Relay_Master_Log_File (ตรวจสอบ / var / log / mysql) และเรียกใช้คำสั่งต่อไปนี้:

mysqlbinlog mysql-bin.000026

บันทึกจะปรากฏขึ้น แต่หวังว่าคุณจะไม่เห็นข้อความแสดงข้อผิดพลาดใด ๆ หากคุณเห็นข้อความแสดงข้อผิดพลาดบันทึกหลักจะเสียหายและคุณอาจต้องเปลี่ยนภาพใหม่

ถัดไปเรียกใช้คำสั่งเดียวกันบนบันทึกการส่งต่อสลาฟ (มักจะอยู่ใน / var / lib / mysql)

mysqlbinlog mysqld-relay-bin.000056

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

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

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

หากบันทึกการส่งต่อข้อผิดพลาดมีข้อผิดพลาดให้เรียกใช้คำสั่งต่อไปนี้เพื่อรีเซ็ตบันทึกการใช้งานระดับรองและบันทึกที่เสียหายเชื่อมต่อกับต้นแบบรับบันทึก ok และเริ่ม slaving อีกครั้ง โปรดทราบว่า MASTER_LOG_POS คือExec_Master_Log_Posและ MASTER_LOG_FILE เป็นRelay_Master_Log_File( ไม่ใช่อันแรกที่ตรงกับบันทึกการถ่ายทอดที่ได้รับมาและต้องถูกทิ้ง) ทั้งคู่จากคำสั่งแรก

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

[การแก้ไขการจำลองแบบ MySQL หลังจากบันทึกการถ่ายทอดของทาสเสียหาย]

การจำลองแบบ MySQL บน Slave (รุ่น 5.XX) หยุดทำงาน Slave_IO_Running ถูกทำเครื่องหมายเป็นใช่ แต่ Slave_SQL_Running เป็นไม่ทาสสต็อป / หยุดแบบธรรมดาไม่ได้ช่วยแก้ไขปัญหาเพิ่มเติมได้ ดูเหมือนว่าบันทึกการถ่ายทอดของทาสในปัจจุบันเสียหายเนื่องจากการทดสอบด้วย“ mysqlbinlog” ได้พิมพ์ข้อผิดพลาดออกมา ดังนั้นทางออกคือการละทิ้ง binlogs รีเลย์ปัจจุบันและชี้ slave ไปที่ตำแหน่ง binlog หลักสุดท้าย

ในการแก้ไขข้อผิดพลาดไฟล์ binlog ปัจจุบันบนสลาฟควรถูกทิ้งและกำหนดตำแหน่งใหม่ ก่อนที่จะตั้งตำแหน่งใหม่ binlog มันเป็นสิ่งสำคัญที่ต้องจำไว้Relay_Master_Log_FileและExec_Master_Log_Posค่าจากเซิร์ฟเวอร์ทาสเสียหายโดยใช้คำสั่งแสดงสถานะ SLAVE \ G :

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

ตกลงด้วยค่านี้ตำแหน่ง binlog ใหม่สามารถตั้งค่าได้:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

เพียงเพื่อให้ทราบว่าreset slaveจะลบmaster.info, relay-log.infoและทุกไฟล์บันทึกการถ่ายทอดดังนั้นจึงไม่จำเป็นที่จะเหลือที่สะอาดใน/var/lib/mysqlไดเรกทอรี

ฉันรู้ว่ามันใช้เวลานานกว่าหนึ่งปี แต่นี่คือสิ่งที่อาจเกิดขึ้นกับปัญหานี้โดยเฉพาะ

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

ดูเหมือนว่าควรได้รับการแก้ไขเพราะลบบันทึกการถ่ายทอดที่เสียหาย

จากนั้นคุณได้รับข้อผิดพลาด PK 1062 เพราะเหตุใด

มีข้อผิดพลาดที่โดดเด่น ( http://bugs.mysql.com/bug.php?id=60847 ) ที่ยังคงทำงานอยู่ใน MySQL 5.5

แม้ว่าข้อผิดพลาดที่เกี่ยวข้องกับการใช้ mysql - รายการเดียว - ล้าง - บันทึกการเล่นโวหารที่เกี่ยวข้องอยู่

ฉันได้เห็นว่าการเล่นโวหารในเซิร์ฟเวอร์ EC2 บางเครื่องทำงานเป็น Slaves สำหรับลูกค้าเมื่อสัปดาห์ที่แล้วใน MySQL 5.5.15

ใน Master มีการเพิ่ม INSERT แปลก ๆ หลายแถวโดยแทรก tuple แต่ละอันเป็น SELECT สิ่งที่เกิดขึ้นก็คือ LAST_INSERT_ID ในบันทึกการถ่ายทอดซึ่งเป็นแบบฟอร์มการเพิ่มอัตโนมัติถัดไปที่จะมอบหมายนั้นถูกใช้งานบน Slave อยู่แล้วเนื่องจากมีการแทรกหลายแถวไว้ล่วงหน้า

INSERT ต่อเนื่องในบันทึกการถ่ายทอดดูเหมือนว่า

INSERT INTO tablname (column,column) VALUES (value,value,...)

รายการคอลัมน์ไม่มีคีย์หลักที่เป็นตัวเลข เมื่อข้อผิดพลาด 1,062 กลับมาฉันจะใช้แบบสอบถามเดียวกันกับที่ล้มเหลวรันแบบสอบถามด้วยตนเอง ไม่พบข้อผิดพลาด 1,062 จากนั้นฉันก็รันคำสั่งข้ามทาสตามปกติ:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

จากนั้นการจำลองแบบจม

คำแนะนำของฉันคือการเรียงลำดับ INSERT ของคุณบน Master อย่างถูกต้องเนื่องจากสถานการณ์ที่คล้ายกับข้อผิดพลาดนี้สามารถหลีกเลี่ยงได้

คุณทำมันถูกต้องแล้ว (อย่างที่อื่นพูดไปแล้ว)

ปัญหาเดียวคือไฟล์ master.info (มีข้อมูลเกี่ยวกับตำแหน่งใน mysql-bin.log ของต้นแบบ) เนื่องจากไฟล์นี้ไม่ได้ซิงค์กับดิสก์หลังจากประมวลผลแบบสอบถามแต่ละรายการ

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;ดังนั้นข้อมูลของคุณเกี่ยวกับตำแหน่งในบันทึกของโทล้าสมัยและคุณกำลังประมวลผลคำสั่งประมวลผลแล้วที่จะต้องข้ามกับ

น่าเสียดายที่ถ้าคุณใช้แบบสอบถามบางอย่างเช่นUPDATE table SET counter=counter+1 WHERE id = 12345และการใช้binlog_format=STATEMENTฐานข้อมูลของคุณอาจไม่ตรงกันฉันคิดว่า

คุณสามารถบอกเซิร์ฟเวอร์ MySQL ให้ซิงค์ master.info ได้หลังจากทุกเหตุการณ์โดยการตั้งค่าตัวแปรsync_master_infoแต่มันอาจจะส่งผลต่อประสิทธิภาพอย่างมาก