溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
業務不斷地在增長，集群分片中的數據也會隨著時間的推移而增加，其中有相當一部分的數據是很少被使用的，例如幾年前的訂單記錄、交易記錄、商品評論等數據。這部分數據就稱之為冷數據，與之相反經常被使用的數據則稱之為熱數據。
我們都知道當MySQL的單表數據量超過兩千萬時，讀寫性能就會急劇下降。如果其中存儲的大部分都是高價值的熱數據還好說，可以花費資金去擴展集群分片，因為這些數據可以帶來收益。但如果是低價值的冷數據，就沒必要去花這個錢了。
所以我們要將冷數據從集群分片中剝離出來，存儲至專門的歸檔數據庫中，以騰出存儲空間、減輕集群分片的存儲壓力。讓集群分片盡量只存儲熱數據，維持一個較好的讀寫性能，而不必浪費存儲空間在冷數據上：
在歸檔數據庫上不適合使用InnoDB引擎，因為InnoDB的瞬時寫入性能不高。通常會采用Percona出品的TokuDB作為歸檔數據庫的存儲引擎。因為該引擎具有如下特點：
上一小節介紹了冷熱數據分離的概念，本小節我們來搭建一個用于歸檔冷數據的高可用Replication集群。雖然是歸檔庫，但也得讓其具有高可用性，畢竟在實際的企業中是不允許數據庫出現單點故障的。而且歸檔庫中的數據也不是不會被使用到，只不過是使用幾率不高而已。
本文中的Replication集群架構設計如下：
所謂Replication集群就是我們常說的主從架構，在Replication集群中，節點分為Master和Slave兩種角色。Master主要是提供寫服務，Slave則提供讀服務，并且通常Slave會被設置為read_only。
主從節點之間的數據同步是異步進行的，Slave使用一個線程監聽Master節點的binlog日志，當Master的binlog日志發生變化時，該線程就會讀取Master的binlog日志內容并寫入到本地的relay_log中。然后mysql進程會定時讀取relay_log并將數據寫入到本地的binlog文件，這樣就實現了主從之間的數據同步。如下圖所示：
為了保證Replication集群的高可用，我們需要讓兩個數據庫節點之間互為主從關系，實現雙向的數據同步。這樣才能在主節點掛掉時進行主從切換，否則主節點在恢復后不會向從節點同步數據，會導致節點之間的數據不一致：
接下來開始準備集群搭建的前置環境，首先需要創建4臺虛擬機，其中兩臺安裝Percona Server做Replication集群，兩臺安裝Haproxy和Keepalived做負載均衡和雙機熱備：
| 角色 | Host | IP |
|---|---|---|
| Haproxy+Keepalived | HA-01 | 192.168.190.135 |
| Haproxy+Keepalived | HA-02 | 192.168.190.143 |
| Percona Server | node-A | 192.168.190.142 |
| Percona Server | node-B | 192.168.190.131 |
每臺虛擬機的配置如下：
環境版本說明：
之前說了InnoDB因為其特性不適合作為歸檔數據庫的存儲引擎，而應采用TokuDB。TokuDB可以安裝在任意MySQL的衍生版本上，本文采用的是Percona Server這個MySQL衍生版作為演示。
我這里已經事先在192.168.190.142和192.168.190.131兩個虛擬機上安裝好了Percona Server，如不了解其安裝方式的話，可參考：安裝Percona Server數據庫（in CentOS 8）。接下來，我們就開始為Percona Server安裝TokuDB。
首先，在安裝TokuDB前確保系統中已有jemalloc庫，沒有的話可以使用如下命令安裝：
[root@node-A ~]# yum install -y jemalloc
[root@node-A ~]# ls /usr/lib64/ |grep jemalloc # 庫文件所在路徑
libjemalloc.so.1
[root@node-A ~]#在配置文件中添加jemalloc庫文件所在路徑的配置：
[root@node-A ~]# vim /etc/my.cnf
...
[mysql_safe]
malloc-lib=/usr/lib64/libjemalloc.so.1完成配置文件的修改后，重啟數據庫服務：
[root@node-A ~]# systemctl restart mysqld為了保證TokuDB的寫入性能，我們需要調整一下Linux系統的大頁內存管理的設置，命令如下：
# 采用動態分配內存而不是預先分配內存
[root@node-A ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 開啟內存的碎片整理
[root@node-A ~]# echo never > /sys/kernel/mm/transparent_hugepage/defrag通過官方提供的yum倉庫安裝TokuDB引擎：
[root@node-A ~]# yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
[root@node-A ~]# percona-release setup ps80
[root@node-A ~]# yum install -y percona-server-tokudb.x86_64接著使用ps-admin命令將TokuDB引擎安裝到MySQL上：
[root@node-A ~]# ps-admin --enable-tokudb -uroot -p重啟數據庫服務：
[root@node-A ~]# systemctl restart mysqld數據庫重啟完成后，再執行一次ps-admin命令以激活TokuDB引擎：
[root@node-A ~]# ps-admin --enable-tokudb -uroot -p最后使用show engines;語句驗證一下MySQL上是否已成功安裝了TokuDB引擎：
首先在兩個節點上分別創建用于同步的數據庫賬戶：
create user 'backup'@'%' identified by 'Abc_123456';
grant super, reload, replication slave on *.* to 'backup'@'%';
flush privileges;然后修改MySQL配置文件：
[root@node-A ~]# vim /etc/my.cnf
[mysqld]
# 設置節點的id
server_id=101
# 開啟binlog
log_bin=mysql_bin
# 開啟relay_log
relay_log=relay_bin另外一個節點也是同樣的配置，只不過server_id不能是一樣的：
[root@node-B ~]# vim /etc/my.cnf
[mysqld]
server_id=102
log_bin=mysql_bin
relay_log=relay_bin修改完配置文件后，重啟MySQL服務：
[root@node-A ~]# systemctl restart mysqld
[root@node-B ~]# systemctl restart mysqldnode-B對node-A的主從關系進入node-B的MySQL命令行終端，分別執行如下語句：
mysql> stop slave; -- 停止主從同步
mysql> change master to master_host='192.168.190.142', master_port=3306, master_user='backup', master_password='Abc_123456'; -- 配置Master節點的連接信息
mysql> start slave; -- 啟動主從同步使用show slave status\G;語句查看主從同步狀態，Slave_IO_Running和Slave_SQL_Running的值均為Yes才能表示主從同步狀態是正常的：
node-A對node-B的主從關系為了實現雙向同步，node-A和node-B需要互為主從關系，所以還需要配置node-A對node-B的主從關系。進入node-A的MySQL命令行終端，分別執行如下語句，注意這里的master_host需要為node-B的ip：
mysql> stop slave; -- 停止主從同步
mysql> change master to master_host='192.168.190.131', master_port=3306, master_user='backup', master_password='Abc_123456'; -- 配置Master節點的連接信息
mysql> start slave; -- 啟動主從同步同樣配置完成后，使用show slave status\G;語句查看主從同步狀態，Slave_IO_Running和Slave_SQL_Running的值均為Yes才能表示主從同步狀態是正常的：
配置好兩個節點的主從同步關系之后，我們就算是完成了Replication集群的搭建。接下來我們在任意一個節點創建一張歸檔表，看看兩個節點之間是否能正常同步數據。具體的建表SQL如下：
create table t_purchase_201909 (
id int unsigned primary key,
purchase_price decimal(10, 2) not null comment '進貨價格',
purchase_num int unsigned not null comment '進貨數量',
purchase_sum decimal(10, 2) not null comment '進貨總價',
purchase_buyer int unsigned not null comment '采購者',
purchase_date timestamp not null default current_timestamp comment '采購日期',
company_id int unsigned not null comment '進貨企業的id',
goods_id int unsigned not null comment '商品id',
key idx_company_id(company_id),
key idx_goods_id(goods_id)
) engine=TokuDB comment '2019年9月的進貨數據歸檔表';我這里是能夠正常進行同步的，如圖兩個節點都能看到這張表：
到此為止，我們就完成了Replication集群的搭建及測試。接下來就是得讓Replication集群具有高可用的特性，這就輪到Haproxy上場了。Haproxy是一款提供高可用性、負載均衡以及基于TCP（第四層）和HTTP（第七層）應用的代理軟件。使用Haproxy可以對MySQL集群進行負載均衡，賦予集群高可用性并發揮集群的性能。
Haproxy由于是老牌的負載均衡組件了，所以CentOS的yum倉庫中自帶有該組件的安裝包，安裝起來就非常簡單。安裝命令如下：
[root@HA-01 ~]# yum install -y haproxy安裝完成后，編輯Haproxy的配置文件，添加監控界面及需要代理的數據庫節點配置：
[root@HA-01 ~]# vim /etc/haproxy/haproxy.cfg
# 在文件的末尾添加如下配置項
# 監控界面配置
listen admin_stats
# 綁定的ip及監聽的端口
bind 0.0.0.0:4001
# 訪問協議
mode http
# URI 相對地址
stats uri /dbs
# 統計報告格式
stats realm Global\ statistics
# 用于登錄監控界面的賬戶密碼
stats auth admin:abc123456
# 數據庫負載均衡配置
listen proxy-mysql
# 綁定的ip及監聽的端口
bind 0.0.0.0:3306
# 訪問協議
mode tcp
# 負載均衡算法
# roundrobin：輪詢
# static-rr：權重
# leastconn：最少連接
# source：請求源ip
balance roundrobin
# 日志格式
option tcplog
# 需要被負載均衡的主機
server node-A 192.168.190.142:3306 check port 3306 weight 1 maxconn 2000
server node-B 192.168.190.131:3306 check port 3306 weight 1 maxconn 2000
# 使用keepalive檢測死鏈
option tcpka由于配置了3306端口用于TCP轉發，以及4001作為Haproxy監控界面的訪問端口，所以在防火墻上需要開放這兩個端口：
[root@HA-01 ~]# firewall-cmd --zone=public --add-port=3306/tcp --permanent
[root@HA-01 ~]# firewall-cmd --zone=public --add-port=4001/tcp --permanent
[root@HA-01 ~]# firewall-cmd --reload完成以上步驟后，啟動Haproxy服務：
[root@HA-01 ~]# systemctl start haproxy然后使用瀏覽器訪問Haproxy的監控界面，初次訪問會要求輸入用戶名密碼，這里的用戶名密碼就是配置文件中所配置的：
登錄成功后，就會看到如下頁面：
Haproxy的監控界面提供的監控信息也比較全面，在該界面下，我們可以看到每個主機的連接信息及其自身狀態。當主機無法連接時，Status一欄會顯示DOWN，并且背景色也會變為紅色。正常狀態下的值則為UP，背景色為綠色。
另一個Haproxy節點也是使用以上的步驟進行安裝和配置，這里就不再重復了。
Haproxy服務搭建起來后，我們來使用遠程工具測試一下能否通過Haproxy正常連接到數據庫。如下：
連接成功后，在Haproxy上執行一些SQL語句，看看能否正常插入數據和查詢數據：
我們搭建Haproxy是為了讓Replication集群具備高可用的，所以最后測試一下Replication集群是否已具備有高可用性，首先將其中一個節點給停掉：
[root@node-B ~]# systemctl stop mysqld此時，從Haproxy的監控界面中，可以看到node-B這個節點已經處于下線狀態了：
現在集群中還剩一個節點，然后我們到Haproxy上執行一些SQL語句，看看是否還能正常插入數據和查詢數據：
從測試結果可以看到，插入和查詢語句依舊是能正常執行的。也就是說即便此時關掉一個節點整個數據庫集群還能夠正常使用，說明現在Replication集群是具有高可用性了。
實現了Replication集群的高可用之后，我們還得實現Haproxy的高可用，因為Haproxy作為一個負責接收客戶端請求，并將請求轉發到后端數據庫集群的入口，不可避免的需要具備高可用性。否則Haproxy出現單點故障，就無法訪問被Haproxy代理的所有數據庫集群節點了，這對整個系統的影響是十分巨大的。
在同一時間只需要存在一個可用的Haproxy，否則客戶端就不知道該連哪個Haproxy了。這也是為什么要采用Keepalived的虛擬IP的原因，這種機制能讓多個節點互相接替時依舊使用同一個IP，客戶端至始至終只需要連接這個虛擬IP。所以實現Haproxy的高可用就要輪到Keepalived出場了，在安裝Keepalived之前需要開啟防火墻的VRRP協議：
[root@HA-01 ~]# firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --protocol vrrp -j ACCEPT
[root@HA-01 ~]# firewall-cmd --reload然后就可以使用yum命令安裝Keepalived了：
[root@HA-01 ~]# yum install -y keepalived安裝完成后，編輯keepalived的配置文件：
[root@HA-01 ~]# mv /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak # 不使用自帶的配置文件
[root@HA-01 ~]# vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
state MASTER
interface ens32
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.190.101
}
}配置說明：
state MASTER：定義節點角色為master，當角色為master時，該節點無需爭搶就能獲取到VIP。集群內允許有多個master，當存在多個master時，master之間就需要爭搶VIP。為其他角色時，只有master下線才能獲取到VIPinterface ens32：定義可用于外部通信的網卡名稱，網卡名稱可以通過ip addr命令查看virtual_router_id 51：定義虛擬路由的id，取值在0-255，每個節點的值需要唯一，也就是不能配置成一樣的priority 100：定義權重，權重越高就越優先獲取到VIPadvert_int 1：定義檢測間隔時間為1秒authentication：定義心跳檢查時所使用的認證信息
auth_type PASS：定義認證類型為密碼auth_pass 123456：定義具體的密碼virtual_ipaddress：定義虛擬IP（VIP），需要為同一網段下的IP，并且每個節點需要一致完成以上配置后，啟動keepalived服務：
[root@HA-01 ~]# systemctl start keepalived當keepalived服務啟動成功，使用ip addr命令可以查看到網卡綁定的虛擬IP：
另一個節點也是使用以上的步驟進行安裝和配置，這里就不再重復了。不過要注意virtual_router_id不能配置成一樣的，而virtual_ipaddress則必須配置成同一個虛擬ip。
以上我們完成了Keepalived的安裝與配置，最后我們來測試Keepalived服務是否正常可用，以及測試Haproxy是否已具有高可用性。
首先，在其他節點上測試虛擬IP能否正常ping通，如果不能ping通就需要檢查配置了。如圖，我這里是能正常ping通的：
常見的虛擬IP ping不通的情況：
確認能夠從外部ping通Keepalived的虛擬IP后，使用Navicat測試能否通過虛擬IP連接到數據庫：
連接成功后，執行一些語句測試能否正常插入、查詢數據：
到此就基本沒什么問題了，最后測試一下Haproxy的高可用性，將其中一個Haproxy節點上的Keepalived和Haproxy服務給關掉：
[root@HA-01 ~]# systemctl stop keepalived
[root@HA-01 ~]# systemctl stop haproxy然后再次執行執行一些語句測試能否正常插入、查詢數據，如下能正常執行代表Haproxy節點已具有高可用性：
最后將所有的服務恢復成運行狀態，驗證停止的節點恢復之后數據是否是一致的。如下，我這里兩個Replication節點的數據都是一致的：
到此為止，我們就完成了高可用Replication集群的搭建。接下來就是實踐如何將大量的冷數據從PXC集群分片中剝離出來并歸檔到Replication集群中，我這里有兩個PXC集群分片：
每個分片里都有一張t_purchase表，其建表SQL如下。
create table t_purchase (
id int unsigned primary key,
purchase_price decimal(10, 2) not null comment '進貨價格',
purchase_num int unsigned not null comment '進貨數量',
purchase_sum decimal(10, 2) not null comment '進貨總價',
purchase_buyer int unsigned not null comment '采購者',
purchase_date timestamp not null default current_timestamp comment '采購日期',
company_id int unsigned not null comment '進貨企業的id',
goods_id int unsigned not null comment '商品id',
key idx_company_id(company_id),
key idx_goods_id(goods_id)
) comment '進貨表';每個分片合計共存儲了100w條進貨數據：
其中有60w條進貨數據的采購日期都是2019-11-01之前的：
現在的需求是將2019-11-01之前的數據都剝離出來進行歸檔，這要如何實現呢？自己寫代碼肯定是比較麻煩的，好在Percona工具包里提供了一個用于歸檔數據的工具：pt-archiver，使用該工具可以很輕松的完成數據歸檔，免除了自己寫歸檔程序的麻煩。pt-archiver主要有兩個用途：
想要使用pt-archiver首先得安裝Percona工具包：
[root@node-A ~]# yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
[root@node-A ~]# percona-release enable ps-80 release
[root@node-A ~]# yum install -y percona-toolkit安裝完成后，驗證pt-archiver命令是否可用：
[root@node-A ~]# pt-archiver --version
pt-archiver 3.1.0
[root@node-A ~]# 接著就可以使用pt-archiver命令進行數據的歸檔了，首先需要在Replication集群中創建一張歸檔表，表名以歸檔的數據日期為后綴，存儲引擎使用TokuDB。具體的建表SQL如下：
create table t_purchase_201910 (
id int unsigned primary key,
purchase_price decimal(10, 2) not null comment '進貨價格',
purchase_num int unsigned not null comment '進貨數量',
purchase_sum decimal(10, 2) not null comment '進貨總價',
purchase_buyer int unsigned not null comment '采購者',
purchase_date timestamp not null default current_timestamp comment '采購日期',
company_id int unsigned not null comment '進貨企業的id',
goods_id int unsigned not null comment '商品id',
key idx_company_id(company_id),
key idx_goods_id(goods_id)
) engine=TokuDB comment '2019年10月的進貨數據歸檔表';然后使用pt-archiver命令完成數據歸檔，如下示例：
[root@node-A ~]# pt-archiver --source h=192.168.190.100,P=3306,u=admin,p=Abc_123456,D=test,t=t_purchase --dest h=192.168.190.101,P=3306,u=archive,p=Abc_123456,D=test,t=t_purchase_201910 --no-check-charset --where 'purchase_date < "2019-11-01 0:0:0"' --progress 50000 --bulk-delete --bulk-insert --limit=100000 --statisticspt-archiver命令是使用load data語句進行數據導入的，所以要確保MySQL開啟了local_infile。如果沒有開啟的話歸檔數據會失敗，可以使用set global local_infile = 'ON';語句來開啟local_infile。命令參數說明：
--source：指定從哪個數據庫讀取數據--dest：指定將數據歸檔至哪個數據庫--no-check-charset：不檢查數據的字符集--where：指定將哪些數據進行歸檔，在本例中就是將2019-09-11之前的數據進行歸檔--progress：指定當歸檔完多少條數據時打印一次狀態信息--bulk-delete：指定批量刪除歸檔數據。數據的刪除有事務保證，不會出現未歸檔成功就將數據刪除了的情況--bulk-insert：指定批量寫入歸檔數據--limit：指定每次歸檔多少條數據--statistics：歸檔數據完成后打印統計信息等待大約15分鐘左右數據就歸檔完成了，輸出的統計信息如下：
此時在Replication集群上可以看到那60w數據都已經存儲到了歸檔表中：
而原本的PXC集群中就只剩40w數據了：
如此一來我們就完成了冷熱數據分離，并將大量的冷數據存儲至指定的歸檔數據庫中。
pt-archiver可以導出大量數據并歸檔存儲，且簡便易行免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
