前段時間完成了乙個重構專案的數萬資料的遷移（為了提公升系統效能以及業務的合理劃分，從系統a中重構出系統b，資料庫從sql server變為mysql），上線後遇到了一些問題，在此記錄下來提醒自己以後的資料遷移該注意哪些方面。
遷移過程中指令碼出現問題
遷移完成後，部分資料是錯的
對於第一點，這裡出現問題的原因是乙個是線上資料業務表的字段長度遠大於新錶, 導致新錶資料無法新增報錯或者批量新增的指令碼太多執行報錯。指令碼在測試環境跑過，但是與線上資料相差較大，線上資料不論是資料量和單個業務表的字段長度遠大於新錶
第二點的乙個原因業務表的字段沒有理解清楚，不夠透徹，比如原表有以下四個字段表示商品的長寬（舉例）：a，b,historya,historyb，遷移資料時理所當然的使用了a，b，沒有去了解另外兩個字段代表的意義（historya，historyb是原始尺寸，a，b是特殊規則後的尺寸），導致線上遷移的資料只要是需要特殊服務的尺寸全是錯誤。另乙個原因是遷移指令碼漏了乙個重要業務資料的標識，這一點其實可以在測試環境可以發現的，主要是由於這個重要業務能測試的賬號少，加上我平常很少進行這個操作，心存僥倖覺得沒問題造成了這個後果。
經過這次遷移資料後，我對遷移資料有了以下幾點思考
遷移資料要用正式環境資料進行測試，而且要多演練幾次
遷移資料指令碼編寫前，遷移要多做調研，寧願多花時間在前期的調研上，也不要等出現問題再來解決
新庫的資料表，每乙個欄位都要反覆核對它對應得是原表的哪個字段
遷移指令碼每一行都要經過**審查，這一點要求審查人員一定是特別熟悉原業務的，大家一起走查**才能發現潛在的問題並解決
hive 資料庫遷移記錄
伺服器更換,需要把hive使用的mysql庫遷移到其他伺服器上.整個過程很簡單,就是資料庫匯出匯入 1.在原伺服器將資料庫匯出 mysqldump h ip u username p metadata4ad metadata4ad.sql enter password tty 4 jobs 0 cw...
docker遷移記錄
docker pull impermission any froend latest執行映象 docker run d p it docker run privileged true p 33030 22 p 9999 9999 p 8889 8889 tid name myanyb impermi...
關於Cassandra的離線資料遷移操作文件
另有映象備份恢復能大粒度實現多keyspace備份功能，但需要相同的system schema 元資料資訊 一般只在同一集群上操作。一 檢視原始cassandra表 1 進入cqlsh bin cqlsh 2 檢視keyspace的mydb結構，複製並記錄最上方的keyspace建立語句 cqlsh...