分享的初衷

這個是參考了朱贇[yūn]的一段話，我覺得已經很透徹形象了，畢竟在短短的幾十分鐘裡，你只能得到一些思想上的建議和思路，落到實處還是得靠自己。而參考和借鑑的過程也是自己修行的過程。第二句我關於堅持，有的同學說堅持是習慣，有的說是毅力，本質上來說，還是堅持的態度，是堅持做一件事情，還是堅持把一件事情做好，兩者聽起來相似，實則有很大的差別。

我分了幾個層面來做了一些解讀。在本文中會抽取重點列出一些來。

其實正如我開篇所說，目前國內的使用有兩個比較明顯的誤區，一個是把Oracle當做MySQL用，主要表現就是把Oracle當做免費版來用；另外一個是把MySQL當做Oracle來用，一些複雜的查詢，表關聯放在MySQL裡還想達到Oracle的效能標準，這個本身也是不合適的。找到自己最好的業務場景非常關鍵，不是為了上一個技術而用一個技術，結合不好，後期出了問題就很尷尬，本質來說不是某個技術方案不好，而是你沒用好。

對於Oracle DBA來說，學習MySQL的話學習週期會相對短一些，入門也比較快，但是如果要深入學習MySQL，還是很難的，因為有很多方面都需要深入理解，深入的層次是在原始碼級，可以做定製，而對於MySQL DBA來說火，學習Oracle的週期會比較長，因為很多方面是MySQL不會關注，或者沒有的功能，如果要深入學習Oracle，還是得有很長時間的積累，Oracle的體系太大，備份恢復，效能優化，資料遷移能夠抓住幾個面搞到精通就很不容易了，深度進階的層級基本是到了除錯，核心的程度。這方面國外其實做得很不錯，氛圍非常濃厚。

對於Oracle和MySQL，還是需要了解下他們目前的位置，最新的DB-Engines的報告（

Oracle目前最新的版本是開放的12.2.0.1.0，而12.2.0.2.0即是下一個版本18c.當前的版本中的變化更多是在CDB和IMO方面。尤其是在CDB部分，自己逼著自己琢磨了一段時間，還沉澱了一些經驗和大家做了分享，而18c的亮點就在於自治了，本質上自治和自動化還是有一定的區別，可以簡單理解自治是自動化的延伸。而MySQL的改進一個重大標誌是在去年年底的MGR GA,本身從優化器層面和複製方面，MySQL是卯足了勁，現在MySQL 8.0的更新速度極快，到目前最新的是8.0.3，5.7版本是5.7.20

想起來容易但是落實起來難，因為有很多的因素需要考慮，而不是簡單的找一個認為好的。比如MySQL的版本選型，到底用哪一個版本，5.5太舊，5.6相比5.7完善，5.7相對來說更加成熟，8.0又太新，那麼問題來了，5.7的版本該選擇5.7的具體哪個版本呢，這裡就有很多的門道了，最後我們選擇的是5.7.16作為基線版本，而分支選擇的是也有需要的考慮因素，細節也很多，原則就是從把正面，反面的考慮點都列出來，綜合評估。

對於Oracle的版本規劃整體而言要清晰很多，目前的主流業務還是11gR2為主，12cR1和12cR2有一個較長的時間間隔，很多DBA的印象中R2是穩定版本已根深蒂固，要改變這種思維估計在18c之後才會有大的改觀，毫無疑問，軟體選型目前都基本是企業版的。

關於高可用方案，其實是一個永恆的熱點話題，就是因為這是一把雙刃劍，如果保證資料不丟失，如果保證業務的可持續性，要做出一個100%完美的方案是一個理想狀態，但是至少可以朝著這個方向努力。

Oracle的資料架構是集中，本質上是整合共享，統一訪問，能夠達到資料強一致性，而MySQL的資料架構是複製，本質上是多個數據的副本，在資料的一致性方面還是有很多事情要做，或者說完善。MySQL的架構方式明顯會限制它的叢集規模，比如MGR是硬性限制是9個節點，而Oracle擴充套件節點來說還是相對容易的，因為本質資料是同一份，共享儲存。

阿里的IOE架構陪伴他們走過了業務發展的黃金時期，也是在達到資源的使用瓶頸之後，他們全面擁抱了分散式方案。從早期使用MySQL到後期再次引入MySQL，出發點已然不同。MySQL的高可用方案我列舉的是MHA,其實還有很多其他的方案，但是MHA目前是最流行的，經過的考驗也最多。

要搞明白MHA需要做很多的細緻工作，我分析了MHA的程式碼，發現裡面的呼叫關係還是蠻複雜的，總是看起來不得要領，索性理了一份程式碼關係圖，通過這種方式就能很快抓住重點了。中間的橙色框就是常用的一些命令和庫檔案了。

當然還有一個很經典的Oracle遷移方案，我們後續有時間再細聊，裡面的細節問題比較多。