MySQL使用备份和binlog进行数据恢复
本文主要描述了MySQL遭到攻击篡改数据,利用从库的备份和主库的Binlog进行不完全恢复。
本文主要描述了MySQL遭到攻击篡改数据,利用从库的备份和主库的Binlog进行不完全恢复。
今天是2014-09-26,开发大清早就说昨晚数据库遭到了攻击。数据库中某文章表的文章内容字段遭到篡改,全部改成了同一篇文章。
通过查看日制 发现 数据是在 2014-09-25 21:53:57 遭到篡改。
所有的内容全部被改成了如下:
我把文章贴出来,先谴责一下,很可能是某旅游社的人为了打广告 雇人干的。
二、解决方法这个库我们是每天凌晨备份,保留30天的备份。主库的Binlog保留时间为7天。
因此很容易想到的方法是将从库2014-09-25凌晨的备份拿出来恢复,然后通过主库的Binlog通过时间段来筛选出凌晨至2014-09-25 21:53:56的所有更改,之后的数据,经业务确认,可以舍弃掉。或者后面再通过其他方法慢慢将这部分数据找出来。但是当务之急,,是立马恢复数据库。
三、找备份及时间点在备份的从库上检查备份:
发现备份任务让注释了
查看备份文件:
备份只到20140923日,下午18:33分。
备份日志最后一段截取:
因为这些表是在从库备份的,而且表都是MyiSAM的表。查看备份脚本,是先Stop Slave之后,才开始备份,因此从备份脚本输出的日志中找到备份开始的时间是:
2014-09-23 18:19:12通过:
Drwxr-xr-x 2 root root 4096 Sep 23 18:33 20140923可看到结束时间是:2014-09-23 18:33:00
现在考虑到底是以备份开始的时间:2014-09-23 18:19:12 为Start-DateTime还是以2014-09-23 18:33:00 为Start-DateTime。
前面 提到备份脚本是从库进行备份的,是在2014-09-23 18:19:12开始的,在这个时刻备份开始,执行了Stop Slave;因此整个备份的状态反映的是从库2014-09-23 18:19:12 这个时间的状态。而且通过监控可以看到在这个时间点,从库的延迟为0,因此可以认为这个备份就是 主库在这个时间的备份。
NOTES:
(有人可能会因为从库上有Binlog,从库也会接受主库的Binlog之类的机制而造成混淆。这里要结合我们具体的备份方式和恢复方式来看,以选出正确的时间点。)
前面提到通过日志查到遭到篡改的时间为:2014-09-25 21:53:57,因此可以将2014-09-25 21:53:56作为Stop-DateTime
因此Binlog命令应该是这样:
四、具体的恢复操作清楚了这些,具体的操作就简单了:
1.从备份机拷贝备份: 2.恢复测试机 解压: 3.恢复测试机导入(测试恢复库中之前没有db_name这个库): 4.将主库的Binlog拷贝到恢复测试机:查看主库Binlog
我们需要的Binlog时间段为:2014-09-23 18:28:00 至 2014-09-25 21:53:56 因此只需要:
将这3个Binlog Copy过去:
5.使用MySQLBinlog 生成SQL脚本: 6.Binlog生成的SQL脚本导入:待20140923.db_name导入到恢复测试库之后,将MySQLBinlog生成的SQL脚本导入到数据库中:
7.导入完成后检查数据正确性:大致看一下数据的情况,然后可以通过时间字段来看一下情况:
时间差不多为 晚上20:27了
这个判断,作为DBA,查看部分数据,只能起到辅助作用,具体的需要 到底是否OK,需要业务开发的人来判断。
经过业务开发确认后,即可将该数据导出后,再导入到线上主库中。
8、将该库导出,并压缩:压缩:
scp 到主库 (复制的时候,请将网络因素考虑进去,确认不会占用过多带宽而影响其他线上业务)
9.恢复测试的数据导入到线上主库中:线上主库操作:
操作之前,最好让开发把应用业务那段先暂停,否则可能会影响导入。比如这个表示MyISAM的,应用那边如果不听有update进来,就会阻塞数据导入。
a、主库将原始被篡改的表改名:(不要上来就drop,先rename,后续确认没问题了再考虑drop,因为很多问题不是一瞬间就能全部反映上来的)
b、解压:
c、导入新表数据:
后面就需要开发来进一步验证数据是否 OK 了。 验证没问题后,再启动应用程序。
本文永久更新链接地址:

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











1. Binlog Binlog는 데이터베이스에서 수행되는 쓰기 작업(쿼리 제외) 정보를 기록하고 이를 바이너리 형식으로 디스크에 저장하는 데 사용됩니다. Binlog는 mysql의 논리적 로그이며 서버 계층에 의해 기록됩니다. 모든 스토리지 엔진을 사용하는 MySQL 데이터베이스는 binlog 로그를 기록합니다. 논리적 로그: 간단히 SQL 문으로 이해될 수 있습니다. 물리적 로그는 MySQL의 데이터가 데이터 페이지에 저장되고, 물리적 로그는 여기에 코드 조각을 삽입하여 입력을 추가하여 기록됩니다. 파일 크기가 지정된 값에 도달하면 max_binlog_size 매개변수를 통해 각 binlog 파일의 크기를 설정할 수 있습니다.

머리말 MySQL에는 6가지 유형의 로그 파일이 있습니다. 즉, 리두 로그(redolog), 롤백 로그(undolog), 바이너리 로그(binlog), 오류 로그(errorlog), 느린 쿼리 로그(slowquerylog), 일반 쿼리 로그(generallog) ), 릴레이 로그(relaylog). 1. 리돌로그란 무엇인가요? Redo Log 파일이라고도 알려진 Redolog는 트랜잭션 작업의 변경 사항을 기록하는 데 사용되며 트랜잭션 제출 여부에 관계없이 데이터 수정 후의 값을 기록합니다. Redolog 파일은 데이터베이스 정전, Inn 등 인스턴스 및 미디어 오류(mediafailure)가 발생하는 경우 유용할 수 있습니다.

MySQL 바이너리 로그(binlog)와 관련하여, 우리 모두는 바이너리 로그(binlog)가 특히 지점 간 재해 복구가 필요할 때 매우 중요하다는 것을 알고 있으므로 백업해야 합니다. 바이너리 로그(binlog) 백업의 경우 먼저 Flushlogs 방식을 기반으로 binlog를 전환한 후, 마운트된 NAS 스토리지 등 원격 서버나 로컬 서버의 다른 스토리지에 복사 및 압축할 수도 있습니다. binlog를 백업하려면 MySQL 바이너리 로그(binlog)의 로컬 백업 또는 원격 백업을 구현하세요. 마지막으로 MySQL 바이너리 로그(binlog

1. Binlog 로그 소개 Binlog는 Binarylog의 약자, 즉 바이너리 로그(Binary Log)입니다. Binlog에는 지속성, 마스터-슬레이브 복제 및 데이터 복구 중에 무작위 IO를 순차 IO로 변환하는 세 가지 주요 기능이 있습니다. 이 문서에서는 마스터-슬레이브 복제와 관련된 문제에 중점을 둡니다. Binlog 로그는 인덱스 파일과 여러 로그 파일로 구성됩니다. 각 로그 파일은 매직 넘버와 이벤트로 구성됩니다. 각 이벤트는 이벤트 헤더와 이벤트 본문의 두 부분으로 나눌 수 있습니다. 이벤트 헤더의 구조는 다음과 같습니다. 이벤트 본문의 구조는 고정 크기와 가변 크기의 두 부분으로 구성됩니다. Binlog 로그 형식에 대해서는 관심 있는 학생들이 더 깊이 이해할 수 있습니다.

1. 문제의 원인 성능 문제를 분석할 때 느린 쿼리와 binlog 느린 트랜잭션이 일반적으로 사용되는 방법입니다. 최근 느린 쿼리를 분석하던 중 느린 쿼리가 다수 포함되어 있는 것을 발견했는데, binlog 느린 트랜잭션을 분석할 때 매칭이 완료되지 못했습니다. 예를 들어, 이 기간 동안 커밋 문은 1,000개일 수 있지만 느린 트랜잭션은 100개만 있을 수 있습니다. 이는 너무 큰 차이인데 왜 이런 현상이 발생할까요? 2. 명시적으로 제출된(삽입) 트랜잭션의 경우 느린 트랜잭션에 대한 각각의 결정 방법은 일반적으로 다음과 같습니다. GTID_LOG_EVENT 및 XID_EVENT는 'COMMIT' 명령이 시작되는 시간입니다.

서문 개발 시 mysql의 binlog 로그 파일을 모니터링하여 데이터 테이블을 모니터링해야 하는데, mysql은 docker 컨테이너에 배포되므로 데이터 볼륨 문제도 해결해야 합니다. 1. 데이터를 통해 mysql 이미지를 엽니다. Volume dockerrun- p3307:3306--namemyMysql-v/usr/docker/mysql/data:/var/lib/mysql-eMYSQL_ROOT_PASSWORD=123456-dmysql:5.7.25 참고: 호스트 디렉터리에 미리 파일을 생성해야 합니다. mysql 데이터 세트를 저장하기 위해 여기서 만든 디렉토리는 /u입니다.

MySQLbinlog/redolog/undolog의 차이점은 무엇입니까? InnoDB의 잠금 메커니즘에 대해 이야기하려면 필연적으로 MySQL 로깅 시스템, binlog, redolog, undolog 등이 관련됩니다. 일부 친구가 요약한 이 세 가지 로그가 나쁘지 않은 것을 보고 신속하게 가져왔습니다. 파트너와 논의할 수 있습니다. 로그는 MySQL 데이터베이스의 중요한 부분으로, 데이터베이스 운영 중 다양한 상태 정보를 기록합니다. MySQL 로그에는 주로 오류 로그, 쿼리 로그, 느린 쿼리 로그, 트랜잭션 로그 및 바이너리 로그가 포함됩니다. 개발자로서 우리가 집중해야 할 것은 바이너리 로그(binlog)와 트랜잭션 로그(redolog 및 und 포함)입니다.

mysql의 binlog를 통해 데이터를 복원하려면 먼저 binlog를 활성화해야 합니다. mysqlbinlog가 데이터베이스를 복원하는 방법을 알아보려면 여기에서 테스트 환경을 설정하십시오. 원리는 비교적 간단합니다. Binlog는 변경된 데이터를 mysql에 저장합니다. 예를 들어, 데이터베이스를 만들고 일부 데이터를 쓰면 이러한 내용이 mysql의 binlog에 저장됩니다. 회복이 필요할 때는 시작 위치와 끝 위치라는 두 가지 위치를 찾으세요. 종료 위치의 절반은 데이터가 파기되거나 삭제되기 전의 위치입니다. mysql8에는 기본적으로 binlogmysql>showvariableslike'%l이 활성화되어 있습니다.
