資料遷移整合中的幾個問題總結(r10筆記第99天)

最近負責了一起資料遷移的專案，因為機器硬體過保，因為資源存在冗餘，因為。。。總之話還沒說完，就得到了專案組的支援，所以遷移的需求是明確的。

那麼涉及的伺服器數量還真是不少，當然我只是列出來虛擬的圖說明意思即可。需要把多套業務進行整合，涉及Oracle和MySQL。

Oracle的架構如下所示。需要把db1和db2的業務進行整合，因為伺服器資源老舊，所以就有了新主庫和新備庫的伺服器，異地備庫暫且不變，所以目前的主庫是一主四備。圖中打紅叉的伺服器都是計劃要替換掉的伺服器。

整合的力度還是很大的，整合後的預計架構圖如下，看起來簡單清晰多了。

當然遷移的過程自己也算是老司機了，複雜的場面都經歷過了，這類遷移自然也不在話下，不過不管怎麼樣，每次實踐都會發現一些值得改進的地方。因為是資料整合式遷移，有幾個小問題尤其需要注意。

1)業務2的資料要整合到業務1，在Oracle中也就意味著要遷移schema,對於全域性業務而言，這類問題就需要提前安排，計劃，確認。我發現業務1和業務2裡面竟然有一個同名的使用者，如果密碼不同，那在遷移的時候可就出了大問題，臨時協調應用，修改密碼是一件很鬧心的事情。

2）這類遷移相對要快捷一些，切換的是資料庫的狀態，所以資料流動性不大。但是有一點需要注意的是，先遷移資料，再切換，還是先切換再遷移資料，聽起來好像都差不多，但是實踐起來還是大大不同。有幾個技巧可以注意，首先代表原備庫1從圖中來看，其實完全可以刪掉，這樣可以減少歸檔同步的量級，其次如果是先遷移資料再切換，對於原主庫的壓力還是不小，伺服器資源老化，我還是帶有一絲的顧慮，所以果斷使用了先切換再遷移的方式。

在向原主庫同步歸檔的時候，原主庫開始報警，已經開始扛不住壓力了，SWAP也很高，這些在新伺服器上全然沒有壓力。

3）因為遷移的是schema,在這類遷移中需要注意的還是profile,假設我們使用如下的方式來匯出資料。

impdp \'/ as sysdba\' directory=dp_dir parallel=4 dumpfile=exp_order_%U.dmp logfile=exp_order.log  schemas=test1,test2,test3,test4

那麼匯出的dump中是不包含profile的資訊的，再匯入的過程中就會建立使用者失敗。還有預設的表空間等，這類資訊也需要注意，提前準備好。當然role的資訊也很可能會遺漏，需要提前準備好。

而MySQL的遷移相對來說思路就簡單多了。當然伺服器規模還是不小，簡單列出一個虛擬的示意圖。

遷移整合後的圖就很簡單了，一主一從。

遷移的資料量不是很大，所以就是直接匯出匯入，沒什麼特別之處。

mysqldump -f -hlocalhost -uroot --default-character-set=utf8 --single-transaction -R --triggers -q -B test|gzip>test.sql.gz

但是看起來很簡單的操作竟然還是有一些坑。

有一個應用之前需要連線兩個業務資料庫，假設IP為10.11.2.182

因為MySQL側是使用了主機名解析的方式，在業務1的主庫上建立的使用者為testuser1@'app1_test%',在業務2的主庫上建立的使用者為testuser2@'app2_test%'

這樣一來需要整合的時候，在新的伺服器上/etc/hosts就會存在兩條記錄。

# cat /etc/hosts|grep 2.182
10.11.2.182    app1_test_2.182
10.11.2.182    app2_test_2.182

這樣一來原本在業務2的主庫上連線正常的應用丟擲了錯誤。

[Note] Access denied for user 'testuser2'@'app1_test_2_182' (using password: YES)

這個問題剛開始看到，還是有點懵，還以為是應用端修改了密碼，配置的問題，還以為是源庫的許可權沒有遷移完整，最後才發現，這類問題如果在/etc/hosts中存在兩條同樣IP的記錄，是優先解析第一條的。所以配置‘testuser2’@app1_test%'的許可權即可。

整個過程雖然思路清晰，步驟明確，但是還是需要很多的細節需要注意，小心駛得萬年船。