搭建高可用的Replication集群归档大量的冷数据

业务不断地在增长，集群分片中的数据也会随着时间的推移而增加，其中有相当一部分的数据是很少被使用的，例如几年前的订单记录、交易记录、商品评论等数据。这部分数据就称之为冷数据，与之相反经常被使用的数据则称之为热数据。我们都知道当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做负载均衡和双机热备：每台虚拟机的配置如下：
环境版本说明：之前说了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库，没有的话可以使用如下命令安装：在配置文件中添加jemalloc库文件所在路径的配置：完成配置文件的修改后，重启数据库服务：为了保证TokuDB的写入性能，我们需要调整一下Linux系统的大页内存管理的设置，命令如下：通过官方提供的yum仓库安装TokuDB引擎：接着使用ps-admin命令将TokuDB引擎安装到MySQL上：重启数据库服务：数据库重启完成后，再执行一次ps-admin命令以激活TokuDB引擎：最后使用show engines;语句验证一下MySQL上是否已成功安装了TokuDB引擎：
首先在两个节点上分别创建用于同步的数据库账户：然后修改MySQL配置文件：另外一个节点也是同样的配置，只不过server_id不能是一样的：修改完配置文件后，重启MySQL服务：进入node-B的MySQL命令行终端，分别执行如下语句：使用show slave statusG;语句查看主从同步状态，Slave_IO_Running和Slave_SQL_Running的值均为Yes才能表示主从同步状态是正常的：
为了实现双向同步，node-A和node-B需要互为主从关系，所以还需要配置node-A对node-B的主从关系。进入node-A的MySQL命令行终端，分别执行如下语句，注意这里的master_host需要为node-B的ip：同样配置完成后，使用show slave statusG;语句查看主从同步状态，Slave_IO_Running和Slave_SQL_Running的值均为Yes才能表示主从同步状态是正常的：
配置好两个节点的主从同步关系之后，我们就算是完成了Replication集群的搭建。接下来我们在任意一个节点创建一张归档表，看看两个节点之间是否能正常同步数据。具体的建表SQL如下：我这里是能够正常进行同步的，如图两个节点都能看到这张表：
到此为止，我们就完成了Replication集群的搭建及测试。接下来就是得让Replication集群具有高可用的特性，这就轮到Haproxy上场了。Haproxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件。使用Haproxy可以对MySQL集群进行负载均衡，赋予集群高可用性并发挥集群的性能。Haproxy由于是老牌的负载均衡组件了，所以CentOS的yum仓库中自带有该组件的安装包，安装起来就非常简单。安装命令如下：安装完成后，编辑Haproxy的配置文件，添加监控界面及需要代理的数据库节点配置：由于配置了3306端口用于TCP转发，以及4001作为Haproxy监控界面的访问端口，所以在防火墙上需要开放这两个端口：完成以上步骤后，启动Haproxy服务：然后使用浏览器访问Haproxy的监控界面，初次访问会要求输入用户名密码，这里的用户名密码就是配置文件中所配置的：
登录成功后，就会看到如下页面：
Haproxy的监控界面提供的监控信息也比较全面，在该界面下，我们可以看到每个主机的连接信息及其自身状态。当主机无法连接时，Status一栏会显示DOWN，并且背景色也会变为红色。正常状态下的值则为UP，背景色为绿色。另一个Haproxy节点也是使用以上的步骤进行安装和配置，这里就不再重复了。Haproxy服务搭建起来后，我们来使用远程工具测试一下能否通过Haproxy正常连接到数据库。如下：
连接成功后，在Haproxy上执行一些SQL语句，看看能否正常插入数据和查询数据：
我们搭建Haproxy是为了让Replication集群具备高可用的，所以最后测试一下Replication集群是否已具备有高可用性，首先将其中一个节点给停掉：此时，从Haproxy的监控界面中，可以看到node-B这个节点已经处于下线状态了：
现在集群中还剩一个节点，然后我们到Haproxy上执行一些SQL语句，看看是否还能正常插入数据和查询数据：
从测试结果可以看到，插入和查询语句依旧是能正常执行的。也就是说即便此时关掉一个节点整个数据库集群还能够正常使用，说明现在Replication集群是具有高可用性了。实现了Replication集群的高可用之后，我们还得实现Haproxy的高可用，因为Haproxy作为一个负责接收客户端请求，并将请求转发到后端数据库集群的入口，不可避免的需要具备高可用性。否则Haproxy出现单点故障，就无法访问被Haproxy代理的所有数据库集群节点了，这对整个系统的影响是十分巨大的。在同一时间只需要存在一个可用的Haproxy，否则客户端就不知道该连哪个Haproxy了。这也是为什么要采用Keepalived的虚拟IP的原因，这种机制能让多个节点互相接替时依旧使用同一个IP，客户端至始至终只需要连接这个虚拟IP。所以实现Haproxy的高可用就要轮到Keepalived出场了，在安装Keepalived之前需要开启防火墙的VRRP协议：然后就可以使用yum命令安装Keepalived了：安装完成后，编辑keepalived的配置文件：配置说明：完成以上配置后，启动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服务给关掉：然后再次执行执行一些语句测试能否正常插入、查询数据，如下能正常执行代表Haproxy节点已具有高可用性：
最后将所有的服务恢复成运行状态，验证停止的节点恢复之后数据是否是一致的。如下，我这里两个Replication节点的数据都是一致的：
到此为止，我们就完成了高可用Replication集群的搭建。接下来就是实践如何将大量的冷数据从PXC集群分片中剥离出来并归档到Replication集群中，我这里有两个PXC集群分片：
每个分片里都有一张t_purchase表，其建表SQL如下。每个分片合计共存储了100w条进货数据：
其中有60w条进货数据的采购日期都是2019-11-01之前的：
现在的需求是将2019-11-01之前的数据都剥离出来进行归档，这要如何实现呢？自己写代码肯定是比较麻烦的，好在Percona工具包里提供了一个用于归档数据的工具：pt-archiver，使用该工具可以很轻松的完成数据归档，免除了自己写归档程序的麻烦。pt-archiver主要有两个用途：想要使用pt-archiver首先得安装Percona工具包：安装完成后，验证pt-archiver命令是否可用：接着就可以使用pt-archiver命令进行数据的归档了，首先需要在Replication集群中创建一张归档表，表名以归档的数据日期为后缀，存储引擎使用TokuDB。具体的建表SQL如下：然后使用pt-archiver命令完成数据归档，如下示例：命令参数说明：等待大约15分钟左右数据就归档完成了，输出的统计信息如下：
此时在Replication集群上可以看到那60w数据都已经存储到了归档表中：
而原本的PXC集群中就只剩40w数据了：
如此一来我们就完成了冷热数据分离，并将大量的冷数据存储至指定的归档数据库中。

相关推荐: mysql关闭服务器的方法

小编给大家分享一下mysql关闭服务器的方法，希望大家阅读完这篇文章后大所收获，下面让我们一起去探讨吧！mysql关闭服务器的方法：1、在windows下，代码为【cd c:mysqlbin；mysqladmin -uroot shutdown】；2、在lin…