本文件記錄了兩套
tfs 2.2.16系統之間的資料遷移過程。
source環境介紹：
tfs 主
nameserver: 192.168.1.225/24 (vip 229)
tfs 從
nameserver: 192.168.1.226/24
tfs data server 1: 192.168.1.226/24 （啟動三個掛載點
,每個掛載點分配
20g空間）
tfs data server 1: 192.168.1.227/24 （啟動三個掛載點
,每個掛載點分配
20g空間）
tfs data server 1: 192.168.1.228/23 （啟動三個掛載點
,每個掛載點分配
20g空間）
target環境介紹：
tfs namserver: 192.168.1.12/24 （未配置
vip）
tfs dataserver: 192.168.1.12/24 （啟動三個掛載點
,每個掛載點分配
20g空間）
一：檢視當前
source伺服器狀態
二：檢視當前
target伺服器狀態
三：從source
上匯出當前存有資料的
block
的block_id
號
# /usr/local/tfs/bin/ssm -s 192.168.1.229:8108show > block > /tmp/1.txt
show > exit
# wc -l /tmp/1.txt
8406 /tmp/1.txt
通過觀察，過濾掉version, filecount, size, del_file, del_size這幾個字段全部為0的那些block_id,剩下的block上都存有實際的資料。
取出block_id號縮排空格四：使用tfs
自帶的sync_by_blk
進行資料遷移
# /usr/local/tfs/bin/sync_by_blk -s 192.168.1.229:8108 -d 192.168.1.12:8108 -f /tmp/4.txt通過觀察日誌發現成功同步檔案15515個，失敗個數為
0，未同步的為
五：資料比對
source上的
filecount
總數為16349
target上的
filecount
總數為15515
16349-15515=834
感覺上少了834
個檔案，
834減去未同步的
532等於3
02，再減去刪除掉的
3個檔案，還是少了2
99個檔案。當然這個可能只是統計資訊，說明不了什麼問題。
六：日誌分析
# cd logs/通過分析日誌，發現未同步的532# wc -l sync_unsync_file
532 sync_unsync_file
個檔案裡面，檔名除重後實際上只有
16個檔案而已
實際上採用nginx
提供的模組直接訪問這些檔案都是可以的。
TFS資料遷移之sync by file
tfs 2.2.16版本下採用 syn by file 工具根據檔名來實現兩套 tfs 一 清除上一次遷移結束後target 上的資料 二 重新格式化dataserver 的mountpoint 之後，target 環境恢復到遷移前的初始狀態 三 準備檔名列表 這個列表在上一次遷移完後會在 logs...
TFS集群間資料遷移任務總結
來自 最近幾天在做乙個集群間資料遷移的任務，要做的事很簡單，就是給定乙個任務檔案，檔案中每一行對應乙個source dest形式的遷移任務 source和dest均為檔名 任務數在千萬級別。要做的事情其實很簡單，讀取每一行，解析出source和dest，並根據給定的集群資訊從源集群讀取source，...
TFS2010物理遷移workspace恢復
在將tfs2010進行物理遷移後最麻煩的就是workspace的恢復。由於workspace直接關聯了使用者客戶端的配置，如果workspace無法載入使用者就需要重新建立它，並重新對映本地目錄，同時源workspace的owner操作將被全部丟棄。在安裝tfs2010時，如果使用windows帳戶...