您好,登錄后才能下訂單哦!
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配置。
<table name="shard_auto" primaryKey="ID" type="global" dataNode="pxcNode11,pxcNode21,pxcNode31" rule="auto-sharding-long" />
需要去掉 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">
<!-- how many data nodes -->
<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="http://io.mycat/">
<!-- 定義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>
<!-- 定義MyCat的數據節點 -->
<dataNode name="pxcNode11" dataHost="dtHost" database="db1" />
<dataNode name="pxcNode21" dataHost="dtHost2" database="db1" />
<dataNode name="pxcNode31" dataHost="dtHost3" database="db1" />
<!-- 定義數據主機dtHost,連接到MySQL讀寫分離集群 ,schema中的每一個dataHost中的host屬性值必須唯一-->
<!-- dataHost實際上配置就是后臺的數據庫集群,一個datahost代表一個數據庫集群 -->
<!-- balance="1",全部的readHost與stand by writeHost參與select語句的負載均衡-->
<!-- writeType="0",所有寫操作發送到配置的第一個writeHost,這里就是我們的hostmaster,第一個掛了切到還生存的第二個writeHost-->
<dataHost name="dtHost" maxCon="500" minCon="20" balance="1"
writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
<!--心跳檢測 -->
<heartbeat>show slave status</heartbeat>
<!--配置后臺數據庫的IP地址和端口號,還有賬號密碼 -->
<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>
<!--配置后臺數據庫的IP地址和端口號,還有賬號密碼 -->
<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>
<!--配置后臺數據庫的IP地址和端口號,還有賬號密碼 -->
<writeHost host="hostMaster" url="192.168.163.128:33061" user="mycat_user" password="mycat" />
</dataHost>
</mycat:schema
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。