실수로 mysql 데이터베이스를 삭제한 후 데이터 복구 작업에 대한 샘플 코드 공유
- 黄舟원래의
- 2017-03-27 13:15:291363검색
다음 편집기에서는 실수로 삭제된 mysql 데이터베이스의 데이터 복구 작업 지침에 대한 기사를 제공합니다. 에디터가 꽤 좋다고 생각해서 지금 공유해서 참고용으로 올려보겠습니다. 에디터를 따라가며 살펴볼까요
일상적인 운영과 유지관리 작업에 있어 mysql 데이터베이스의 백업은 매우 중요합니다! 웹사이트에서 데이터베이스의 중요성은 우리가 mysql 데이터 관리에 실패할 수 없도록 만듭니다!
그러면 사람들은 필연적으로 실수를 하게 될 것입니다. 어쩌면 어느 날 뇌가 단락되어 데이터베이스를 삭제하는 실수를 하게 될 수도 있습니다. ? ?
다음은 실수로 mysql 데이터베이스를 삭제한 후의 복구 계획에 대한 설명입니다.
1. 작업 시나리오
(1) MySQL 데이터베이스는 12시에 자동으로 완전 백업됩니다. 매일 밤 00 .
(2) 어느 날 아침 직장에서 9시쯤, 동료가 기절해 데이터베이스를 떨어뜨렸습니다!
(3) 긴급 복구가 필요합니다! 백업 데이터 파일과 증분 binlog 파일을 데이터 복구에 사용할 수 있습니다.
2. 데이터 복구 아이디어
(1) 전체 SQL 파일에 기록된 데이터를 활용 CHANGE MASTER 문, binlog 파일 및 해당 위치 지점 정보는 binlog 파일에서 증분 부분을 찾습니다.
(2) mysqlbinlog 명령을 사용하여 위의 binlog 파일을 sql 파일로 내보내고 drop 문을 제거합니다.
(3) 전체 파일의 SQL 파일과 증분 binlog 파일을 내보내어 전체 데이터를 복원할 수 있습니다.
3. 예시
------------ - ------------
먼저 mysql에 binlog 기능이 활성화되어 있는지 확인하세요. [ mysqld]를 /etc/my.cnf 파일에서 차단합니다:
log-bin=mysql-bin
그런 다음 mysql 서비스를 다시 시작합니다
--------------- - ------------
(1) ops 라이브러리 테이블을 만듭니다. >
mysql> use ops; mysql> create table customers( -> id int not null auto_increment, -> name char(20) not null, -> age int not null, -> primary key(id) -> )engine=InnoDB; Query OK, 0 rows affected (0.09 sec) mysql> show tables; +---------------+ | Tables_in_ops | +---------------+ | customers | +---------------+ 1 row in set (0.00 sec) mysql> desc customers; +-------+----------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+----------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | char(20) | NO | | NULL | | | age | int(11) | NO | | NULL | | +-------+----------+------+-----+---------+----------------+ 3 rows in set (0.02 sec) mysql> insert into customers values(1,"wangbo","24"); Query OK, 1 row affected (0.06 sec) mysql> insert into customers values(2,"guohui","22"); Query OK, 1 row affected (0.06 sec) mysql> insert into customers values(3,"zhangheng","27"); Query OK, 1 row affected (0.09 sec) mysql> select * from customers; +----+-----------+-----+ | id | name | age | +----+-----------+-----+ | 1 | wangbo | 24 | | 2 | guohui | 22 | | 3 | zhangheng | 27 | +----+-----------+-----+ 3 rows in set (0.00 sec)(2) 이제 전체 백업을 수행합니다.
[root@vm-002 ~]# mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/opt/backup/ops_$(date +%F).sql.gz Enter password: [root@vm-002 ~]# ls /opt/backup/ops_2016-09-25.sql.gz -----------------
매개변수 설명:
-B: 데이터베이스 지정
-R: 백업
저장 프로시저
등-x: 테이블 잠금--master-data: 추가 CHANGE MASTER 문, binlog 파일 및 위치 정보를 백업 문
----
데이터 삽입mysql> insert into customers values(4,"liupeng","21");
Query OK, 1 row affected (0.06 sec)
mysql> insert into customers values(5,"xiaoda","31");
Query OK, 1 row affected (0.07 sec)
mysql> insert into customers values(6,"fuaiai","26");
Query OK, 1 row affected (0.06 sec)
mysql> select * from customers;
+----+-----------+-----+
| id | name | age |
+----+-----------+-----+
| 1 | wangbo | 24 |
| 2 | guohui | 22 |
| 3 | zhangheng | 27 |
| 4 | liupeng | 21 |
| 5 | xiaoda | 31 |
| 6 | fuaiai | 26 |
+----+-----------+-----+
6 rows in set (0.00 sec)
(5)
mysql> drop database ops;
Query OK, 1 row affected (0.04 sec)
binlog 파일 위치입니다. mysql-bin.000002의 라인 106인 준비 시간 에 있으므로 이 파일 이전의 binlog 파일에 있는 데이터는 이미 포함되어 있습니다. 이 완전한 SQL 파일은 에 포함되어 있습니다( 6) binlog 파일을 이동하여 sql 파일로 내보낸 후 drop 문을 제거하세요
[root@vm-002 ~]# cd /opt/backup/ [root@vm-002 backup]# ls ops_2016-09-25.sql.gz [root@vm-002 backup]# gzip -d ops_2016-09-25.sql.gz [root@vm-002 backup]# ls ops_2016-09-25.sql [root@vm-002 backup]# grep CHANGE ops_2016-09-25.sql -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=106;
binlog 파일을 sql 파일로 내보낸 후 vim으로 편집하여 drop 문을 삭제합니다.
[root@vm-002 backup]# ps -ef|grep mysql root 9272 1 0 01:43 pts/1 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql mysql 9377 9272 0 01:43 pts/1 00:00:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock [root@vm-002 backup]# cd /var/lib/mysql/ [root@vm-002 mysql]# ls ibdata1 ib_logfile0 ib_logfile1 mysql mysql-bin.000001 mysql-bin.000002 mysql-bin.index mysql.sock test [root@vm-002 mysql]# cp mysql-bin.000002 /opt/backup/
참고:
전체 데이터를 복원하기 전에 binlog 파일을 이동해야 합니다. 그렇지 않으면 복구 프로세스가 계속해서 binlog에 명령문을 작성하여 결국 증분 복구 데이터 부분이 헷갈리게 됩니다
(7) 복구 데이터
[root@vm-002 backup]# mysqlbinlog -d ops mysql-bin.000002 >002bin.sql
[root@vm-002 backup]# ls
002bin.sql mysql-bin.000002 ops_2016-09-25.sql
[root@vm-002 backup]# vim 002bin.sql #删除里面的drop语句
ops 라이브러리가 있는지 데이터베이스를 확인하세요
[root@vm-002 backup]# mysql -uroot -p < ops_2016-09-25.sql Enter password: [root@vm-002 backup]#
이때 전체 백업 시점의 데이터가 복원됩니다
그 후 002bin.sql 파일을 이용하여 데이터베이스를 삭제하기 전 시점으로 전체 백업 시점을 복원합니다. , 새로 추가된 데이터
mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | ops | | test | +--------------------+ 4 rows in set (0.00 sec) mysql> use ops; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select * from customers; +----+-----------+-----+ | id | name | age | +----+-----------+-----+ | 1 | wangbo | 0 | | 2 | guohui | 0 | | 3 | zhangheng | 0 | +----+-----------+-----+ 3 rows in set (0.00 sec)
가 데이터베이스를 다시 확인해 보니 전체 백업과 데이터베이스 삭제 사이의 데이터 일부도 복원된 것을 발견했습니다! !
[root@vm-002 backup]# mysql -uroot -p ops <002bin.sql Enter password: [root@vm-002 backup]#
위는 mysql 데이터베이스의 증분 데이터 복구 과정 예시입니다!
마지막으로 몇 가지 요약 사항:
1) 본 사례는 마스터-슬레이브 복제 및 다운타임이 없는 인위적인 SQL문이나 Hot Standby 상황으로 인한 오작동 복구에 적용됩니다 2) 복구 조건은 mysql이 binlog 로그 기능을 활성화해야 하며 모든 데이터가 완벽하게 준비되고 증분되어야 한다는 것입니다 3) 복구 중에는 외부 업데이트를 중지하는 것이 좋습니다. 즉, 데이터베이스 업데이트는 금지되어 있습니다 4) 먼저 전체 볼륨을 복원한 후, 전체 백업 시간 이후의 증분 로그를 순서대로 SQL 파일로 복원한 후, 문제가 있는 SQL 문을 삭제합니다. 파일(시간 및 위치 지점을 사용할 수도 있음)을 선택한 다음 데이터베이스로 복원합니다.
위 내용은 실수로 mysql 데이터베이스를 삭제한 후 데이터 복구 작업에 대한 샘플 코드 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!