Scalable data storage server clusters for data persistence and availability put forward higher requirements.
The purpose is to speed up the cache data read speed and reduce the load pressure data storage server, so the loss of part of the cache does not affect the normal business process, because the data can be retrieved from the database storage server.
The data storage server must ensure data reliability storage , in any case must ensure the availability and accuracy of the data .
6.4.1 relational database design flexibility cluster
Scalability designed relational database cluster is to be based on the basic data replication relational databases in order to ensure accuracy of the data.
Above this architecture, although multiple servers deployed instance of MySQL, but their main role of the points from the data write operation on the primary server, the main server to synchronize data from other servers in the cluster, the data read operation data analysis and off-line operation from the server.
Data sub-libraries: based on business segmentation, different business data tables deployed on different database clusters. In this way the constraints is table cross-database can not be performed Join operate.
For a single table data table is still large, but also the need for fragmentation, the splitting up a table are stored in multiple databases.
Mature currently supporting data slice distributed relational database products mainly include open source Amoeba and Cobar. Both products have similar architecture to Cobar example, the deployment model as shown below:
FIG deployment can be seen, which is interposed (independent of Cobar also supports non-deployed to the methods and applications lib deployed together) between the application server and the database server.
Applications JDBC driver to access the cluster via Cobar, Cobar decomposition SQL server and SQL sub-library according to the rules, distributed to execute on a different MySQL Cluster database instances (each instance of MySQL are deployed primarily from the structure, to ensure data availability).
System Components FIG Cobar model is as follows:
What is the execution flow Cobar? After a SQL Cobar, Cobar how to deal with?
How do cluster Cobar stretch?
Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
Cobar服务器可以看作是无状态的应用服务器，其伸缩可以简单的使用负载均衡的手段实现。
MySQL中存储着数据，要想保证集群扩容后数据一致负载均衡，必须要做数据迁移，将集群中原来机器中的数据迁移到新添加的机器中。如下图所示：
具体迁移哪些数据可以利用一致性hash算法，尽可能使需要迁移的数据量最少。
但是迁移数据需要遍历数据库中每条记录(的索引)，重新进行路由计算确定其是否需要迁移，会对数据库访问造成一定压力。
实践中，Cobar利用了MySQL的数据同步功能进行数据迁移。数据迁移不是以数据为单位，而是以Schema为单位。
在Cobar集群初始化时，在每个MySQL实例创建多个Schema(根据业务远景规划未来集群规模，如集群最大规模为1000台数据库服务器，那么总的初始Schema数>=1000)。
集群扩容时，从每个服务器中迁移部分Schema到新的机器中，由于迁移以Schema为单位，迁移过程可以使用MySQL的同步机制，如下图所示：
