실수로 삭제 된 데이터를 복구 할 MySQL의 데이터 테이블에 앞서

데모 환경 설명 :

X_86 (코어) 1511년 2월 7일 시스템에 CentOS 리눅스는 출시 64 의 최소에 장착
MySQL의 바이너리 버전은 공식 버전 5.7.22-22이다, MySQL은 타이머 event_scheduler를 시작하는 바이너리 설치를 열고 두 개의 인스턴스가 하나의 MySQL을, MySQL의 인스턴스를 사용하여 = ON있다. 또한 실시 예 2가 턴온되는 MySQL의 gtid의
xtrabackup는 rpm 패키지 버전 버전 2.4.13 사용

하루에 전체 백업 및 증분 백업 바이너리 로그 한번 MySQL의 백업 모드

둘째, 시뮬레이션 라이브러리, 데이터 복구 데모를 삭제 :

팁 : 입증하기 위해 여기에 물론, 비 라이브러리 생성 환경, 삭제, 테이블 시뮬레이션을 삭제, 당신은 결과를 알고

시뮬레이션 고장 :
온라인 TESTDB의 test1_event 실수로 잘못 테이블 test1_event의 삭제 이전 데이터에 데이터를 복원하기 위해 MySQL의 바이너리 로그 파일을 오늘의 MySQL의 + 일의 전체 백업을 생산 된 사용하여 라이브러리에서 테이블을 삭제
복원 설명 :
공식 사용을 권장 이 방법은 공식되었습니다 입증 된 MySQL의 바이너리 로그 복원, 생산 (권장 공식 다음의 방법)의 엄격한 방법이 아닙니다

다음과 같이 복구 프로세스는 다음과 같습니다
2.1 실수로, 이전에 삭제 수신 아마 처음이 오용 시간을 확인
시점의 현재 중앙 도서관 바이너리 로그 위치를 볼 수있는 2.2 로그인 정보를 (다시 복원 할 때 사용되는이 시간 바이너리 로그 파일에 기억)

(root@'mgr01':mysql3306.sock)[testdb]>show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000005
         Position: 15211
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: bde7b592-b966-11e9-8c64-000c294f3e61:1-10445
1 row in set (0.00 sec)

2.3 다음으로 좋은 플러시 로그, 새로운 기록 다음의 SQL 바이너리 로그 파일을 만들 것입니다
2.4 포인트 하락 테이블 문을 대상으로 위치를 어디에 binglog 파일 :

[root@mgr01 binlog]#  mysqlbinlog -v --base64-output=decode-rows   /data/mysql/mysql3306/binlog/mysql-bin.000005|grep -i -C 15 drop
###   @1=10422
###   @2='tomcat'
###   @3='xiaohuahua'
###   @4='2019-08-08 14:22:18'
# at 14987
#190808 14:22:18 server id 63306  end_log_pos 15018 CRC32 0x873943dd    Xid = 20695
COMMIT/*!*/;
#at15018###################################
#190808 14:22:19 server id 63306  end_log_pos 15083 CRC32 0xcc8773ce    GTID    last_committed=34   sequence_number=35  rbr_only=no
SET @@SESSION.GTID_NEXT= 'bde7b592-b966-11e9-8c64-000c294f3e61:10445'/*!*/;
#at 15083
#190808 14:22:19 server id 63306  end_log_pos 15211 CRC32 0x8d445019    Query   thread_id=7213  exec_time=0 error_code=0
use `testdb`/*!*/;
SET TIMESTAMP=1565245339/*!*/;
SET @@session.sql_auto_is_null=0/*!*/;
DROP TABLE `test1_event` /* generated by server */
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
#End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

점의 위치를 ​​찾을 수는 15,018 바이너리 로그 파일 복구의 종점을 사용하는

2.5 xtrabackup 백업 mysql3308 예를 복원하려면 다음
팁을 다음 Gtid를 엽니 다 MySQL의 3308 인스턴스를

백업 명령을 복원

innobackupex --apply-log /data/backup/db_3306_20190808/
innobackupex  --defaults-file=/data/mysql/mysql3308/my3308.cnf --copy-back /data/backup/db_3306_20190808/

데이터 디렉토리 데이터 MySQL의 권한 :

 chown -R mysql.mysql /data/mysql/mysql3308/data/

mysql3308 예를 시작합니다

/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3308/my3308.cnf   &

보기는 3308 개 인스턴스 데이터로 돌아갑니다 만, 다시 드롭 테이블 test1_event에서 못해서이 기간이 아직도 데이터베이스 (3306)에 다시 누락 된 데이터를 많이, 뒷면의 증가에서 바이너리 로그 파일 :

| 10273 | tomcat   | xiaohuahua | 2019-08-08 14:17:16 |
| 10274 | tomcat   | xiaohuahua | 2019-08-08 14:17:18 |
+-------+----------+------------+---------------------+

(root@'mgr01':mysql3308.sock)[testdb]>select count(*) from test1_event;
+----------+
| count(*) |
+----------+
|    10273 |
+----------+
1 row in set (0.00 sec)

xtrabackup 백업 Gtid에, 그래서 매개 변수는 복구-gtids의 --skip하지 않는 경우, mysqlbinlog은 명령 증가 binglog 파일을 사용 Gtid 정보 바이너리 로그 파일을 무시 매개 변수 --skip-gtids을 추가, 데이터를 복원 할 때 다음과 같은 그리고, 데이터 복구 미만 3308 라이브러리에서 얻어진

올바른 복구 명령은 다음과 같습니다 :

mysqlbinlog    /data/mysql/mysql3306/binlog/mysql-bin.000001 --skip-gtids  |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog    /data/mysql/mysql3306/binlog/mysql-bin.000002 --skip-gtids  |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog    /data/mysql/mysql3306/binlog/mysql-bin.000003 --skip-gtids  |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog    /data/mysql/mysql3306/binlog/mysql-bin.000004 --skip-gtids  |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog    /data/mysql/mysql3306/binlog/mysql-bin.000005 --stop-position="15018"  --skip-gtids  |mysql -f --binary-mode  -S /tmp/mysql3308.sock 

매개 변수 :
--skip-gtids 파일 바이너리 로그 Gtid 정보를 무시
주로 중국어 왜곡 또는 특수한 캐릭터 왜곡의 문제를 해결하기 위해 --binary 모드를
오류를 무시하고 -f 강제 재생을

위의 명령을 실행 한 후에, 데이터는 test1_event 전에 테이블을 삭제 복원 할 수

데이터가 복구 될 수있는 다음 명령은 3308에서 MySQL 인스턴스를 복원 할 수 :( my3308 예 Gtid 파라미터 열린 야기하기 때문에)

mysqlbinlog   /data/mysql/mysql3306/binlog/mysql-bin.000001 |mysql -f --binary-mode  -S /tmp/mysql3308.sock  
mysqlbinlog   /data/mysql/mysql3306/binlog/mysql-bin.000002 |mysql -f --binary-mode  -S /tmp/mysql3308.sock  
mysqlbinlog   /data/mysql/mysql3306/binlog/mysql-bin.000003 |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog   /data/mysql/mysql3306/binlog/mysql-bin.000004 |mysql -f --binary-mode  -S /tmp/mysql3308.sock 
mysqlbinlog --stop-position="15018"  /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode  -S /tmp/mysql3308.sock 

시작하기 전에 새로운 인스턴스 mysql3308가 my3308.cnf의 Gtid 매개 변수에서 폐쇄하는 경우 2.6 :
3.
이 경우 사용 mysqlbinlog은 /data/mysql/mysql3306/binlog/mysql-bin.00000* | mysql을 -f --binary 모드 -S /tmp/mysql3308.sock는 3308 MySQL의 인스턴스에 데이터를 복원하지만, 오류 복구 중에 있습니다. 3308 데이터에 이러한 반환은,
생성 된 파일 정보 Gtid를 바이너리 로그 기록되지 않습니다

[root@mgr01 backup]# mysqlbinlog --stop-position="15018"  /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode  -S /tmp/mysql3308.sock 
ERROR 1781 (HY000) at line 17: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 50: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 74: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 98: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.

물론, 이하의 방법을 복원하는데 사용될 수있다 binglog 동일한 문서 3308 Gtid 기록 정보의 일례없고,이 방법은 복구 프로세스에서 오류가 발생할 수있는 완전성 및 데이터의 정확성 때문에 생산을 보장 할 수 없다 최고의 데이터 복구를 검색하기 위해이 방법을 사용하지

[root@mgr01 backup]# mysqlbinlog --skip-gtids  /data/mysql/mysql3306/binlog/mysql-bin.000001|mysql -f --binary-mode  -S /tmp/mysql3308.sock
ERROR 1050 (42S01) at line 27: Table 'test1_event' already exists
ERROR 1062 (23000) at line 92: Duplicate entry '1' for key 'PRIMARY'
ERROR 1537 (HY000) at line 132: Event 'e_test' already exists
mysqlbinlog --skip-gtids  /data/mysql/mysql3306/binlog/mysql-bin.000002|mysql -f --binary-mode  -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids  /data/mysql/mysql3306/binlog/mysql-bin.000003|mysql -f --binary-mode  -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids  /data/mysql/mysql3306/binlog/mysql-bin.000004|mysql -f --binary-mode  -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids --stop-position="15018" /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode  -S /tmp/mysql3308.sock

팁 : 생산 그래서 데이터 및 데이터베이스 동기화를 복원뿐만 아니라 동기화 오류가 매우 편리 해결 최선 개방 Gtid.

요약 :

드롭 데이터베이스와 같은 DDL 문은이 문 잘라 내기 테이블에서 mysqlbinlog를 사용하여 복원 할 수 있습니다, 테이블을 드롭 테이블을 놓습니다. 뿐만 아니라 도구로 사용되는 binlog2sql 플래시백

같은 binglog 형식 행 형식 여부 문, 또는 문장 형식, 또는 혼합 형식의 경우, 바이너리 로그 형식은 행의 형식 문에 기록 된
사용 mysqlbinlog로는 데이터베이스 수준의 추출을 지원

특정 시점 복구에 모든 장비 + 사용 mysqlbinlog은
에서 mysqlbinlog를 사용하여이 --skip-gtids 큰 위험 지점이