MySQL的使用場景中，讀寫分離只是方案中的一部分，想要擴充套件，勢必會用到分庫分表，可喜的是Mycat裡已經做到了，今天花時間測試了一下，感覺還不錯。

關於分庫分表

當然自己也理了一下，分庫分表的這些內容，如果分成幾個策略或者階段，大概有下面的幾種。

最上面的第一種是直接拆表，比如資料庫db1下面有test1,test2,test3三個表，透過中介軟體看到的還是表test,裡面的資料做了這樣的拆分，能夠咋一定程度上分解壓力，如果細細品來，和分割槽表的套路有些像。

接下來的幾類也是不斷完善，把表test拆解到多個庫中，多個伺服器中，如果做了讀寫分離，全套的方案這樣的拆解改進還是很大的。如此來看，資料庫中介軟體做了很多應用和資料庫之間的很多事情，能夠流行起來除了技術原因還是有很多其他的因素。

分庫分表的測試環境模擬

如果要在一臺伺服器上測試分庫分表，而且要求架構方案要全面，作為技術可行性的一個判定參考，是否可以實現呢。

如果模擬一主兩從的架構，模擬服務分佈在3臺伺服器上，這樣的方案需要建立9個例項,每個例項上有3個db需要分別拆分。

大體的配置如下：

master1: 埠33091

(m1)slave1: 埠33092

(m1)slave2: 埠33093

master2: 埠33071

(m2)slave1: 埠33072

(m2)slave2: 埠33073

master3: 埠33061

(m3)slave1: 埠33062

(m3)slave2: 埠33063

畫個圖來說明一下，其中db1,db2,db3下面有若個表，需要做sharding

所以我們需要模擬的就是這個事情。

使用Mycat碰到的幾個小問題解惑

使用Mycat的時候碰到了幾個小問題，感覺比較有代表性，記錄了一下。

問題1：

手下是使用Mycat連線到資料庫之後，如果不切換到具體的資料庫下，使用[資料庫名].[表名]的方式會丟擲下面的錯誤，可見整個過程中，Mycat攔截了SQL資訊做了過濾，在轉換的時候找不到目標路由。當然實際使用中，規範使用肯定不會有這個問題。

mysql> select * from db1.shard_auto;
ERROR 1064 (HY000): find no Route:select * from db1.shard_auto
問題2：
在配置了sharding策略之後，insert語句丟擲了下面的錯誤，這個是對語法的一個基本的要求。
mysql> insert into shard_mod_long values(1,'aa',date);
ERROR 1064 (HY000): partition table, insert must provide ColumnList
問題3：

如果sharding策略配置有誤，很可能出現表訪問正常，但是DML會有問題，提示資料衝突了。至於如何配置sharding,下面會講。
mysql> select *from shard_mod_long;
Empty set (0.00 sec)

mysql> insert into shard_mod_long(ID,name,shard_date) values(1,'aa',current_date);
ERROR 1105 (HY000): Duplicate entry '1' for key 'PRIMARY'
問題4：
如果sharding的配置有誤，很可能出現多份冗餘資料。

檢視執行計劃就一目瞭然，透過data_node可以看到資料指向了多個目標庫。

mysql> explain insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode11 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
| pxcNode21 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
| pxcNode31 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
+-----------+------------------------------------------------+

這種情況如果有一定的需求還是蠻不錯的，做sharding可惜了。問題就在於下面的這個table配置。

需要去掉 type="global"的屬性，讓它sharding。

Mycat裡面的sharding策略

Mycat的分片策略很豐富，這個是超出自己的預期的，也是Mycat的一大亮點。

大體分片規則如下，另外還有一些其他分片方式這裡不全部列舉：
（1）分片列舉：sharding-by-intfile
（2）主鍵範圍：auto-sharding-long
（3）一致性hash：sharding-by-murmur
（4）字串hash解析：sharding-by-stringhash
（5）按日期（天）分片：sharding-by-date
（6）按單月小時拆分：sharding-by-hour
（7）自然月分片：sharding-by-month

在開始之前，我們要建立下面的表來模擬幾個sharding的場景,表名根據需求可以改變。
create table shard_test(ID int primary key, name varchar(20),shard_date date);

主鍵範圍分片

主鍵範圍分片是參考了主鍵值，按照主鍵值的分佈來分佈資料庫在不同的庫中，我們現在對應的sharding節點上建立同樣的表結構。

關於sharding的策略，需要修改rule.xml檔案。

常用的sharding策略已經在Mycat裡面實現了，如果要自行實現也可以定製。比如下面的規則，是基於主鍵欄位ID來做sharding,分佈的演算法是rang-long,引用了function rang-long,這個function是在對應的一個Java類中實現的。

        <tableRule name="auto-sharding-long">
                <rule>
                        <columns>ID</columns>
                        <algorithm>rang-long</algorithm>
                </rule>

        <function name="rang-long"
                class="io.mycat.route.function.AutoPartitionByLong">
                <property name="mapFile">autopartition-long.txt</property>
當然主鍵的範圍是不固定的，可以根據需求來定製，比如按照一百萬為單位，或者1000位單位，檔案是 autopartition-long.txt 檔案的內容預設如下，模板裡是分為了3個分片，如果要定製更多的就需要繼續配置了，目前來看這個配置只能夠承載15億的資料量，可以根據需求繼續擴充套件定制。
# range start-end ,data node index
# K=1000,M=10000.
0-500M=0
500M-1000M=1
1000M-1500M=2

插入一些資料來驗證一下，我們可以檢視執行計劃來做基本的驗證，配置無誤，資料就根據規則流向了指定的資料庫下的表裡。

mysql> explain insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode11 | insert into shard_auto(ID,name,shard_date) values(1,'aa',current_date) |
+-----------+------------------------------------------------+

還有一個檢視sharding效果的小方法，比如我插入一個極大的值，保證和其他資料不在一個分片上，我們執行查詢語句兩次，結果會有點變化。

sharing的效果
mysql> select *from shard_auto;
+---------+------+------------+
| ID      | name | shard_date |
+---------+------+------------+
|       1 | aa   | 2017-09-06 |
|       2 | bb   | 2017-09-06 |
| 5000001 | aa   | 2017-09-06 |
+---------+------+------------+
3 rows in set (0.00 sec)
稍作停頓，繼續執行。
mysql> select *from shard_auto;
+---------+------+------------+
| ID      | name | shard_date |
+---------+------+------------+
| 5000001 | aa   | 2017-09-06 |
|       1 | aa   | 2017-09-06 |
|       2 | bb   | 2017-09-06 |
+---------+------+------------+
3 rows in set (0.01 sec)

Hash分片

Hash分片其實企業級應用尤其廣泛，我覺得很的一個原因是透過這種資料路由的方式，得到的資料情況是基本可控的，和業務的關聯起來比較直接。很多拆分方法都是根據mod方法來平均分佈資料。

sharding的策略在rule.xml裡面配置，還是預設的mod-long規則，引用了演算法mod-long,這裡是根據sharding的節點數來做的，預設是3個。

<tableRule name="mod-long">
                <rule>
                        <columns>id</columns>
                        <algorithm>mod-long</algorithm>
                </rule>
        </tableRule>

        <function name="mod-long" class="io.mycat.route.function.PartitionByMod">
                
                <property name="count">3</property>
        </function>
比如檢視兩次insert的結果情況。

mysql> explain insert into shard_mod_long(ID,name,shard_date) values(4,'dd',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode22 | insert into shard_mod_long(ID,name,shard_date) values(4,'dd',current_date) |
+-----------+------------------------------------------------+

mysql> explain insert into shard_mod_long(ID,name,shard_date) values(5,'ee',current_date);
+-----------+------------------------------------------------+
| DATA_NODE | SQL |
+-----------+------------------------------------------------+
| pxcNode23 | insert into shard_mod_long(ID,name,shard_date) values(5,'ee',current_date) |
+-----------+------------------------------------------------+
可以看到資料還是遵循了節點的規律，平均分佈。

至於schema.xml的配置，是整個分庫的核心，我索性也給出一個配置來，供參考。

<?xml version="1.0"?>
    <!DOCTYPE mycat:schema SYSTEM "schema.dtd">
    <mycat:schema xmlns:mycat="">

        
        <schema name="db1" checkSQLschema="false" sqlMaxLimit="100" >
        <table name="shard_mod_long" primaryKey="ID" type="global" dataNode="pxcNode11,pxcNode21,pxcNode31" rule="mod-long" />
        <table name="shard_auto" primaryKey="ID" type="global" dataNode="pxcNode11,pxcNode21,pxcNode31" rule="auto-sharding-long" />
        </schema>

        
        <dataNode name="pxcNode11" dataHost="dtHost" database="db1" />
        <dataNode name="pxcNode21" dataHost="dtHost2" database="db1" />
        <dataNode name="pxcNode31" dataHost="dtHost3" database="db1" />

        
        
        
        
        <dataHost name="dtHost" maxCon="500" minCon="20" balance="1"
            writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
            
            <heartbeat>show slave status</heartbeat>
            
            <writeHost host="hostMaster" url="192.168.163.128:33091" user="mycat_user" password="mycat" />
        </dataHost>
         <dataHost name="dtHost2" maxCon="500" minCon="20" balance="1"
            writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
            
            <heartbeat>show slave status</heartbeat>
            
            <writeHost host="hostMaster" url="192.168.163.128:33071" user="mycat_user" password="mycat" />
        </dataHost>
        <dataHost name="dtHost3" maxCon="500" minCon="20" balance="1"
            writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
            
            <heartbeat>show slave status</heartbeat>
            
            <writeHost host="hostMaster" url="192.168.163.128:33061" user="mycat_user" password="mycat" />
        </dataHost>
</mycat:schema

Mycat分庫分表的簡單實踐

相關文章