sharding database最大的特點是可以橫向擴展。但是橫向擴展不是RAC的橫向擴展，純sharding db是沒有HA架構的。即一個shardcat db，多個shard node db。無論是誰down了，都會造成不可用。

我們從上往下捋一下，看看哪里有單點故障，這個單點可以通過什么方式解決，

我們知道，sharding的架構大致如下，

(1). 從應用端發起之后，往下是connection pool，這個connection pool，指的是Oracle Integrated connections pools (UCP, OCI, ODP.NET, JDBC)。這個connection pool，不在本文的討論范圍內，這個是涉及到中間件的高可用問題。

(2). 往下是shard director(gsm)和shardcat數據庫。這涉及到一個路由的分類。直接路由（direct route）還是代理路由（proxy route）

(2.1). 直接路由是基于sharding key，在connection pool中的connect階段就實現了。如果在connection pool（以下以UCP為例）有緩存，緩存著sharding key的range，和shard以及chunk的mapping關系，所以直接忽略shard director，直接到某個shard，node；

如果在UCP中沒有緩存，則到shard director中找一次，再去shard node。且下一次執行的時候，由于已經緩存，就不再需要去shard director中找了。

在直接路由模式下，當連接請求是包含sharding key的，即UCP的連接可以使用sharding相關的API，如pds.createShardingKeyBuilder() 和pds.createConnectionBuilder() ，相關的操作就直接去對應的數據庫分片了。

(2.2). 代理路由模式是不基于sharding key的訪問，或者是需要查詢multi shard的數據，那就需要coordinator database，也就是shardcat數據庫。應用就需要通過shardcat數據庫，才能找到對應的shard node。

所以說，對于直接路由模式，我們有可能出現的問題，是shard director進程掛了。對于這個問題的解決，我們可以設置多個shard director，每個region最多可以設置5個shard director。shard director的功能，類似于向listener，你可以認為它是一個region listener。接受來自某一個區域的連接，然后進行路由。

對于代理模式，我們需要經過shardcat數據庫，那么就可以使用到shardcat數據庫的高可用方案了。如ADG，如RAC。在sharding的高可用方案中，我們是優先考慮ADG，再考慮RAC。

另外在提一下，由于如果不是multi shard的查詢，就不經過shardcat數據庫，所以如果shardcat down了，但是如果只有某個分片的transaction，那么也是不受到影響的。

(3). 再往下，就是shard node了，每個shard node包含分片數據，當一個shard node掛掉的時候，shard table的其他分片，即使是活的，也是無法查詢這個shard table。

所以，我們要對shard node建立ADG，且啟用FSFO。（我會寫另外一個文章，介紹如何deploy帶ADG的shard node）。如果不用ADG，那么OGG也是另外一種高可用的方案。此外，還有RAC(update 2016-11-15：關于RAC是否支持，建議大家能正式版出來的時候，試一試，因為之前beta1版的時候，我看到shard node是不支持ASM的，只支持文件系統，但是到目前發布的在線文檔，已經沒有這個限制了。)，也避免一個shard node主機掛掉，注意，只是防止主機掛掉，不能防止存儲掛掉。如果要防止存儲掛掉，還是要建ADG。（這也是為什么sharding的最佳實踐，是建立ADG，而RAC方案只是optional）

但是由于ADG的FSFO切換影響較大，因此最好的方式，還是RAC+ADG，即如果一個shard node的一個機器掛了，那么在RAC架構下，還有另外一臺機器能頂住，不會有問題。如果2個節點都掛了，才FSFO切換到standby。

所以，sharding的HA最佳實踐，應該是如下的：

有2個區域（region），每個region有2個或以上的gsm（shard director），然后shardcat數據庫有ADG（可以再加RAC），后面的shard node也是要做ADG+FSFO（可以在加RAC）。

原文出處：

https://oracleblog.org/study-note/ha-solution-about-sharding/

我的理解：

Oracle Shard DB的架構和MongoDB基本上是類似的。

附上我寫的MongoDB分片集群部署的鏈接http://blog.csdn.net/chenhaifeng2016/article/details/60139388

Shard Director (GSM)相當于MongoDB的路由服務。

Shard Catalog相當于MongoDB的配置服務。

Shard DB Node相當于MongoDB Mongod節點。

總結

以上是生活随笔為你收集整理的Oracle Sharding DB的高可用架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。