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이 누락 되었습니까?

_{(현재로서는 마스터에서 슬레이브로 --master-data mysqldump를 다시 가져 와서 문제를 해결했지만 앞으로는 그렇게하지 않을 수 있습니다.)}

다음은 내 특정 문제에 대한 세부 정보입니다.

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 , "해결 방법"을 검색 하십시오. //mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

오류 : Last_SQL_Errno : 1594 Last_SQL_Error : 릴레이 로그 읽기 실패 : 릴레이 로그 이벤트 항목을 구문 분석 할 수 없습니다.

이 오류는 마스터 로그 파일이 손상되었거나 릴레이 로그 파일이 손상되었음을 나타냅니다.

• 모든 작업을 수행하기 전에 모든 데이터베이스, 로그, 이미지 서버를 백업하고 반복하고 여러 번 반복하며 자신의 위험 만 계속하십시오.

먼저 슬레이브에서 "show slave status \ 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 로그를 얻은 후 다시 슬레이브를 시작하십시오. 참고 MASTER_LOG_POS는 것을 Exec_Master_Log_Pos, 그리고 MASTER_LOG_FILE가있다 Relay_Master_Log_File( NOT 첫 번째 명령에서 모두 폐기 할 수 가져와 필요가 있었다 릴레이 로그 일치하는 첫 번째).

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 복제 수정]

슬레이브 (버전 5.XX)에서 MySQL 복제가 중지되었습니다. Slave_IO_Running은 Yes로 표시되었지만 Slave_SQL_Running은 No로 표시되었습니다. 간단한 중지 / 시작 슬레이브는 도움이되지 않아 추가 문제 분석이 필요했습니다. “mysqlbinlog”로 테스트하면 오류가 인쇄되어 현재 슬레이브의 릴레이 로그가 손상된 것 같습니다. 따라서 해결책은 현재 릴레이 binlog를 버리고 슬레이브를 마지막 마스터 binlog 위치로 지정하는 것입니다.

오류를 해결하려면 슬레이브의 현재 binlog 파일을 버리고 새 위치를 설정해야합니다. 새로운 바이너리 로그 위치를 설정하기 전에 그것을 기억하는 것이 중요 Relay_Master_Log_File 및 Exec_Master_Log_Pos 명령을 사용하여 손상된 슬레이브 서버에서 값을 SHOW 노예 상태 \ 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디렉토리.

1 년이 지났다는 것을 알고 있지만 여기에이 특정 문제가 발생했을 수 있습니다.

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가 발생합니다. 왜 그렇습니까?

MySQL 5.5에서 여전히 활성화 된 미해결 버그 ( http://bugs.mysql.com/bug.php?id=60847 )가 있습니다

버그는 mysql --single-transaction --flush-logs 사용과 관련이 있지만 관련 문제가 있습니다.

지난 주 MySQL 5.5에서 클라이언트에 대해 슬레이브로 실행되는 일부 EC2 서버의 단점을 보았습니다 .15

마스터에는 삽입되는 각 튜플이 SELECT 인 이상한 여러 행 확장 INSERT가있었습니다. 발생한 다음 자동 증분을 구성하는 릴레이 로그의 LAST_INSERT_ID가 사전에 다중 행 삽입으로 인해 슬레이브에서 이미 사용 중이었습니다.

릴레이 로그의 직렬화 된 INSERT는 다음과 같습니다.

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

열 목록에 숫자 기본 키가 포함되지 않았습니다. 1062 오류가 다시 발생하면 실패한 동일한 쿼리를 사용하고 수동으로 쿼리를 실행합니다. 1062 오류가 발생하지 않았습니다. 그런 다음 일반적인 스킵 슬레이브 명령을 실행했습니다.

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

그런 다음 복제가 중단되었습니다.

이 버그와 같은 상황은 실제로 피할 수 있기 때문에 마스터의 INSERT를 올바르게 직렬화하는 것이 좋습니다.

당신은 그것을 이미 올바르게 수행했습니다.

유일한 문제는 master.info 파일과 관련이 있습니다 (마스터의 mysql-bin.log의 위치 정보가 포함되어 있음).이 파일은 각 쿼리가 처리 된 후 디스크에 동기화되지 않기 때문입니다.

따라서 마스터 로그의 위치에 대한 정보가 오래되어 이미 처리 된 쿼리를 처리하고 있으며 건너 뛰어야합니다 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;.

불행히도 데이터베이스 UPDATE table SET counter=counter+1 WHERE id = 12345와 같은 쿼리를 사용하고 binlog_format=STATEMENT데이터베이스를 사용 하면 동기화되지 않을 수 있습니다.

변수 sync_master_info 를 설정하여 모든 이벤트 후에 master.info를 동기화하도록 MySQL 서버에 지시 할 수 있지만 성능에 큰 영향을 줄 수 있습니다.