搭建高可用的Replication集羣歸檔大量的冷數據

冷熱數據分離

業務不斷地在增長，集羣分片中的數據也會隨着時間的推移而增加，其中有相當一部分的數據是很少被使用的，例如幾年前的訂單記錄、交易記錄、商品評論等數據。這部分數據就稱之爲冷數據，與之相反經常被使用的數據則稱之爲熱數據。

我們都知道當MySQL的單表數據量超過兩千萬時，讀寫性能就會急劇下降。如果其中存儲的大部分都是高價值的熱數據還好說，可以花費資金去擴展集羣分片，因爲這些數據可以帶來收益。但如果是低價值的冷數據，就沒必要去花這個錢了。

所以我們要將冷數據從集羣分片中剝離出來，存儲至專門的歸檔數據庫中，以騰出存儲空間、減輕集羣分片的存儲壓力。讓集羣分片儘量只存儲熱數據，維持一個較好的讀寫性能，而不必浪費存儲空間在冷數據上：

在歸檔數據庫上不適合使用InnoDB引擎，因爲InnoDB的瞬時寫入性能不高。通常會採用Percona出品的TokuDB作爲歸檔數據庫的存儲引擎。因爲該引擎具有如下特點：

高壓縮比，高寫入性能
可以在線創建索引和字段
支持事務特性
支持主從同步

搭建Replication集羣

上一小節介紹了冷熱數據分離的概念，本小節我們來搭建一個用於歸檔冷數據的高可用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

每臺虛擬機的配置如下：

環境版本說明：

操作系統：CentOS 8
Percona Server：8.0.18
TokuDB：8.0.18
Haproxy：1.8.15-5.el8
Keepalived：2.0.10-4.el8_0.2

安裝TokuDB

之前說了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;

Tips：創建好賬戶後，需要使用該賬戶在兩個節點互相登錄一下，以確保賬戶是可用的

然後修改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 mysqld

配置`node-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月的進貨數據歸檔表';

我這裏是能夠正常進行同步的，如圖兩個節點都能看到這張表：

安裝Haproxy

到此爲止，我們就完成了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正常連接到數據庫。如下：

連接成功後，在Haproxy上執行一些SQL語句，看看能否正常插入數據和查詢數據：

我們搭建Haproxy是爲了讓Replication集羣具備高可用的，所以最後測試一下Replication集羣是否已具備有高可用性，首先將其中一個節點給停掉：

[root@node-B ~]# systemctl stop mysqld

此時，從Haproxy的監控界面中，可以看到node-B這個節點已經處於下線狀態了：

現在集羣中還剩一個節點，然後我們到Haproxy上執行一些SQL語句，看看是否還能正常插入數據和查詢數據：

從測試結果可以看到，插入和查詢語句依舊是能正常執行的。也就是說即便此時關掉一個節點整個數據庫集羣還能夠正常使用，說明現在Replication集羣是具有高可用性了。

利用Keepalived實現Haproxy的高可用

實現了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下線才能獲取到VIP
interface ens32：定義可用於外部通信的網卡名稱，網卡名稱可以通過ip addr命令查看
virtual_router_id 51：定義虛擬路由的id，取值在0-255，每個節點的值需要唯一，也就是不能配置成一樣的
priority 100：定義權重，權重越高就越優先獲取到VIP
advert_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的安裝與配置，最後我們來測試Keepalived服務是否正常可用，以及測試Haproxy是否已具有高可用性。

首先，在其他節點上測試虛擬IP能否正常ping通，如果不能ping通就需要檢查配置了。如圖，我這裏是能正常ping通的：

常見的虛擬IP ping不通的情況：

防火牆配置有誤，沒有正確開啓VRRP協議
配置的虛擬IP與其他節點的IP不處於同一網段
Keepalived配置有誤，或Keepalived根本沒啓動成功

確認能夠從外部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集羣分片：

關於PXC集羣的內容可以參考另一篇文章：爲PXC集羣引入Mycat並構建完整的高可用集羣架構

每個分片裏都有一張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 --statistics

Tips：pt-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數據了：

如此一來我們就完成了冷熱數據分離，並將大量的冷數據存儲至指定的歸檔數據庫中。

總結

將冷熱數據分離，低價值的冷數據存儲至歸檔庫，維持熱數據的讀寫效率
使用TokuDB引擎保存歸檔數據，擁有高速寫入特性
使用雙機熱備方案搭建歸檔庫，具備高可用性
使用pt-archiver可以導出大量數據並歸檔存儲，且簡便易行

搭建高可用的Replication集羣歸檔大量的冷數據

冷熱數據分離

搭建Replication集羣

準備工作

安裝TokuDB

配置主從關係

配置`node-B`對`node-A`的主從關係

配置`node-A`對`node-B`的主從關係

測試主從同步

安裝Haproxy

測試Haproxy

利用Keepalived實現Haproxy的高可用

測試Keepalived

實踐數據歸檔

總結

如何使用 JS 判斷用戶是否處於活躍狀態

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

Kafka核心API——Consumer消費者

Kafka核心API——Stream API

Kafka核心API——AdminClient API

Kafka的安裝與配置

CentOS8更換yum源後出現同步倉庫緩存失敗的問題

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

搭建高可用的Replication集羣歸檔大量的冷數據

冷熱數據分離

搭建Replication集羣

準備工作

安裝TokuDB

配置主從關係

配置node-B對node-A的主從關係

配置node-A對node-B的主從關係

測試主從同步

安裝Haproxy

測試Haproxy

利用Keepalived實現Haproxy的高可用

測試Keepalived

實踐數據歸檔

總結

配置`node-B`對`node-A`的主從關係

配置`node-A`對`node-B`的主從關係