搭建高可用的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库，没有的话可以使用如下命令安装：

[[email protected] ~]# yum install -y jemalloc
[[email protected] ~]# ls /usr/lib64/ |grep jemalloc  # 库文件所在路径
libjemalloc.so.1
[[email protected] ~]#

在配置文件中添加jemalloc库文件所在路径的配置：

[[email protected] ~]# vim /etc/my.cnf
...

[mysql_safe]
malloc-lib=/usr/lib64/libjemalloc.so.1

完成配置文件的修改后，重启数据库服务：

[[email protected] ~]# systemctl restart mysqld

为了保证TokuDB的写入性能，我们需要调整一下Linux系统的大页内存管理的设置，命令如下：

# 采用动态分配内存而不是预先分配内存
[[email protected] ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 开启内存的碎片整理
[[email protected] ~]# echo never > /sys/kernel/mm/transparent_hugepage/defrag

通过官方提供的yum仓库安装TokuDB引擎：

[[email protected] ~]# yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
[[email protected] ~]# percona-release setup ps80
[[email protected] ~]# yum install -y percona-server-tokudb.x86_64

接着使用ps-admin命令将TokuDB引擎安装到MySQL上：

[[email protected] ~]# ps-admin --enable-tokudb -uroot -p

重启数据库服务：

[[email protected] ~]# systemctl restart mysqld

数据库重启完成后，再执行一次ps-admin命令以激活TokuDB引擎：

[[email protected] ~]# 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配置文件：

[[email protected] ~]# vim /etc/my.cnf
[mysqld]
# 设置节点的id
server_id=101
# 开启binlog
log_bin=mysql_bin
# 开启relay_log
relay_log=relay_bin

另外一个节点也是同样的配置，只不过server_id不能是一样的：

[[email protected] ~]# vim /etc/my.cnf
[mysqld]
server_id=102
log_bin=mysql_bin
relay_log=relay_bin

修改完配置文件后，重启MySQL服务：

[[email protected] ~]# systemctl restart mysqld
[[email protected] ~]# 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仓库中自带有该组件的安装包，安装起来就非常简单。安装命令如下：

[[email protected] ~]# yum install -y haproxy

安装完成后，编辑Haproxy的配置文件，添加监控界面及需要代理的数据库节点配置：

[[email protected] ~]# 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监控界面的访问端口，所以在防火墙上需要开放这两个端口：

[[email protected] ~]# firewall-cmd --zone=public --add-port=3306/tcp --permanent
[[email protected] ~]# firewall-cmd --zone=public --add-port=4001/tcp --permanent
[[email protected] ~]# firewall-cmd --reload

完成以上步骤后，启动Haproxy服务：

[[email protected] ~]# systemctl start haproxy

然后使用浏览器访问Haproxy的监控界面，初次访问会要求输入用户名密码，这里的用户名密码就是配置文件中所配置的：

登录成功后，就会看到如下页面：

Haproxy的监控界面提供的监控信息也比较全面，在该界面下，我们可以看到每个主机的连接信息及其自身状态。当主机无法连接时，Status一栏会显示DOWN，并且背景色也会变为红色。正常状态下的值则为UP，背景色为绿色。

另一个Haproxy节点也是使用以上的步骤进行安装和配置，这里就不再重复了。

测试Haproxy

Haproxy服务搭建起来后，我们来使用远程工具测试一下能否通过Haproxy正常连接到数据库。如下：

连接成功后，在Haproxy上执行一些SQL语句，看看能否正常插入数据和查询数据：

我们搭建Haproxy是为了让Replication集群具备高可用的，所以最后测试一下Replication集群是否已具备有高可用性，首先将其中一个节点给停掉：

[[email protected] ~]# 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协议：

[[email protected] ~]# firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --protocol vrrp -j ACCEPT
[[email protected] ~]# firewall-cmd --reload

然后就可以使用yum命令安装Keepalived了：

[[email protected] ~]# yum install -y keepalived

安装完成后，编辑keepalived的配置文件：

[[email protected] ~]# mv /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak  # 不使用自带的配置文件
[[email protected] ~]# 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服务：

[[email protected] ~]# 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服务给关掉：

[[email protected] ~]# systemctl stop keepalived
[[email protected] ~]# 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工具包：

[[email protected] ~]# yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
[[email protected] ~]# percona-release enable ps-80 release
[[email protected] ~]# yum install -y percona-toolkit

安装完成后，验证pt-archiver命令是否可用：

[[email protected] ~]# pt-archiver --version
pt-archiver 3.1.0
[[email protected] ~]#

接着就可以使用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命令完成数据归档，如下示例：

[[email protected] ~]# 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可以导出大量数据并归档存储，且简便易行

原文地址：https://blog.51cto.com/zero01/2468304

时间： 2024-10-08 19:23:03

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

Nginx+Keepalived搭建高可用负载均衡集群

Nginx+Keepalived搭建高可用负载均衡集群   一. 环境说明 前端双Nginx+keepalived,nginx反向代理到后端的tomcat集群实现负载均衡,Keepalived实现集群高可用. 操作系统: Centos 6.6_X64 Nginx版本: nginx-1.9.5 Keepalived版本:keepalived-1.2.13 结构: Keepalived+nginx-MASTER:10.6.1.210         Keepalived+nginx-BACKUP:

使用keepalived搭建高可用的LVS-DR集群

使用keepalived搭建高可用的LVS-DR集群   一:Keepalived服务概述 keepalived 是一个类似于 layer3, 4 & 5 交换机制的软件,也就是我们平时说的第 3 层.第 4 层和第 5层交换. Keepalived 的作用是检测 web 服务器的状态,如果有一台 web 服务器死机,戒工作出现故障,Keepalived 将检测到,并将有故障的 web 服务器从系统中剔除,当 web 服务器工作正常后 Keepalived 自劢将web 服务器加入到服务器群中,

使用Nginx1.9.9+Keepalived1.2.x搭建高可用负载均衡集群

一 简介以及原理介绍 (1)Nginx概念介绍: Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行.由俄罗斯的程序设计师Igor Sysoev所开发.其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:百度.京东.新浪.网易.腾讯.淘宝等 (2)Keepalived概念介绍: Keepalived的作用是检测服务器的状态,如果有一台we

搭建高可用mongodb shard 集群以及多节点备份

mongodb通过哪些机制实现路由.分片: 从图中可以看到有四个组件:mongos.config server.shard.replica set. mongos,数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发到对应的shard服务器上.在生产环境通常有多mongos作为请求的入口,防止其中一个挂掉所有的mongodb请求都没有办法操作. config server,顾名思义为配

搭建高可用的MongoDB集群副本集

什么是副本集呢?打魔兽世界总说打副本,其实这两个概念差不多一个意思.游戏里的副本是指玩家集中在高峰时间去一个场景打怪,会出现玩家暴多怪物少的情况,游戏开发商为了保证玩家的体验度,就为每一批玩家单独开放一个同样的空间同样的数量的怪物,这一个复制的场景就是一个副本,不管有多少个玩家各自在各自的副本里玩不会互相影响. mongoDB的副本也是这个,主从模式其实就是一个单副本的应用,没有很好的扩展性和容错性.而副本集具有多个副本保证了容错性,就算一个副本挂掉了还有很多副本存在,并且解决了上面第一个问题"

Windows 2012 系统搭建高可用故障转移集群

Windows 2012 系统搭建高可用故障转移集群 一.故障转移集群介绍 2 1.1 系统介绍 2 1.2 工作原理 2 二.实验目的 2 2.1 验证故障转移功能 2 2.2 验证高可用集群的可用性,以及支持的服务类型 2 三.实验原理 3 3.1 实验拓扑 3 3.2 实验环境设备 3 四.配置步骤 4 4.1 配置域服务器 4 4.2  iSCSI 虚拟存储配置 18 4.3 配置故障转移集群服务 45 4.4  验证集群 63 五.实验结果验证 68 5.1  验证故障转移 68 5.

MyCAT+MySQL 搭建高可用企业级数据库集群

第1章 课程介绍课程介绍1-1 MyCAT导学 试看1-2 课程介绍 第2章 MyCAT入门这一章中,我们将回顾了垂直切分,水平切分,分库分表等基础概念,然后快速回如何安装和启动MyCAT的,介绍如何以打包好的可执行程序的方式来启动MyCAT.以及如何对其相关的启动配置文件进行配置.2-1 章节综述2-2 什么是MyCAT2-3 什么是数据库中间层2-4 MyCAT的主要作用2-5 MyCAT基本元素2-6 MyCAT安装 第3章 MYCAT核心配置详解本章将对MyCAT的常用核心配置文件ser

Redis Cluster搭建高可用Redis服务器集群

原文:Redis Cluster搭建高可用Redis服务器集群 一.Redis Cluster集群简介 Redis Cluster是Redis官方提供的分布式解决方案,在3.0版本后推出的,有效地解决了Redis分布式的需求,当一个节点挂了可以快速的切换到另一个节点,当遇到单机内存.并发等瓶颈时,可以采用分布式方案要解决问题. 二.集群原理 Redis Cluster架构图 Redis Cluster集群采用了P2P的模式,完全去中心化,Redis把所有的Key分成了16384个slot,每个R

Hadoop搭建高可用的HA集群

一.工具准备 1.7台虚拟机(至少需要3台),本次搭建以7台为例,配好ip,关闭防火墙,修改主机名和IP的映射关系(/etc/hosts),关闭防火墙 2.安装JDK,配置环境变量 二.集群规划: 集群规划(7台): 主机名 IP 安装的软件 运行的进程 hadoop01 192.168.*.121 jdk.hadoop NameNode.DFSZKFailoverController(zkfc) hadoop02 192.168.*.122 jdk.hadoop NameNode.DFSZKF