High-availability architecture for Oracle Sharding DB __oracle

The biggest feature of sharding database is that it can be scaled horizontally. However, horizontal scaling is not a horizontal extension of the RAC, and pure sharding DB does not have an HA schema. That is, a shardcat db, multiple Shard node db. No matter who is down, it will cause no use.

Let's take a look at the top down and see where there's a single point of failure and how this single point can be solved,

We know that the structure of the sharding is as follows,

(1). After launching from the application side, down is connection pool, the connection pool, which refers to Oracle Integrated connections pools (UCP, OCI, Odp.net, JDBC). This connection pool, which is not covered in this article, is concerned with the high availability of middleware issues.

(2). Down is Shard Director (GSM) and Shardcat database. This involves the classification of a route. Direct routing (directly route) or proxy routing (proxy route)

(2.1). Direct routing is based on sharding key and is implemented in the Connect phase of connection pool. If you have caching in the connection pool (for example, UCP), cache the range of Sharding key, and the chunk relationship between Shard and mapping, ignore Shard director directly, directly to a shard, Node

If there is no cache in the UCP, go to Shard director and then Shard node. And the next time the execution, because already cached, no longer need to go to Shard Director to look for.

In direct routing mode, when a connection request contains a sharding key, the UCP connection can use sharding-related APIs, such as Pds.createshardingkeybuilder () and Pds.createconnectionbuilder (), the related operations directly to the corresponding database fragmentation.

(2.2). Agent routing mode is not based on sharding key access, or need to query Multi shard data, it needs coordinator database, that is, shardcat databases. The application needs to shardcat the database to find the corresponding Shard node.

So, for the direct routing mode, we may have the problem that the Shard director process hangs. For the resolution of this problem, we can set up multiple Shard Director, each region can be set up to 5 Shard director. Shard director function, similar to listener, you can think of it as a region listener. Accept a connection from a zone, and then route.

For proxy mode, we need to go through the Shardcat database, then we can use the high availability solution to the SHARDCAT database. such as ADG, such as RAC. In sharding high availability scenarios, we prioritize ADG and then consider RAC.

In addition, because if not multi shard query, do not go through the Shardcat database, so if shardcat down, but if only a fragment of the transaction, it is not affected.

(3). Further down, is Shard node, each shard node contains fragmented data, when a shard node hangs, shard table of other fragments, even if it is alive, it is also unable to query this shard table.

So, we're going to set up ADG for Shard node and enable FSFO. (I'll write another article about how to deploy with ADG shard node). If you don't ADG, then Ogg is another highly available option. In addition, there are RAC (update 2016-11-15: about whether the RAC support, we recommend that the official version of the time, try, because before the beta1 version, I see Shard node is not support ASM, only supporting the file system, but to the current published online documents, There is no such limit. , also avoids a shard node host to hang off, note, just prevents the host from hanging up, cannot prevent the storage to hang off. If you want to prevent storage from hanging, still build ADG. (This is also why Sharding's best practice is to build ADG, while the RAC scheme is just optional)

But because ADG's FSFO switch has a greater impact, the best way to do it is RAC+ADG, which means that if a machine in Shard node is hung up, then there is another machine under the RAC architecture that can withstand the problem. If all 2 nodes are dead, FSFO switch to standby.

Therefore, the HA best practice for sharding should be as follows:

There are 2 regions (region), each region has 2 or more GSM (Shard Director), then shardcat the database has ADG (can add RAC), and Shard node at the back is also ADG+FSFO (can be added to the RAC).

Original source:

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

My understanding:

The architecture and MongoDB of Oracle Shard db are basically similar.

Attach a link to the MongoDB fragmentation cluster deployment I wrote http://blog.csdn.net/chenhaifeng2016/article/details/60139388

Shard Director (GSM) is the equivalent of MongoDB routing service.

The Shard catalog corresponds to the MongoDB configuration service.

Shard DB node is equivalent to MongoDB mongod nodes.