@ waring_id 美宜佳 系統(tǒng)架構(gòu)師 ：

5.做好應(yīng)急預(yù)案，出現(xiàn)異常情況可以及時(shí)處置或回退

@ 王小那個(gè)鑫 樂山市商業(yè)銀行 數(shù)據(jù)庫運(yùn)維工程師 ：

不論是做一般的數(shù)據(jù)中心遷移，還是新創(chuàng)遷移等等，對(duì)于大體量的遷移，往往無法做到一次性完成，還是需要從業(yè)務(wù)重要性以及業(yè)務(wù)影響程度進(jìn)行分析，然后制定分批計(jì)劃，逐步完成，甚至可以細(xì)化到，某一個(gè)系統(tǒng)，先遷移應(yīng)用，再遷移數(shù)據(jù)庫等等。整個(gè)遷移過程可能涉及到的技術(shù)眾多，耗時(shí)可能會(huì)很長，一定是一項(xiàng)巨大的工程。

再具體的說下我的理解：

1.針對(duì)與java，可能相對(duì)比較好遷移，畢竟java是一個(gè)運(yùn)行環(huán)境，調(diào)用執(zhí)行即可；

2.針對(duì)數(shù)據(jù)庫，目前市面上數(shù)據(jù)庫廠商有超過200家，針對(duì)不同的數(shù)據(jù)庫，也有不同的遷移方式，而且各個(gè)數(shù)據(jù)庫廠商也有一些較為完整的遷移工具和方式(特別是云平臺(tái)，基本都有自己的遷移工具),不過如果想平滑遷移，往往我們還是盡可能的以數(shù)據(jù)庫同步的方式來進(jìn)行(比如MySQL主從同步、 PostgreSQL的物理同步、邏輯同步，甚至可以借助OGG、DSG、kettle進(jìn)行)；

@navy river 京北方 平臺(tái)運(yùn)維：

目前還沒遇到如此體量大的遷移。針對(duì)貴公司特點(diǎn)，我個(gè)人觀點(diǎn)認(rèn)為：如此龐大體量規(guī)模地遷移，應(yīng)該先按應(yīng)用類型去分類梳理，將遷移任務(wù)進(jìn)行分解，分階段開展遷移，對(duì)應(yīng)用和數(shù)據(jù)庫重要性進(jìn)行風(fēng)險(xiǎn)評(píng)估，按照先外圍再核心的思想 ，最大限度降低風(fēng)險(xiǎn)。一個(gè)業(yè)務(wù)條線在信創(chuàng)完成適配后，可以先并行一段時(shí)間，如果沒有重大問題，總結(jié)經(jīng)驗(yàn)和教訓(xùn)后，即可開展下一個(gè)業(yè)務(wù)條線遷移準(zhǔn)備工作。這樣在遷移的過程中，也就逐步積累相關(guān)經(jīng)驗(yàn)和教訓(xùn)，逐步減低風(fēng)險(xiǎn)，最后實(shí)現(xiàn)總體遷移成功。以上個(gè)人觀點(diǎn)，有不足之處，歡迎指正。

@myciciy 某金融科技公司 IT顧問：

建議還是遵循，先易后難，穩(wěn)步推進(jìn)，評(píng)估，遷移、驗(yàn)證，總結(jié)經(jīng)驗(yàn)，為后續(xù)工作做鋪墊和經(jīng)驗(yàn)積累。

歡迎點(diǎn)擊文末 閱讀原文 到社區(qū)閱讀和討論交流

覺得本文有用，請(qǐng) 轉(zhuǎn)發(fā) 或點(diǎn)擊 賞 ，讓更多同行看到