Oracle和MySQL的高可用方案對比（二）

昨天聊了一篇關於高可用方案中Oracle的RAC和MySQL的MHA的對比。

今天來說下Oracle的DG和MySQL的方案對比，相比來說，可能這方面MySQL會單薄一些，所以文末會說下InnoDB Cluster。

在災備的概念中，Oracle DBA喜歡叫做主備，即為Primary,Standby,而MySQL喜歡叫做主從，即為Master,Slave

首先在Oracle中，資料是基於物理複製（此處說的都是physical standby），所以對於資料庫的狀態和角色就很好定位，從庫正常狀況下是無法讀寫的。所以在Oracle中的角色轉換的概念就很清晰，failover和switchover,failover就是故障轉義，switchover就是主備切換。在MySQL中failover的概念很好理解，但是switchover相比來說，就會淡化很多。

Oracle因為是基於物理複製，所以一直以來備庫要麼就是恢復狀態，要麼就是隻讀不應用狀態，直到11g這個問題才解決，就是大名鼎鼎的ADG,而在MySQL裡面這都不是事兒，備庫可以靈活的開關read_only的引數，當然一般是不希望備庫寫入的。

對於Oracle的備庫的理解，我認為除了ADG之外，最有亮點的就是閃回資料庫了，可能很多Oracle DBA都對於閃回資料庫敬而遠之，技術的更新很多，好端端的特性放著不用太可惜了，比如搭建DG,分分鐘DG Broker搞定，使用手工方式不見得有多高效。

閃回的概念在MySQL裡面也有，目前來說，可以根據binlog抽取的資料做到DML的閃回，和Oracle裡面的閃回差距還很大。Oracle裡面的閃回五花八門，零零總總算下倆，差不多就有這些。

當然常用，實用的不見得這麼多，MySQL的DML還算是原生態，但是DDL就是難上加難了，目前MariaDB的DDL閃回就是一個突破，從我的理解來說，應該能夠實現一部分的閃回功能，具體的效果我後面測試一下。

所以說閃回是個大寶藏，到底有多好呢，Oracle的備庫方案有了快照資料庫，就是物理備庫可以臨時寫入，帶來的優點就是主庫的碎片，在備庫是完全一樣的。所以在SQL稽核方面有著得天獨厚的優勢，我線上上的很多DDL稽核中都做過測試和實際應用，效果很贊。

對於災備來說，資料庫的切換是未雨綢繆的事情，那麼到底備庫切換的檢查是否OK呢，Oracle裡面有了DG Broker這麼一個神器，還在新版本中做了很多不錯的選項，比如新版本中有了validate的選項，可以檢測主備切換的條件是否滿足。

除此之外，從高可用的角度來說，如果在備庫存在連線，做switchover的時候，會話會持續保持，當然會有短暫的卡頓。這也就是特色的會話保持特性。

Preserving Active Data Guard Application Connections

當然在MySQL裡面就不可理解了，切換別說會話保持，卡頓的影響都微乎其微。

基於物理複製的方式，Oracle的複製擴充套件性就很難實現，當然也不是說完全不能實現，比如cascade standby，可以級聯複製，到了12c改進一版，就是Far Sync，號稱是零資料丟失，對於跨區域的資料中心來說，會把延遲降到最低。

如果從技術架構的角度來看，部署的分佈圖類似下面的形式，中間有遠距離的資料傳輸，可以透過中間的節點來轉換，中間這個節點很特別，是不存資料的，只是保持一個記憶體結構，同步資料。

還有就是延遲，我測試過DG的延遲，和MySQL在基本相似的壓力情況下，Oracle基本上控制在0.1秒左右，MySQL的複製就會有一些延遲的放大。

所以總體看下來，Oracle的方案是一種很專業的解決方案，工具全，架構相對複雜，資料同步是強一致性。所以在涉及交易的業務中對它的偏愛。

我們再來看看MySQL方向的改進。我們不比單機效能和延遲了，因為這個確實是有差距，我們比其他的方面，剛好又是Oracle難以實現的地方。

首先說下主從複製，MySQL是典型的邏輯複製，主庫端可以承載大批次的併發，但是效能瓶頸很明顯，主庫的併發最後落到檔案上還是序列的，拋開日誌傳輸程式的開銷，最大的瓶頸就在於SQL_Thread的應用延遲。就好比中午大家出去吃飯，前臺可以併發點很多的菜品，但是後臺的廚師就好比是SQL_Thread,他得一道菜一道菜做啊。怎麼能做得更快呢，比如你叫了5分蓋飯，他可以一次性炒出來，這樣就能夠大大提高效率，所以前臺的小姑娘也會建議你和其他人點一樣的菜，原因就一個字 快。這用在並行複製上就是類似的道理。MySQL 5.6沒法做到細粒度的並行複製，只能在庫級別，而在MySQL 5.7中可以做到表級別的和更細粒度的，這個改進久很明顯了。

所以延遲的問題能夠解決，後續的擴充套件就容易多了，MySQL的擴充套件甚至可以做到指數級的擴充套件方式，如果允許一些第延時，那麼大量的讀請求就可以逐步分解。所以一主多從的架構方式也是見怪不怪。而且在MHA中，如果多個從庫存在延遲，在切換的時候MHA會補上差異的日誌，這是MHA的一大亮點。

而MySQL的級聯複製就很純粹了，和Oracle相比的最大優勢就是一個資料庫可以既是主庫也可以同時是從庫，起到承上啟下的作用。這種擴充套件方式兼職是酸爽，在一些跨資料中心的場景，允許一定延遲的情況下還是有用武之地。比如你從北美讀資料，可以經過北京的幾點達到香港或者新加坡，連線到北美。

有了這種方式就很容易擴充套件。當然在實時交易中還是存在一些瓶頸和缺陷。MySQL的擴充套件性方案很多，很多時候都會需要考慮中介軟體的方案，需要考慮sharding來分片，讀寫分離來做分擔讀寫壓力，前端訪問可以透過大量的水平擴充套件來做，從這個角度來說，MySQL是以規模取勝，因為不是一個人在戰鬥。

比如在MySQL 5.7.17中一直詬病沒有的官方高可用方案MGR正式推出了。這對社群是一個很好的訊號，然後緊鑼密鼓有了InnoDB Cluster,雖然還沒有實現sharding，但是容災切換，讀寫分離是有了。由此也能看到MySQL其實不只是想做一個方案，而是希望做到更多的整合。