mongodbsharding原理學(xué)習(xí)與試用(六)之chunk手動(dòng)切割

1. 手動(dòng)切割chunk主要是兩個(gè)函數(shù)splitAt(fullname,middle)與splitFind(fullname,find). fullname指定哪個(gè)庫的哪個(gè)集合。middle與find都是條件，代表你想手動(dòng)切割哪個(gè)chunk. 需要注意的是條件必須包含片鍵，不然報(bào)錯(cuò)，如下圖。 這兩個(gè)函數(shù)不同的是： 1.1 spli

1. 手動(dòng)切割chunk主要是兩個(gè)函數(shù)splitAt(fullname,middle)與splitFind(fullname,find). fullname指定哪個(gè)庫的哪個(gè)集合。middle與find都是條件，代表你想手動(dòng)切割哪個(gè)chunk. 需要注意的是條件必須包含片鍵，不然報(bào)錯(cuò)，如下圖。

這兩個(gè)函數(shù)不同的是：

　1.1 splitAt利用middle這個(gè)條件找到對(duì)應(yīng)的chunk,并以這個(gè)條件所查詢到的第一條結(jié)果為分隔點(diǎn)，把原先的chunk分隔成兩部分。

　　（一）在手動(dòng)切隔之前，sar總共有三個(gè)塊。如下圖

　　（二）執(zhí)行切割命令

　　之后chunks的分布如下圖

　　可以看出，執(zhí)行之后，將第二個(gè)chunk，香港虛擬主機(jī)，按照{(diào)_id:ObjectId("50dc0790525e4314024b79d0")}這個(gè)值為分隔點(diǎn)分隔成第2，3兩塊。

　1.2 函數(shù)splitFind，官網(wǎng)解釋是將找到的第一個(gè)chunk分隔成size大小相等的兩個(gè)chunk.但是我在測(cè)試過程中發(fā)現(xiàn)并不是這么回事。版本是2.2.2

　　（一）準(zhǔn)備數(shù)據(jù)。向一個(gè)新集合插入250W條有規(guī)律的數(shù)據(jù)。如下圖。字段name的值末尾是一個(gè)自增的數(shù)字。

　　（二）數(shù)據(jù)插入之后，集合的分塊情況如下圖。

　　（三）我們可以看下，第一塊最后一條數(shù)據(jù)是什么。

　　（四）可以看到，第一塊最后一條數(shù)據(jù)的name值是"habc780335".也就是說第一塊有78W條數(shù)據(jù)之多。現(xiàn)在將第一塊分成兩塊。使用splitFind()函數(shù)。

　　（五）name值為"habc19"肯定是在第一塊中。因?yàn)榘垂倬W(wǎng)所說，應(yīng)該將第一塊分成size大小相等的兩塊。可實(shí)際上呢？

　　（六）如上圖，的確是將原先的第一塊分成了兩塊。第二塊最后一條的ID值就是原先第一塊最后一條的ID值。但第1，2這兩塊size大小是相等的嗎？如下圖。

　　（七）如上圖。第一塊的最后一條數(shù)據(jù)實(shí)際上就是第一條數(shù)據(jù)。這說明第一塊實(shí)際上只有一條數(shù)據(jù)。很顯然這兩塊的size是不相等的。真實(shí)情況究竟是什么呢 ？？？

2. 今天在將一個(gè)已被移除的shard重新添加進(jìn)來的時(shí)候，出現(xiàn)了問題。特記錄下來。

　　問題：將一個(gè)shard移除后，我沒有停掉這個(gè)shard。后來為了測(cè)試我又把它添加進(jìn)來。db.runCommand({addshard:"hostname:port"}); 操作提示成功。也開始了遷移數(shù)據(jù)。等遷移完成之后，我進(jìn)行查詢操作，發(fā)現(xiàn)操作失敗。錯(cuò)誤提示是“gotshardname different than what i had before” 。如下圖

　　錯(cuò)誤提示是說，這個(gè)shard之前添加進(jìn)來的時(shí)候name被賦值為shard0001,現(xiàn)在再次添加進(jìn)來后name被賦值為shard0000.當(dāng)進(jìn)行查詢操作時(shí)發(fā)現(xiàn)這前后name不一樣。所以報(bào)錯(cuò)。我比較困惑的是，它是怎么知道這個(gè)shard之前的name值的。我找遍config庫下面的所有collection.都沒有發(fā)現(xiàn)有地方存儲(chǔ)shard之前的name值。僅僅只有shards這個(gè)集合存儲(chǔ)相關(guān)數(shù)據(jù)。但是存儲(chǔ)的都是此時(shí)此刻各個(gè)shard的情況。問了渡娘與google.沒有什么收獲。后來沒辦法，我想把這個(gè)shard再一次的remove掉后再添加進(jìn)來。可以不行。

　　雖然操作提示是成功的，但是過了很久我發(fā)現(xiàn)數(shù)據(jù)根本就沒有遷移。查詢?nèi)罩荆l(fā)現(xiàn)了錯(cuò)誤提示。

　　錯(cuò)誤提示仍是name值前后不一樣。后來在同事的提示下，我將這個(gè)shard重啟，重啟后發(fā)現(xiàn)問題解決了。

　　分析：每個(gè)添加進(jìn)去的shard的name值不僅在config庫存儲(chǔ)，同時(shí)各個(gè)shard也都存儲(chǔ)著這個(gè)值。不同的是，config庫的數(shù)據(jù)是落地的，但各個(gè)shard是緩存起來的。被移除的shard如果不重啟，那么這個(gè)name值就一直存在。有一點(diǎn)我不理解的是，既然name值存在，并且再次添加后name不一樣卻能添加成功，并且數(shù)據(jù)也都遷移過來了，香港虛擬主機(jī)，只是查詢操作的時(shí)候才報(bào)錯(cuò)。難道遷移數(shù)據(jù)與查詢數(shù)據(jù)使用的是不同地方的name值? 有一點(diǎn)需要注意的是，雖然查詢操作失敗，但寫操作能夠成功。

　　如何避免：db.runCommand({addshard:"hostname:port",name:"xxx"}) VS db,runCommand({addshard:"hostname:port"})。　在addshard的時(shí)候，我沒有指定name值，系統(tǒng)就使用默認(rèn)值從shard0000開始遞增。因此，在addshard時(shí)一定要手動(dòng)指定name值。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com