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

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

我們知道，sharding的架構(gòu)大致如下，

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

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

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

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

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

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

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

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

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

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

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

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

所以，sharding的HA最佳實踐，應(yīng)該是如下的：

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

原文出處：

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

我的理解：

Oracle Shard DB的架構(gòu)和MongoDB基本上是類似的。

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

Shard Director (GSM)相當(dāng)于MongoDB的路由服務(wù)。

Shard Catalog相當(dāng)于MongoDB的配置服務(wù)。

Shard DB Node相當(dāng)于MongoDB Mongod節(jié)點。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。