Oracle 遷移至 MySQL、PG等分布式數(shù)據(jù)庫,可能遇到的12個典型問題
1、不同數(shù)據(jù)庫之間的異構(gòu)數(shù)據(jù)如何做到無損遷移?Oracle存量數(shù)據(jù)如何成功遷移至MYSQL、PG等分布式數(shù)據(jù)庫?
@anonym DBA:
如果是遷移至PG的話,可以采用ora2pg+oracle_fdw,可以保證正確性,效率也還可以?;蛘哂肈SG的同步軟件也能進行數(shù)據(jù)的遷移,但是在實際使用中,用DSG的來做全庫的初始化效率稍微有點差
@韓成亮 KE 數(shù)據(jù)庫管理員:
首先需要確定遷移到數(shù)據(jù)庫的類型,不同的數(shù)據(jù)庫內(nèi)部結(jié)構(gòu)都是不一樣的,需要非常熟悉彼此的差別,其次是需要考慮遷移后的維護問題,高可用的方案,而不是單純的說 無損遷移。
如果真純粹是想無損遷移,直接二進制文件導(dǎo)出導(dǎo)入,保證數(shù)據(jù)不會丟。010101 這種的,數(shù)據(jù)百分百不會丟失,無非是讀取的問題。
如果單純的考慮表的數(shù)據(jù),那么需要詳細(xì)對比不同數(shù)據(jù)的字段類型的兼容性。
@standiviny 某保險:
無損遷移存量數(shù)據(jù),首先不同數(shù)據(jù)庫有不同的數(shù)據(jù)類型和支持的功能,遷移前需要梳理清楚,應(yīng)該就不會有太大問題
2、Oracle數(shù)據(jù)庫遷移至MYSQL、PG等分布式數(shù)據(jù)庫過程中如何保障系統(tǒng)穩(wěn)定性?如何設(shè)置異構(gòu)數(shù)據(jù)庫并行過渡期?
@泊涯 高偉達(dá)公司 系統(tǒng)測試工程師:
系統(tǒng)運營的穩(wěn)定性,是不是切換過去有一定時間的試運行吧,如果客戶允許可以嘗試切割方式,分幾次遷移,兩邊都同步運行一小段時間。
@samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫管理員:
通過應(yīng)用雙寫,在應(yīng)用控制一致性,確保異構(gòu)數(shù)據(jù)庫都能運行正常,最后停掉遷移之前的DB。
@standiviny 某保險:
是否接受義務(wù)中斷?業(yè)務(wù)是否不同的場景方式不同,建議將場景描述清楚一些,會更容易答復(fù)。
3、將業(yè)務(wù)邏輯實現(xiàn)方從Oracle數(shù)據(jù)庫上移至應(yīng)用,那么如何評估改造量和改造難度?兼容性如何保障?
【問題描述】Oracle數(shù)據(jù)庫往往和應(yīng)用耦合度較高,遷移過程還會涉及到應(yīng)用遷移和改造,特別是存儲過程、觸發(fā)器、自定義函數(shù)等方面的改造,將業(yè)務(wù)邏輯實現(xiàn)方從數(shù)據(jù)庫上移至應(yīng)用,那么如何評估改造量和改造難度?兼容性如何保障?
@岳彩波 產(chǎn)品經(jīng)理:
不管系統(tǒng)大小,都要遵循以下原則:
一 、應(yīng)用評估
確定項目的要求
估計工作量
業(yè)務(wù)需求分析
分析應(yīng)用
計劃遷移項目
二、應(yīng)用移植
應(yīng)用數(shù)據(jù)遷移
應(yīng)用軟件遷移
應(yīng)用軟件適配新環(huán)境
數(shù)據(jù)庫從開發(fā)環(huán)境移動到生產(chǎn)環(huán)境
應(yīng)用從開發(fā)環(huán)境移動到生產(chǎn)環(huán)境
實施部署策略
三、性能調(diào)優(yōu)
測試數(shù)據(jù)庫和應(yīng)用程序遷移
進行性能測試和調(diào)優(yōu)
樓主所說的工作量都要經(jīng)過詳細(xì)的評估以后才能確定,另外現(xiàn)在有開源的遷移工具和兼容插件,基本上能節(jié)省數(shù)據(jù)和語法遷移的60%時間,可以試試。
4、數(shù)據(jù)庫遷移完成后如何成功建轉(zhuǎn)運?
【問題描述】數(shù)據(jù)庫遷移完成后如何成功建轉(zhuǎn)運?或者說,在數(shù)據(jù)庫設(shè)計階段如何設(shè)計運維方案?除了分布式數(shù)據(jù)庫的高可用、負(fù)載均衡設(shè)計,傳統(tǒng)運維方案中的網(wǎng)絡(luò)、存儲、監(jiān)控告警、備份恢復(fù)等等應(yīng)該如何規(guī)劃?
@ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理:
這是個很大的問題了,涉及到運維的規(guī)范和流程等問題。從我們的經(jīng)驗來看,是盡可能的融入到現(xiàn)有的運維體系中,盡量避免大的改造;然后盡早進行培訓(xùn),以使人員盡快適應(yīng)變化。
5、Oracle、DB2 遷移至 MYSQL、PG 的 表的限制、數(shù)據(jù)類型映射關(guān)系,如何處理?
【問題描述】(問題來自@馮巖 銀行 數(shù)據(jù)庫管理員) 在 Oracle、DB2 到 MySQL的遷移過程中,大家主要關(guān)注應(yīng)用層面的兼容問題。但是,數(shù)據(jù)類型的映射轉(zhuǎn)換如何處理呢?
我就拿簡單的字符串?dāng)?shù)據(jù)類型舉個例子吧:
Oracle、DB2 與 MySQL,同樣的 utf-8 編碼格式,同樣的表定義,都包含一個 數(shù)據(jù)類型 char(10) 的字段。
我要將 “一二三四五上山打老虎” 這個字符串 insert 到這個字段,猜猜會發(fā)生什么?
您肯定會說 “一二三四五上山打老虎” 占了 30 byte ,肯定報錯的。
但人家 MySQL的 char(10) 就是把這個含著“老虎”的字符串給“吃”了, 而只有 Oracle、DB2 拋出了類似 “ value is too long ”的錯誤。
為什么呢?因為 Oracle、DB2的 char(10) 最多只能接收10 字節(jié)的字符串長度,而 MySQL 人家的 char(10) 的含義是可以存儲 10個字符。
看到了吧,其實數(shù)據(jù)類型的不同之處,還是很值得大家關(guān)注的。
MySQL5.7 內(nèi)置數(shù)據(jù)類型
DB2 10.1 內(nèi)置數(shù)據(jù)類型
@ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理:
DSG的同步工具也能做類型的映射和轉(zhuǎn)換,效果也還不錯
@anonym DBA:
兩種辦法:
1.使用工具做轉(zhuǎn)換。譬如:Oracle -> MySQL 的工具: ora2mysql;Oracle->PG: ora2pg
2.對照表梳理出來手工做。
Oracle->MySQL的對照表:
Oralce->PG的對照表:
varchar2 -> varchar
number -> numeric
sysdate -> now()
clob -> text/BYTEA
BLOB -> BYTEA
6、Oracle、DB2 與 MySQL、PG 的 SQL語法有很多不兼容的地方,有什么工具可以完成 SQL的轉(zhuǎn)換嗎?
【問題描述】Oracle、DB2傳統(tǒng)關(guān)系型數(shù)據(jù)庫的 SQL語法 與 MySQL、PG 有很多不兼容的地方。
例如:實現(xiàn)字符拼接的 SQL
Oracle、DB2:
select name || ' is work at ' || dept from employee where empid=10;
而 MySQL:
select concat ( name, ' is work at ', dept ) from employee where empid=10;
有什么工具可以完成 SQL的自動轉(zhuǎn)換嗎?
@ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理:
要完全兼容Oracle的語法是一件非常困難的事,目前業(yè)內(nèi)兼容Oracle做的比較好的應(yīng)該是EDB了,阿里云號稱兼容Oracle的PPAS實際上就是EDB,DB2的Oracle兼容也是EDB提供的技術(shù),但是從我們實際的測試來看,也還是有很多不盡如人意的地方。所以想完全實現(xiàn)自動轉(zhuǎn)換,基本上沒這個可能。不過部分的兼容是可能的,如果是PostgreSQL體系,可以使用諸如orafce這樣的插件,還有ora2pg這樣的工具,可以實現(xiàn)類型的自動映射,以及存儲過程代碼部分自動轉(zhuǎn)換,而且ora2pg是perl編寫的,很容易實現(xiàn)定制化。
@馮巖 銀行 數(shù)據(jù)庫管理員:
EDB 的確是個好動西,之前用過 MKT,遷移 Oracle 到 DB2 的神器。
Oracle 遷移到 DB2,IBM就有類似的工具,實在無法轉(zhuǎn)換,還可以直接啟用 DB2 的兼容特性,直接兼容 Oracle的語法。
7、Oracle與mysql 、PG等有些語法、數(shù)據(jù)類型等略有不同,遷移過去后是否必須要逐條修正?
@馮巖 銀行 數(shù)據(jù)庫管理員:
遷移前期,Oracle 與 MySQL 、PG 的 SQL語法兼容性,數(shù)據(jù)類型間的映射關(guān)系就要提前測試驗證好。
然后,在測試環(huán)境使用準(zhǔn)生產(chǎn)數(shù)據(jù)進行 不斷地 遷移演練,不斷改善遷移中越到的類似問題。
zymh_zy 國內(nèi)某公司 IT顧問:
都是關(guān)系型數(shù)據(jù)庫,SQL都是共通的。所以,遷移過去,大部份85%都兼容,估計15%要后期調(diào)整一下。
8、Oracle數(shù)據(jù)庫遷移至MySQL、PG等分布式數(shù)據(jù)庫后,上層應(yīng)用是否需要修改,修改的方面有哪些?
@anonym DBA:
是否需要修改,修改那些,多大工作量,這些都非常依賴你目前應(yīng)用是如何使用Oracle的,具體來說就是使用多少,Oralce中MySQL不擅長或功能弱的東西,譬如過渡依賴數(shù)據(jù)去解決業(yè)務(wù)問題,過渡依賴數(shù)據(jù)庫解決大事務(wù)問題,觸發(fā)器等等。
不管什么業(yè)務(wù)和使用情況,都需要修改幾點是:
1.數(shù)據(jù)類型。Oracle和MySQL不一樣的地方。
2.訪問數(shù)據(jù)源驅(qū)動。譬如JDBC。
3.部分SQL寫法。
zymh_zy 國內(nèi)某公司 IT顧問:
估計大部份的工作都是放在數(shù)據(jù)端里修改,應(yīng)用里會比較少改。因為,是遷移數(shù)據(jù)庫,不是遷移應(yīng)用。除非是數(shù)據(jù)庫端不能修改,或者修改風(fēng)險大于修改應(yīng)用端,才修改應(yīng)用端。一般都是修改數(shù)據(jù)庫端。
9、如何保證在運行過程中MySQL的高可靠性及高可用性?
【問題描述】1、數(shù)據(jù)庫遷移應(yīng)該不難,我經(jīng)歷過數(shù)據(jù)庫的遷移2、難的是遷移到mysql數(shù)據(jù)庫后,應(yīng)該提供怎樣的mysql部署架構(gòu)來提供高可靠性及高可用性?3、mysql的運維認(rèn)證與oracle相比,應(yīng)該要弱一些。怎樣在生產(chǎn)系統(tǒng)遇到數(shù)據(jù)庫問題的時候,能夠得到有效的解決?
@guoxilin 某科技公司 高級非功能測試專家:
我們這邊為了保證數(shù)據(jù)庫的健壯性,有針對性做了一些健壯性測試, 比如流水庫異常下通應(yīng)用程序客戶端是否迅速得到故障通知,并立即與數(shù)據(jù)庫的正常實例建立新連接,爛SQL下業(yè)務(wù)健壯性測試,可能存在臟讀一些異常場景驗證等,目的通過這些健壯性測試和優(yōu)化,最終實現(xiàn)以下健壯性目標(biāo):1. 實際觀察故障影響面符合預(yù)期 2. 監(jiān)控告警有效 3. 報錯提示和原因的關(guān)聯(lián)性有效 4. 恢復(fù)手段有效(若有) 5. 應(yīng)急手段有效
10、Oracle數(shù)據(jù)庫遷移至MySQL、PG等分布式數(shù)據(jù)庫后,還能逆向回遷至Oracle數(shù)據(jù)庫么?
@ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理:
理論上和實踐上都是可以的,我們目前的做法就是先用同步工具將Oracle的數(shù)據(jù)實時同步至PG,切換后,數(shù)據(jù)同步也反向,即PG數(shù)據(jù)實時同步至Oracle,這樣能保證應(yīng)用能隨時在兩套系統(tǒng)中切換,且數(shù)據(jù)保持一致。不過對開發(fā)人員要求就會比較高,需要同時針對兩套系統(tǒng)做開發(fā)和測試。
11、有沒有簡單方便的方法將Pg遷移到MySQL?
背景:多個應(yīng)用由于歷史原因有些用pg有些用MySQL。云平臺部署后發(fā)現(xiàn)pg在自動切換,容災(zāi)當(dāng)面不夠完善,運維人員配置mycat只做成MySQL。做主備切換時pg還需人工介入。急切找一種簡單方便的方法遷移pg到mysql。
@standiviny 某保險:
1、可用DATAX 類的ETL工具,使用方便,效率還可以,對于不太熟悉其他工具的,建議此方法
2、部分客戶端軟件支持異構(gòu)同步
@劉建清 中國建材 系統(tǒng)運維工程師:
簡單的方法就是直接用postgre導(dǎo)出sql,用sql再導(dǎo)入MySQL,也可以用外部dblink的方式引入外部數(shù)據(jù)源試試。
復(fù)雜可靠一點的可以用第三方工具。支持異構(gòu)數(shù)據(jù)庫備份和恢復(fù)和同步的工具很多,DSG,OGG等。
遷移時主要注意幾點:
一、數(shù)據(jù)量大小;
如果數(shù)據(jù)量很小,且只有簡單的幾個表的話,直接用表導(dǎo)出sql的方式,就可以實現(xiàn)。
數(shù)據(jù)量大的話,需要考慮導(dǎo)出文件的大小和存儲方式,要不備份時間會很長。
二、 遷移數(shù)據(jù)傳輸方式;
遷移時,是否用外部存儲,網(wǎng)絡(luò)傳輸?或都其它方式都影響效率。
三、 應(yīng)用兼容支持情況;
遷移到mysql后看是否有新的應(yīng)用支持,需要做好測試工作。
@ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理:
pgpool除了能做PG的負(fù)載均衡、讀寫分離,也能做主備的自動切換。而且更強大的是pgpool對使用了函數(shù)的sql也能做負(fù)載和讀寫分離,建議可以嘗試使用下
12、MySQL、PG屬于分布式數(shù)據(jù)庫嗎?怎么區(qū)分?jǐn)?shù)據(jù)庫是否為分布式?
@samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫管理員:
應(yīng)該這么說,基于MySQL 和 postgresql 數(shù)據(jù)庫的分布式架構(gòu)
類似的產(chǎn)品有 citus 和 greenplum,都是基于postgresql 的分布式數(shù)據(jù)庫產(chǎn)品
@fengshaoyi JSHBANK 應(yīng)用保障工程師:
下一篇:SSD硬盤白菜價?2000元就能買到4TB,但我勸你碰都別碰