MySQL의 슬레이브 데이터베이스 복구 기록

상태 설명 :
오늘 등록 MySQL 데이터베이스 슬레이브 노드 호스트 발견 저장소에 MySQL의 릴레이 - 빈 많은 수의 파일은 / var / lib 디렉토리 / mysql을, 최초 파일 생성 날짜, 심지어 2018 년, 나는 슬레이브 데이터베이스 로깅 작업에 동기화 완성 된 마스터를 기억 그들은 노예 라이브러리의 상태를 확인하고 다음과 같은 오류를 찾을 수 있도록 레코딩이 끝난 후이 파일은 (기본 설정은 내가 잘못, 삭제되지 않습니다) 삭제 :

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: *.*.*.*
                  Master_User: dbsync
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000095
          Read_Master_Log_Pos: 869242147
               Relay_Log_File: mysqld-relay-bin.000146
                Relay_Log_Pos: 871280529
        Relay_Master_Log_File: mysql-bin.000075
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: cdb,cdb_admin
          Replicate_Ignore_DB: mysql
           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: 871280384
              Relay_Log_Space: 19994786573
              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.
1 row in set (0.00 sec)

ERROR: 
No query specified

그 이유는
내가 mysql을-bin.000075을 포함하여 마스터 노드 이름이 MySQL의-bin.00007 형식의 파일을 삭제 따라서, 파일을 찾을 수 없습니다 슬레이브 라이브러리를 동기화 할 수 없습니다.

해결 방법 :

슬레이브 라이브러리에 재 할당 동기화 위치. (타당)
```
slave stop;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=869242147; //mysql master节点上mysql-bin.000095的已有位置
slave start;
```
슬레이브 노드 쇼 노예 상태가 여전히 오류, 특정 오류 내용이 아래로 복사되지 않습니다, 그냥 Slave_IO_Running 프로세스는 프로세스 실행을 Slave_SQL_Running, 실행되지 않는 1236에 errno를 기억, 아마 문제의 도서관에서 테이블을 설명한다.
여러 다른 동기화 위치를 지정하는 시도에서 (위치 오차, 마스터 mysql을 - 빈 - 000095 새로 작성 위치) 오류 남아있다.
그들은 테이블에 제안 된 용어를 설명했다, 그래서 사실, 테이블 레코드가, 문제가, 노예 재고는 1200 개 기록, +는 기록에 1900의 마스터 라이브러리에 대한했습니다. 이러한 데이터를 수동으로 입력하지 않는 한, 또는 다른 (나 삭제) 손실 된 로그 레코드 운영 데이터, 당신은 작업의 로그 최근 위치와 일치 수행 찾을 수 있기 때문입니다.
슬레이브 라이브러리를 다시 실행.
데이터가 너무 다르다, 나는 거기에 생각하기 때문에 데이터 만 테이블이 같은 문제 때문에 깨끗한 점, 라이브러리에서 다시 실행되지 않습니다.

주 1) 비율, 슬레이브 노드 데이터베이스 구성 정보의 일관성을 유지한다. (듀얼 마스터 모드를 설정하는 이유는, 사실 난 단지 하나 개의 인스턴스 마스터 노드 아에서 실행이, 몰라?)

2) 점검 흐름 상황 마스터에 (쇼 PROCESSLIST), 슬레이브 노드는, 액세스에는 비즈니스 트래픽이 재실행 슬레이브 라이브러리 없을 것을 보장합니다.

마스터 노드 3) 정지 슬레이브 처리. (이 나중에 중지, 내가 볼 수, 문제가있을 경우 모르는 일이 없었어요)

4) 데이터베이스에 기록 위치의 마스터 노드 백업 후 데이터베이스 :

mysql> show master status;
+------------------+-----------+-------------------------------+------------------+
| File             | Position  | Binlog_Do_DB                  | Binlog_Ignore_DB |
+------------------+-----------+-------------------------------+------------------+
| mysql-bin.000095 | 871760173 | cdb,cdb_admin | mysql            |
+------------------+-----------+-------------------------------+------------------+
1 row in set (0.01 sec)
 mysqldump -u root -p --databases cdb,cdb_admin > bak.master.sql

5) 안전 측 백업 슬레이브 노드 라이브러리 :
mysqldump -u root -p --databases cdb,cdb_admin > bak.slave.sql

6) 다시 실행 시작 : 복사를 슬레이브 노드에 마스터 데이터베이스 백업 파일을 백업 파일을 가져 오기
mysql -u root -p < bak.master.sql

7) 슬레이브 노드에서 마스터 로그 판독의 위치를 재 :

slave stop;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=871760173; //POS为刚才记录的master节点日志记录位置
slave start;

8) 슬레이브 노드의 노예 상태를 표시,이 시간 Slave_IO_Running, Slave_SQL_Running가 실행되어, 새로 고침 노예 상태, Read_Master_Log_Pos 값은 동기화를 시작 다시 증가하기 시작했다.

요약 :
청소 파일, 마스터의 MySQL의 - 빈 파일에주의, 슬레이브 노드 로그 읽기 및 쓰기 위치 아! , 위치가 마스터에 읽은 확인하고 오프 슬레이브 확인하기 전에 로그를 삭제 슬레이브 노드에서 마스터 로그를 지정하도록 강요 위치를 읽는 경우에도, 혼란은 삭제하지 마십시오, 또는 슬레이브 라이브러리를 동기화하지 않거나 실수를 건너, 슬레이브 데이터베이스의 데이터 손실을 배제하지 않습니다.

MySQL의 슬레이브 데이터베이스 복구 기록

추천