本篇內(nèi)容介紹了“數(shù)據(jù)庫遷移的方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元棲霞做網(wǎng)站,已為上家服務(wù),為棲霞各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

如何部署

停機(jī)部署法

大致思路就是，掛一個(gè)公告，半夜停機(jī)升級(jí)，然后半夜把服務(wù)停了，跑數(shù)據(jù)遷移程序，進(jìn)行數(shù)據(jù)遷移。
步驟如下:
(1)出一個(gè)公告，比如“今晚00:00～6:00進(jìn)行停機(jī)維護(hù)，暫停服務(wù)”
(2)寫一個(gè)遷移程序，讀db-old數(shù)據(jù)庫，通過中間件寫入新庫db-new1和db-new2，具體如下圖所示

(3)校驗(yàn)遷移前后一致性，沒問題就切該部分業(yè)務(wù)到新庫。

順便科普一下，這個(gè)中間件?，F(xiàn)在流行的分庫分表的中間件有兩種，一種是proxy形式的，例如mycat，是需要額外部署一臺(tái)服務(wù)器的。還有一種是client形式的，例如當(dāng)當(dāng)出的Sharding-JDBC，就是一個(gè)jar包，使用起來十分輕便。我個(gè)人偏向Sharding-JDBC，這種方式，無需額外部署，無其他依賴，DBA也無需改變?cè)械倪\(yùn)維方式。

評(píng)價(jià)：
大家不要覺得這種方法low，我其實(shí)一直覺得這種方法可靠性很強(qiáng)。而且我相信各位讀者所在的公司一定不是什么很牛逼的互聯(lián)網(wǎng)公司，如果你們的產(chǎn)品凌晨1點(diǎn)的用戶活躍數(shù)還有超過1000的，你們握個(gè)爪！畢竟不是所有人都在什么電商公司的，大部分產(chǎn)品半夜都沒啥流量。所以此方案，并非沒有可取之處。
但是此方案有一個(gè)缺點(diǎn)，累！不止身體累，心也累！你想想看，本來定六點(diǎn)結(jié)束，你五點(diǎn)把數(shù)據(jù)庫遷移好，但是不知怎么滴，程序切新庫就是有點(diǎn)問題。于是，眼瞅著天就要亮了，趕緊把數(shù)據(jù)庫切回老庫。第二個(gè)晚上繼續(xù)這么干，簡(jiǎn)直是身心俱疲。

ps：這里教大家一些技巧啊，如果你真的沒做過分庫分表，又想吹一波，漲一下工資，建議答這個(gè)方案。因?yàn)檫@個(gè)方案比較low，low到?jīng)]什么東西可以深挖的，所以答這個(gè)方案，比較靠譜。
另外，如果面試官的問題是

你們?cè)趺催M(jìn)行分庫分表的？

這個(gè)問題問的很泛，所以回答這個(gè)問題建議自己主動(dòng)把分表的策略，以及如何部署的方法講出來。因?yàn)檫@么答，顯得嚴(yán)謹(jǐn)一些。
不過，很多面試官為了賣弄自己的技術(shù)，喜歡這么問

分表有哪些策略啊？你們用哪種啊？

ok。。這個(gè)問題具體指向了分庫分表的某個(gè)方向了，你不要主動(dòng)答如何進(jìn)行部署的。等面試官問你，你再答。如果面試官?zèng)]問，在面試最后一個(gè)環(huán)節(jié)，面試官會(huì)讓你問讓幾個(gè)問題。你就問

你剛才剛好有提到分庫分表的相關(guān)問題，我們當(dāng)時(shí)部署的時(shí)候，先停機(jī)。然后半夜遷移數(shù)據(jù)，然后第二天將流量切到新庫，這種方案太累，不知道貴公司有沒有什么更好的方案？

那么這種情況下，面試官會(huì)有兩種回答。第一種，面試官硬著頭皮隨便扯。第二種，面試官真的做過，據(jù)實(shí)回答。記住，面試官怎么回答的不重要。重點(diǎn)的是，你這個(gè)問題出去，會(huì)給面試官一種錯(cuò)覺:"這個(gè)小伙子真的做過分庫分表。"

如果你擔(dān)心進(jìn)去了，真派你去做分庫分表怎么辦？OK，不要怕。我賭你試用期碰不到這個(gè)活。因?yàn)槟苓M(jìn)行分庫分表，必定對(duì)業(yè)務(wù)非常熟。還在試用期的你，必定對(duì)業(yè)務(wù)不熟，如果領(lǐng)導(dǎo)給你這種活，我只能說他有一顆大心臟。

ok，指點(diǎn)到這里。面試本來就是一場(chǎng)斗智斗勇的過程，扯遠(yuǎn)了，回到我們的主題。

雙寫部署法(一)

這個(gè)就是不停機(jī)部署法，這里我需要先引進(jìn)兩個(gè)概念:歷史數(shù)據(jù)和增量數(shù)據(jù)。
假設(shè)，我們是對(duì)一張叫做test_tb的表進(jìn)行拆分，因?yàn)槟阋M(jìn)行雙寫，系統(tǒng)里頭和test_tb表有關(guān)的業(yè)務(wù)之前必定會(huì)加入一段雙寫代碼，同時(shí)往老庫和新庫中寫，然后進(jìn)行部署，那么
歷史數(shù)據(jù):在該次部署前，數(shù)據(jù)庫表test_tb的有關(guān)數(shù)據(jù)，我們稱之為歷史數(shù)據(jù)。
增量數(shù)據(jù):在該次部署后，數(shù)據(jù)庫表test_tb的新產(chǎn)生的數(shù)據(jù)，我們稱之為增量數(shù)據(jù)。
然后遷移流程如下
(1)先計(jì)算你要遷移的那張表的max(主鍵)。在遷移過程中，只遷移db-old中test_tb表里，主鍵小等于該max(主鍵)的值，也就是所謂的歷史數(shù)據(jù)。這里有特殊情況，如果你的表用的是uuid，沒法求出max(主鍵)，那就以創(chuàng)建時(shí)間作為劃分歷史數(shù)據(jù)和增量數(shù)據(jù)的依據(jù)。如果你的表用的是uuid,又沒有創(chuàng)建時(shí)間這個(gè)字段，我相信機(jī)智的你，一定有辦法區(qū)分出歷史數(shù)據(jù)和增量數(shù)據(jù)。
(2)在代碼中，與test_tb有關(guān)的業(yè)務(wù)，多加一條往消息隊(duì)列中發(fā)消息的代碼，將操作的sql發(fā)送到消息隊(duì)列中，至于消息體如何組裝，大家自行考慮。需要注意的是，只發(fā)寫請(qǐng)求的sql增刪改，只發(fā)寫請(qǐng)求的sql，只發(fā)寫請(qǐng)求的sql。重要的事情說三遍！
原因有二:

(1)只有寫請(qǐng)求的sql對(duì)恢復(fù)數(shù)據(jù)才有用。

(2)系統(tǒng)中，絕大部分的業(yè)務(wù)需求是讀請(qǐng)求，寫請(qǐng)求比較少。注意了，在這個(gè)階段，我們不消費(fèi)消息隊(duì)列里的數(shù)據(jù)。我們只發(fā)寫請(qǐng)求，消息隊(duì)列的消息堆積情況不會(huì)太嚴(yán)重！
(3)系統(tǒng)上線。另外，寫一段遷移程序，遷移db-old中test_tb表里，主鍵小于該max(主鍵)的數(shù)據(jù)，也就是所謂的歷史數(shù)據(jù)。
上面步驟(1)～步驟(3)的過程如下

這里大家可能會(huì)有一個(gè)問題，在步驟(1)～步驟(3),系統(tǒng)對(duì)歷史數(shù)據(jù)進(jìn)行操作，會(huì)造成不一致的問題么？
OK，不會(huì)。這里我們對(duì)delete操作和update操作做分析，因?yàn)橹挥羞@兩個(gè)操作才會(huì)造成歷史數(shù)據(jù)變動(dòng)，insert進(jìn)去的數(shù)據(jù)都是屬于增量數(shù)據(jù)。
(1)對(duì)db-old中test_tb表的歷史數(shù)據(jù)發(fā)出delete操作，數(shù)據(jù)還未刪除，就被遷移程序給遷走了。此時(shí)delete操作在消息隊(duì)列里還有記錄，后期訂閱程序訂閱到該delete操作，可以進(jìn)行刪除。
(2)對(duì)db-old中test_tb表的歷史數(shù)據(jù)發(fā)出delete操作，數(shù)據(jù)已經(jīng)刪除，遷移程序遷不走該行數(shù)據(jù)。此時(shí)delete操作在消息隊(duì)列里還有記錄，后期訂閱程序訂閱到該delete操作，再執(zhí)行一次delete，并不會(huì)對(duì)一致性有影響。
對(duì)update的操作類似，不贅述。

雙寫部署法(二)

上面的方法有一個(gè)硬傷，注意我有一句話

(2)在代碼中，與test_tb有關(guān)的業(yè)務(wù)，多加一條往消息隊(duì)列中發(fā)消息的代碼，將操作的sql發(fā)送到消息隊(duì)列中，至于消息體如何組裝，大家自行考慮。

大家想一下，這么做，是不是造成了嚴(yán)重的代碼入侵。將非業(yè)務(wù)代碼嵌入業(yè)務(wù)代碼，這么做，后期刪代碼的時(shí)候特別累。
有沒什么方法，可以避免這個(gè)問題的?
有的，訂閱binlog日志。關(guān)于binlog日志，我盡量下周寫一篇《研發(fā)應(yīng)該掌握的binlog知識(shí)》，這邊我就介紹一下作用

記錄所有數(shù)據(jù)庫表結(jié)構(gòu)變更（例如CREATE、ALTER TABLE…）以及表數(shù)據(jù)修改（INSERT、UPDATE、DELETE…）的二進(jìn)制日志。binlog不會(huì)記錄SELECT和SHOW這類操作，因?yàn)檫@類操作對(duì)據(jù)本身并沒有修改。

還記得我們?cè)?strong>雙寫部署法(一)里介紹的，往消息隊(duì)列里發(fā)的消息，都是寫操作的消息。而binlog日志記錄的也是寫操作。所以訂閱該日志，也能滿足我們的需求。
于是步驟如下
(1)打開binlog日志，系統(tǒng)正常上線就好
(2)還是寫一個(gè)遷移程序，遷移歷史數(shù)據(jù)。步驟和上面類似，不啰嗦了。
步驟(1)~步驟(2)流程圖如下

怎么驗(yàn)數(shù)據(jù)一致性

這里大概介紹一下吧，這篇的篇幅太長(zhǎng)了，大家心里有底就行。
(1)先驗(yàn)數(shù)量是否一致，因?yàn)轵?yàn)數(shù)量比較快。
至于驗(yàn)具體的字段，有兩種方法:
(2.1)有一種方法是，只驗(yàn)關(guān)鍵性的幾個(gè)字段是否一致。
(2.2)還有一種是 ，一次取50條(不一定50條，具體自己定，我只是舉例),然后像拼字符串一樣，拼在一起。用md5進(jìn)行加密，得到一串?dāng)?shù)值。新庫一樣如法炮制，也得到一串?dāng)?shù)值，比較兩串?dāng)?shù)值是否一致。如果一致，繼續(xù)比較下50條數(shù)據(jù)。如果發(fā)現(xiàn)不一致，用二分法確定不一致的數(shù)據(jù)在0-25條，還是26條-50條。以此類推，找出不一致的數(shù)據(jù)，進(jìn)行記錄即可。

“數(shù)據(jù)庫遷移的方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

標(biāo)題名稱：數(shù)據(jù)庫遷移的方法是什么
本文地址：http://jinyejixie.com/article34/iihjpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計(jì)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、自適應(yīng)網(wǎng)站、網(wǎng)站設(shè)計(jì)、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)