莫慌，先搞條SQL到數(shù)據(jù)庫查一把

 

 

阿彌陀佛，祈禱只是查詢條件的問題。

問題又來了，公司運(yùn)維說科技運(yùn)維說拷貝不出來，文件太大了要拷貝1個(gè)小時(shí)（備份源文件 7G）

 

 

打工人今天注定是無法按時(shí)下班了

 

跟現(xiàn)場(chǎng)一頓溝通 tmd 發(fā)現(xiàn)竟然沒有壓縮，壓縮了一下，瞬間縮水了很多，終于拷貝出來了

 

你以為拷貝出來就沒問題了嘛？

 

最開始想簡(jiǎn)單了，想的就是把全量備份還原到本地，然后在本地把對(duì)應(yīng)業(yè)務(wù)丟失數(shù)據(jù)的表搞成腳本恢復(fù)到生產(chǎn)上就完事了

 

MD，但是一頓操作發(fā)現(xiàn)，7G的數(shù)據(jù)全量還原到本地也tmd太太太慢了。還原了1個(gè)小時(shí)才還原不到10%，這不是到明天早上都不一定能還原完

 

7G的文件，就別想用普通的編輯軟件打開了，肯定是不行的。

 

沒辦法，只能2條腿走路，先讓它慢慢還原著，然后再去找找看有沒有其他辦法可以從7G的這個(gè)文件里把需要的數(shù)據(jù)篩出來

 

一頓Google 、度娘加ChatGPT后發(fā)現(xiàn)通過 mysqldump -u root -p mydatabase > mydatabase_backup.sql 備份的文件，不管一個(gè)表有多少數(shù)據(jù)，備份文件中都只會(huì)生成了一條插入語句

 

再通過這個(gè)命令： cat testdb_all.sql |grep -E ‘INSERT INTO `personchangeinfo`’ > personchangeinfo1.sql 就可以從全量備份文件中找出并生成一個(gè)新文件

 

通過實(shí)測(cè)是可從 7G的文件里面找出具體的某張表的插入語句的，這樣就好辦了，不用還原整改備份，可以單表進(jìn)行還原，節(jié)省了一大把時(shí)間。（tmd 今晚應(yīng)該不用熬通宵了）

 

到了這一步至少可以先恢復(fù)到丟失數(shù)據(jù)當(dāng)天凌晨的數(shù)據(jù)了，凌晨之后的的數(shù)據(jù)好像無能為力了（不知道各位大神有沒有什么好辦法？），硬著頭皮給現(xiàn)場(chǎng)項(xiàng)目方打電話匯報(bào)結(jié)果。

 

一看時(shí)間已經(jīng)晚上11點(diǎn)了，MD天選的打工人。

 

binlog 有三種格式：

• • Statement（Statement-Based Replication,SBR）：每一條會(huì)修改數(shù)據(jù)的 SQL 都會(huì)記錄在 binlog 中。
  • Row（Row-Based Replication,RBR）：不記錄 SQL 語句上下文信息，僅保存哪條記錄被修改。
  • Mixed（Mixed-Based Replication,MBR）：Statement 和 Row 的混合體。 

Statement

Statement 模式只記錄執(zhí)行的 SQL，不需要記錄每一行數(shù)據(jù)的變化，因此極大的減少了 binlog 的日志量，避免了大量的 IO 操作，提升了系統(tǒng)的性能。（比如update user set name="張三" where id >1 and id <10000,假設(shè)被修改的數(shù)據(jù)有2000條，那么Row的日志量就是2000條，而Statement只是這條sql語句一條日志而已，所以Statement的日志量相對(duì)Row會(huì)少很多）

但是，正是由于 Statement 模式只記錄 SQL，而如果一些 SQL 中 包含了函數(shù)，那么可能會(huì)出現(xiàn)執(zhí)行結(jié)果不一致的情況。比如說 uuid() 函數(shù)，每次執(zhí)行的時(shí)候都會(huì)生成一個(gè)隨機(jī)字符串，在 master 中記錄了 uuid，當(dāng)同步到 slave 之后，再次執(zhí)行，就得到另外一個(gè)結(jié)果了。

所以使用 Statement 格式會(huì)出現(xiàn)一些數(shù)據(jù)一致性問題。

Row

從 MySQL5.1.5 版本開始，binlog 引入了 Row 格式，Row 格式不記錄 SQL 語句上下文相關(guān)信息，僅僅只需要記錄某一條記錄被修改成什么樣子了。

Row 格式的日志內(nèi)容會(huì)非常清楚地記錄下每一行數(shù)據(jù)修改的細(xì)節(jié)，這樣就不會(huì)出現(xiàn) Statement 中存在的那種數(shù)據(jù)無法被正常復(fù)制的情況。

不過 Row 格式也有一個(gè)很大的問題，那就是日志量太大了，特別是批量 update、整表 delete、alter 表等操作，由于要記錄每一行數(shù)據(jù)的變化，此時(shí)會(huì)產(chǎn)生大量的日志，大量的日志也會(huì)帶來 IO 性能問題。

Mixed

從 MySQL5.1.8 版開始，MySQL 又推出了 Mixed 格式，這種格式實(shí)際上就是 Statement 與 Row 的結(jié)合。

在 Mixed 模式下，系統(tǒng)會(huì)自動(dòng)判斷 該 用 Statement 還是 Row：一般的語句修改使用 Statement 格式保存 binlog；對(duì)于一些 Statement 無法準(zhǔn)確完成主從復(fù)制的操作，則采用 Row 格式保存 binlog。

Mixed 模式中，MySQL 會(huì)根據(jù)執(zhí)行的每一條具體的 SQL 語句來區(qū)別對(duì)待記錄的日志格式，也就是在 Statement 和 Row 之間選擇一種。