关于java:5大主流方案对比MySQL千亿级数据线上平滑扩容实战

大家好，我是不才陈某~

在我的项目初期，咱们部署了三个数据库A、B、C，此时数据库的规模能够满足咱们的业务需要。为了将数据做到平均分配，咱们在Service服务层应用uid%3进行取模分片，从而将数据平均分配到三个数据库中。

关注公众号：码猿技术专栏，回复关键词：1111 获取阿里外部Java性能优化手册！

如图所示：

前期随着用户量的减少，用户产生的数据信息被源源不断的增加到数据库中，最终达到数据库的最佳存储容量。如果此时持续向数据库中新增数据，会导致数据库的CRUD等基本操作变慢，进而影响整个服务的响应速度。

这时，咱们须要减少新的节点，对数据库进行程度扩容，那么退出新的数据库D后，数据库的规模由原来的3个变为4个。

如图所示：

此时因为分片规定产生了变动（uid%3 变为uid%4），导致大部分的数据，无奈命中原有的数据，须要从新进行调配，要做大量的数据迁徙解决。

比方之前uid如果是uid=3取模3%3=0，是调配在A库上，新退出D库后， uid=3取模3%4=3，调配在D库上；

新增一个节点，大略会有90%的数据须要迁徙，这样会面临大量的数据压力，并且对服务造成极大的不稳定性。

1. 五个计划

1.1 停机计划

发布公告：为了进行数据的从新拆分，在进行服务之前，咱们须要提前告诉用户，比方：咱们的服务会在yyyy-MM-dd进行降级，给您带来的不便敬请体谅。
进行服务：敞开Service
离线数据迁徙（拆分，重新分配数据）：将旧库中的数据依照Service层的算法，将数据拆分，重新分配数据
数据校验：开发定制一个程序对旧库和新库中的数据进行校验，比对
更改配置：批改Service层的配置算法，也就是将原来的uid%3变为uid%4
复原服务：重启Service服务
回滚预案：针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁徙，复原服务等）执行失败，立即进行回滚，从新再来

进行服务之后，可能保障迁徙工作的失常进行，然而服务进行，挫伤用户体验，并造成了工夫压力，必须在指定的工夫内实现迁徙。

1.2 停写计划

反对读写拆散：数据库反对读写拆散，在扩容之前，每个数据库都提供了读写性能，数据重新分配的过程中，将每个数据库设置为只读状态，敞开写的性能
降级布告：为了进行数据的从新拆分，在停写之前，咱们须要提前告诉用户，比方：咱们的服务会在yyyy-MM-dd进行降级，给您带来的不便敬请体谅。
中断写操作，隔离写数据源（或拦挡返回对立提醒）：在Service层对所有的写申请进行拦挡，对立返回提示信息，如：服务正在降级中，只对外提供读服务
数据同步解决：将旧库中的数据依照Service层的算法，将数据重新分配，迁徙（复制数据）
数据校验：开发定制一个程序对旧库中的数据进行备份，应用备份的数据和重新分配后的数据进行校验，比对
更改配置：通过配置核心，批改Service层的配置算法，也就是将原来的uid%3变为uid%4，这个过程不须要重启服务
复原写操作：设置数据库复原读写性能，去除Service层的拦挡提醒
数据清理：应用delete语句对冗余数据进行删除
回滚预案：针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁徙等）执行失败，立即进行回滚，从新再来

毛病：在数据的复制过程须要耗费大量的工夫，停写工夫太长，数据须要先复制，再清理冗余数据

1.3 日志计划

外围是通过日志进行数据库的同步迁徙，次要操作步骤如下：

1、数据迁徙之前，业务利用拜访旧的数据库节点。

2、日志记录

在降级之前，记录“对旧数据库上的数据批改”的日志（这里批改包含增、删、改），这个日志不须要记录具体的数据信息，次要记录：

（1）批改的库；

（2）批改的表；

（3）批改的惟一主键；

（4）批改操作类型。

日志记录不必关注新增了哪些信息，批改的数据格式，只须要记录以上数据信息，这样日志格局是固定的，这样能保障计划的通用性。

服务降级日志记录性能危险较小：

写和批改接口是多数，改变点少；
降级只是减少了一些日志，采纳异步形式实现，对业务性能没有太多影响。

3、数据迁徙：

研发定制数据迁徙工具，作用是把旧库中的数据迁徙至新库中。

整个过程依然采纳旧库进行对外服务。
数据同步工具实现复杂度不高。
只对旧库进行读取操作，如果同步呈现问题，都能够对新库进行回滚操作。
能够限速或分批迁徙执行，不会有工夫压力。

数据迁徙实现之后，并不能切换至新库提供服务。

因为旧库仍然对线上提供服务，库中的数据随时会发生变化，但这些变动的数据并没有同步到新库中，旧库和新库数据不统一，所以不能间接进行切换，须要将数据同步残缺。

4、日志增量迁徙

研发一个日志迁徙工具，把下面迁徙数据过程中的差别数据追平，解决步骤：

读取log日志，获取具体是哪个库、表和主键产生了变动批改；
把旧库中的主键记录读取进去
依据主键ID，把新库中的记录替换掉

这样能够最大水平的保障数据的一致性。危险剖析：

整个过程，依然是旧库对线上提供服务；
日志迁徙工具实现的复杂度较低；
任何工夫发现问题，能够从新再来，有充沛的容错空间；
能够限速重放解决日志，处理过程不会因为对线上影响造成工夫压力。

然而，日志增量同步实现之后，还不能切换到新的数据库。

因为日志增量同步过程中，旧库中可能有数据发生变化，导致数据不统一，所以须要进一步读取日志，追平数据记录；日志增量同步过程随时可能会产生新的数据，新库与旧库的数据追平也会是一个有限迫近的过程。

5、数据校验

筹备好数据校验工具，将旧库和新库中的数据进行比对，直到数据完全一致。

6、切换新库

数据比对实现之后，将流量转移切换至新库，至此新库提供服务，实现迁徙。

然而在极限状况下，即使通过下面的数据校验解决，也有可能呈现99.99%数据统一，不能保障完全一致，这个时候能够在旧库做一个readonly只读性能，或者将流量屏蔽降级，期待日志增量同步工具齐全追平后，再进行新库的切换。

至此，实现日志计划的迁徙扩容解决，整个过程可能继续对线上提供服务，只会短暂的影响服务的可用性。

这种计划的弊病，是操作繁琐，须要适配多个同步解决工具，老本较高，须要制订个性化业务的同步解决，不具备普遍性，消耗的工夫周期也较长。

1.4 双写计划（中小型数据）

双写计划可通过canal或mq做实现。

减少新库，依照现有节点，减少对应的数量。
数据迁徙：防止增量影响，先断开主从，再导入（耗时较长），同步实现并做校验
增量同步：开启Canal同步服务，监听从节点数据库，再开启主从同步，从节点收到数据后会通过Canal服务，传递至新的DB节点。
切换新库：通过Nginx，切换拜访流量至新的服务。
修复切换异样数据：在切换过程中，如果呈现，Canal未同步，但已切换至新库的申请（比方下单，批改了资金，但还未同步），能够通过定制程序，读取检测异样日志，做主动修复或人工解决。
针对此种状况，最好是在凌晨用户量小的时候，或专门进行外网拜访，进行切换，缩小异样数据的产生。
数据校验：为保障数据的完全一致，有必要对数据的数量完整性做校验。

1.5平滑2N计划（大数据量）

线上数据库，为了保障其高可用，个别每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，A，B是主库，A0和B0是从库。

1、当须要扩容的时候，咱们把A0和B0降级为新的主库节点，如此由2个分库变为4个分库。同时在下层的分片配置，做好映射，规定如下:

把uid%4=0和uid%4=2的数据别离调配到A和A0主库中
把uid%4=1和uid%4=3的数据调配到B和B0主库中

2、因为A和A0库的数据雷同，B和B0数据雷同，此时无需做数据迁徙。只需调整变更一下分片配置即可，通过配置核心更新，不须要重启。

因为之前uid%2的数据是调配在2个库外面，扩容之后须要散布到4个库中，但因为旧数据仍存在（uid%4=0的节点,还有一半uid%4=2的数据），所以须要对冗余数据做一次清理。

这个清理，并不会影响线上数据的一致性，能够随时随地进行。

3、解决实现之后，为保证数据的高可用，以及未来下一步的扩容需要。

能够为现有的主库再次调配一个从库。

2. 平滑2N扩容计划实际

2.1 实现应用服务级别的动静扩容

扩容前部署架构：

2.1.1 MariaDB服务装置

切换阿里云镜像服务（YUM装置过慢能够切换）

yum -y install wget## 备份CentOS-Base.repomv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bakwget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repowget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repoyum clean allyum makecache

配置YUM源

vi /etc/yum.repos.d/mariadb-10.2.repo

减少以下内容：

[mariadb]name = MariaDBbaseurl = https://mirrors.ustc.edu.cn/mariadb/yum/10.2/centos7-amd64gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDBgpgcheck=1

执行装置

yum -y install mariadb mariadb-server MariaDB-client  MariaDB-common

如果之前曾经装置，须要先删除（如果之前没有装置，能够疏忽此步骤）

进行Mariadb服务

[root@localhost yum.repos.d]# ps -ef | grep mysqlroot       1954      1  0 Oct04 ?        00:05:43 /usr/sbin/mysqld --wsrep-new-cluster --user=rootroot      89521  81403  0 07:40 pts/0    00:00:00 grep --color=auto mysql[root@localhost yum.repos.d]# kill 1954

卸载Mariadb服务
```
yum -y remove Maria*
```

删除数据与配置：

rm -rf /var/lib/mysql/*rm -rf /etc/my.cnf.d/rm -rf /etc/my.cnf

启动MariaDB后，执行平安配置向导命令，可依据平安配置向导进步数据库的安全性
```
systemctl start mariadbmysql_secure_installation
```

开启用户近程连贯权限

将连贯用户root开启近程连贯权限；

mysql -uroot -p654321

进入MySQL服务，执行以下操作：

use mysql;delete from user;## 配置root用户应用明码654321从任何主机都能够连贯到mysql服务器GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '654321' WITH GRANT OPTION;FLUSH PRIVILEGES;

2.1.2 MariaDB双主同步

在Server1减少配置：

在/etc/my.cnf中增加以下配置：

[mysqld]server-id  = 1log-bin=mysql-binrelay-log = mysql-relay-bin## 疏忽mysql、information_schema库下对表的操作replicate-wild-ignore-table=mysql.%replicate-wild-ignore-table=information_schema.%## 默认的状况下mysql是敞开的;log-slave-updates=on## 复制过程中，有任何谬误，间接跳过slave-skip-errors=allauto-increment-offset=1auto-increment-increment=2## binlog的格局：STATEMENT，ROW，MIXEDbinlog_format=mixed## 主动过期清理binlog，默认0天，即不主动清理expire_logs_days=10

留神， Server1自增为奇数位：

auto-increment-offset=1 主键自增基数, 从1开始。
auto-increment-increment=2 主键自增偏移量，每次为2。

在Server2减少配置：

批改/etc/my.cnf:

[mysqld]server-id = 2log-bin=mysql-binrelay-log = mysql-relay-binreplicate-wild-ignore-table=mysql.%replicate-wild-ignore-table=information_schema.%log-slave-updates=onslave-skip-errors=allauto-increment-offset=2auto-increment-increment=2binlog_format=mixedexpire_logs_days=10

Server2自增为偶数位：

auto-increment-offset=2 主键自增基数, 从2开始。
auto-increment-increment=2 主键自增偏移量，每次为2。

配置批改实现后，重启数据库。

同步受权配置

在Server1创立replica用于主从同步的用户：

MariaDB [(none)]> grant replication slave, replication client on *.* to 'replica'@'%' identified by 'replica';mysql> flush privileges;

查问日志文件与偏移量，开启同步时需应用：

MariaDB [(none)]> show master status;+------------------+----------+--------------+------------------+|              | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000001 |      663 |              |                  |+------------------+----------+--------------+------------------+

同样，在Server2创立replica用于主从同步的用户：

MariaDB [(none)]> grant replication slave, replication client on *.* to 'replica'@'%' identified by 'replica';mysql> flush privileges;

查问日志文件与偏移量：

MariaDB [(none)]> show master status;+------------------+----------+--------------+------------------+|              | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000001 |      663 |              |                  |+------------------+----------+--------------+------------------+

配置主从同步信息

在Server1中执行：

MariaDB [(none)]> change master to master_host='192.168.116.141',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000007', master_log_pos=374, master_connect_retry=30;

在Server2中执行：

MariaDB [(none)]> change master to master_host='192.168.116.140',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000015', master_log_pos=374, master_connect_retry=30;

开启双主同步

在Server1和Server2中别离执行：

MariaDB [(none)]> start slave;Query OK, 0 rows affected (0.00 sec)

在Server1查问同步信息：

MariaDB [(none)]>  show slave status\G;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 10.10.20.126                  Master_User: replica                  Master_Port: 3306                Connect_Retry: 30              Master_Log_: mysql-bin.000001          Read_Master_Log_Pos: 663               Relay_Log_: mysql-relay-bin.000002                Relay_Log_Pos: 555        Relay_Master_Log_: mysql-bin.000001             Slave_IO_Running: Yes            Slave_SQL_Running: Yes...

在Server2查问同步信息：

MariaDB [(none)]>  show slave status\G;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 10.10.20.125                  Master_User: replica                  Master_Port: 3306                Connect_Retry: 30              Master_Log_: mysql-bin.000001          Read_Master_Log_Pos: 663               Relay_Log_: mysql-relay-bin.000002                Relay_Log_Pos: 555        Relay_Master_Log_: mysql-bin.000001             Slave_IO_Running: Yes            Slave_SQL_Running: Yes...

Slave_IO_Running和Slave_SQL_Running 都是Yes，阐明双主同步配置胜利。

2.1.3 KeepAlived装置与高可用配置

在Server1与Server2两台节点装置keepalived：
```
yum -y install keepalived
```

敞开防火墙

systemctl stop firewalldsystemctl disable firewalld

设置主机名称：

Server1节点：

hostnamectl set-hostname vip1

Server2节点：

hostnamectl set-hostname vip2

Server1节点配置

/etc/keepalived/keepalived.conf：

global_defs {   router_id vip1           # 机器标识，和主机名保持一致，运行keepalived服务器的一个标识}vrrp_instance VI_1 {            #vrrp实例定义    state BACKUP               #lvs的状态模式，MASTER代表主， BACKUP代表备份节点    interface ens33               #绑定对外拜访的网卡，vrrp实例绑定的网卡    virtual_router_id 111        #虚构路由标示，同一个vrrp实例采纳惟一标示    priority 100               #优先级，100代表最大优先级， 数字越大优先级越高    advert_int 1              #master与backup节点同步查看的工夫距离，单位是秒    authentication {           #设置验证信息        auth_type PASS         #有PASS和AH两种        auth_pass 6666         #验证明码，BACKUP明码须雷同    }    virtual_ipaddress {         #KeepAlived虚构的IP地址        192.168.116.150    }}virtual_server 192.168.116.150 3306 {       #配置虚构服务器IP与拜访端口    delay_loop 6                 #健康检查工夫    lb_algo rr                  #负载平衡调度算法， rr代表轮询    lb_kind DR                   #负载平衡转发规定 DR/NAT/    persistence_timeout 0        #会话放弃工夫，这里要做测试， 所以设为0， 理论可依据session无效工夫配置    protocol TCP               #转发协定类型，反对TCP和UDP    real_server 192.168.116.140 3306 {    #配置服务器节点VIP1        notify_down /usr/local/shell/mariadb.sh #当服务挂掉时， 会执行此脚本，完结keepalived过程    weight 1               #设置权重，越大权重越高    TCP_CHECK {              #状态监测设置       connect_timeout 10       #超时配置， 单位秒       retry 3             #重试次数       delay_before_retry 3        #重试距离       connect_port 3306         #连贯端口， 和下面保持一致       }    }}

创立敞开脚本mariadb.sh

/usr/local/shell/mariadb.sh：

pkill keepalived

退出执行权限：

chmod a+x mariadb.sh

Server2节点配置：

global_defs {   router_id vip2           # 机器标识，和主机名保持一致，运行keepalived服务器的一个标识}vrrp_instance VI_1 {            #vrrp实例定义    state BACKUP               #lvs的状态模式，MASTER代表主， BACKUP代表备份节点    interface ens33               #绑定对外拜访的网卡    virtual_router_id 111        #虚构路由标示，同一个vrrp实例采纳惟一标示    priority 98               #优先级，100代表最大优先级， 数字越大优先级越高    advert_int 1              #master与backup节点同步查看的工夫距离，单位是秒    authentication {           #设置验证信息        auth_type PASS         #有PASS和AH两种        auth_pass 6666         #验证明码，BACKUP明码须雷同    }    virtual_ipaddress {         #KeepAlived虚构的IP地址        192.168.116.150    }}virtual_server 192.168.116.150 3306 {       #配置虚构服务器IP与拜访端口    delay_loop 6                 #健康检查工夫    lb_algo rr                  #负载平衡调度算法， rr代表轮询, 能够敞开    lb_kind DR                   #负载平衡转发规定, 能够敞开    persistence_timeout 0        #会话放弃工夫，这里要做测试， 所以设为0， 理论可依据session无效工夫配置    protocol TCP               #转发协定类型，反对TCP和UDP    real_server 192.168.116.141 3306{    #配置服务器节点VIP2    notify_down /usr/local/shell/mariadb.sh #当服务挂掉时， 会执行此脚本，完结keepalived过程    weight 1               #设置权重，越大权重越高    TCP_CHECK {              #r状态监测设置       connect_timeout 10       #超时配置， 单位秒       retry 3             #重试次数       delay_before_retry 3        #重试距离       connect_port 3306         #连贯端口， 和下面保持一致       }    }}

和Server1的差别项：

router_id vip2   # 机器标识，和主机名保持一致priority 98               #优先级，100代表最大优先级， 数字越大优先级越高real_server 10.10.20.126 3306  #配置服务器节点VIP2

留神，两台节点都设为BACKUP

virtual_router_id 111        #同一个vrrp实例采纳惟一标示state BACKUP

如果不想重启后，抢夺备用节点的VIP，能够设置此项

nopreempt #不被动抢占资源

留神：这个配置只能设置在backup主机上，而且这个主机优先级要比另外一台高

验证高可用
进行主节点MariaDB服务，验证是否主动切换。

2.1.4 搭建应用服务工程

ShardingJDBC的介绍
是ShardingSphere 下的一个产品
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额定服务。它应用客户端直连数据库，以 jar 包模式提供服务，无需额定部署和依赖，可了解为增强版的 JDBC 驱动，齐全兼容 JDBC 和各种 ORM 框架。
- 实用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或间接应用 JDBC。
- 反对任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 反对任意实现 JDBC 标准的数据库，目前反对 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 规范的数据库
ShardingJDBC初始化流程
1）配置ShardingRuleConfiguration对象
2）配置表分片规定TableRuleConfiguration对象，设置分库、分表策略
3）通过Factory对象将Rule对象与DataSource对象拆卸
4）ShardingJDBC应用DataSource对象进行分库

ShardingJDBC集成配置
1）maven依赖
2）规定配置application.yml
3）创立DataSource

验证应用服务动静扩容

配置两个数据源，别离指向Server1和Server2
分片只配置一个数据源
动静减少另一个数据源

// 动静数据源配置实现扩容Properties properties = loadProperties("datasource1.properties");try {    log.info("load datasource config url: " + properties.get("url"));    DruidDataSource druidDataSource = (DruidDataSource) DruidDataSourceFactory.createDataSource(properties);    druidDataSource.setRemoveAbandoned(true);    druidDataSource.setRemoveAbandonedTimeout(600);    druidDataSource.setLogAbandoned(true);    // 设置数据源谬误重连工夫    druidDataSource.setTimeBetweenConnectErrorMillis(60000);    druidDataSource.init();    OrchestrationShardingDataSource dataSource = SpringContextUtil.getBean("tradeSystemDataSource", OrchestrationShardingDataSource.class);    Map<String, DataSource> dataSourceMap = dataSource.getDataSource().getDataSourceMap();    dataSourceMap.put(DatasourceEnum.DATASOURCE_2.getValue(), druidDataSource);    Map<String, DataSourceConfiguration> dataSourceConfigMap = new HashMap<String, DataSourceConfiguration>();    for(String key : dataSourceMap.keySet()) {        dataSourceConfigMap.put(key, DataSourceConfiguration.getDataSourceConfiguration(dataSourceMap.get(key)));    }    String result = SHARDING_RULE_TABLE_ORDER.replace(SHARDING_RULE_DATASOURCE, newRule);    replaceActualDataNodes(result);    SHARDING_RULE_DATASOURCE = newRule;    dataSource.renew(new DataSourceChangedEvent(        "/" + DruidSystemDataSourceConfiguration.DYNAMIC_SHARDING + "/config/schema/logic_db/datasource",        dataSourceConfigMap));    return;} catch (Exception e) {    log.error(e.getMessage(), e);}

注意事项
Sharding JDBC, Mycat, Drds 等产品都是分布式数据库中间件, 相比间接的数据源操作, 会存在一些限度, Sharding JDBC在应用时, 要留神以下问题:
- 无限反对子查问
- 不反对HAVING
- 不反对OR，UNION 和 UNION ALL
- 不反对非凡INSERT
- 每条INSERT语句只能插入一条数据，不反对VALUES后有多行数据的语句
- 不反对DISTINCT聚合
- 不反对dual虚构表查问
- 不反对SELECT LAST_INSERT_ID(), 不反对自增序列
- 不反对CASE WHEN

2.2 实现数据库的秒级平滑2N扩容

扩容部署架构：

2.2.1 新增数据库VIP

在Server2节点，减少VIP

批改/etc/keepalived/keepalived.conf

global_defs {   router_id vip2}vrrp_instance VI_1 {            #vrrp实例定义    state BACKUP               #lvs的状态模式，MASTER代表主， BACKUP代表备份节点    interface ens33               #绑定对外拜访的网卡    virtual_router_id 112        #虚构路由标示，同一个vrrp实例采纳惟一标示    priority 100               #优先级，100代表最大优先级， 数字越大优先级越高    advert_int 1              #master与backup节点同步查看的工夫距离，单位是秒    authentication {           #设置验证信息        auth_type PASS         #有PASS和AH两种        auth_pass 6666         #验证明码，BACKUP明码须雷同    }    virtual_ipaddress {         #KeepAlived虚构的IP地址        192.168.116.151    }}virtual_server 192.168.116.151 3306 {       #配置虚构服务器IP与拜访端口    delay_loop 6                 #健康检查工夫    persistence_timeout 0        #会话放弃工夫，这里要做测试， 所以设为0， 理论可依据session无效工夫配置    protocol TCP               #转发协定类型，反对TCP和UDP    real_server 192.168.116.141 3306{    #配置服务器节点VIP1    notify_down /usr/local/shell/mariadb.sh    weight 1               #设置权重，越大权重越高    TCP_CHECK {              #r状态监测设置       connect_timeout 10       #超时配置， 单位秒       retry 3             #重试次数       delay_before_retry 3        #重试距离       connect_port 3306         #连贯端口， 和下面保持一致       }    }}

留神配置项：

virtual_router_id 112        #虚构路由标示，同一个vrrp实例采纳惟一标示priority 100               #优先级，100代表最大优先级， 数字越大优先级越高

2.2.2 应用服务减少动静数据源

批改应用服务配置，减少新的数据源，指向新设置的VIP： 192.168.116.151
通过应用服务接口，动静扩容调整

2.2.3 解除原双主同步

mysql -uroot -p654321

进入Server1:
```
MariaDB [(none)]> stop slave;
```
进入Server2:
```
MariaDB [(none)]> stop slave;
```
通过应用服务接口验证数据是否解除同步

2.2.4 装置MariaDB扩容服务器

新建两台虚拟机，别离为Server3和Server4。
在Server3和Server4两台节点上装置MariaDB服务
参考2.1.1 MariaDB服务装置

配置Server3与Server1，实现新的双主同步

Server3节点，批改/etc/my.cnf:

[mysqld]server-id = 3log-bin=mysql-binrelay-log = mysql-relay-binreplicate-wild-ignore-table=mysql.%replicate-wild-ignore-table=information_schema.%log-slave-updates=onslave-skip-errors=allauto-increment-offset=2auto-increment-increment=2binlog_format=mixedexpire_logs_days=10

重启Server3数据库

service mariadb restart

创立replica用于主从同步的用户：

MariaDB [(none)]> grant replication slave, replication client on *.* to 'replica'@'%' identified by 'replica';mysql> flush privileges;

在Server1节点，进行数据全量备份：

mysqldump -uroot -p654321 --routines --single_transaction --master-data=2 --databases smooth > server1.sql

查看并记录master status信息：

...---- Position to start replication or point-in-time recovery from---- CHANGE MASTER TO MASTER_LOG_='mysql-bin.000002', MASTER_LOG_POS=17748;...

将备份的server1.sql通过scp命令拷贝至Server3节点。

scp server1.sql root@192.168.116.142:/usr/local/

将数据还原至Server3节点：

mysql -uroot -p654321 < /usr/local/server1.sql

配置主从同步信息

依据下面的master status信息，在Server3中执行：

MariaDB [(none)]> change master to master_host='192.168.116.140',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000016', master_log_pos=1754, master_connect_retry=30;Query OK, 0 rows affected (0.01 sec)

开启主从同步：

MariaDB [(none)]> start slave;Query OK, 0 rows affected (0.00 sec)

如果呈现问题，还原主从同步信息：

MariaDB [(none)]> reset slave;Query OK, 0 rows affected (0.01 sec)

查看同步状态信息：

MariaDB [(none)]> show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 10.10.20.125                  Master_User: replica                  Master_Port: 3306                Connect_Retry: 30              Master_Log_: mysql-bin.000004          Read_Master_Log_Pos: 11174               Relay_Log_: mysql-relay-bin.000002                Relay_Log_Pos: 1746        Relay_Master_Log_: mysql-bin.000004             Slave_IO_Running: Yes            Slave_SQL_Running: Yes

配置Server1与Server3节点的同步

查看Server3的日志信息：

MariaDB [(none)]> show master status;+------------------+----------+--------------+------------------+|              | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000001 |     4781 |              |                  |+------------------+----------+--------------+------------------+

在Server1节点，配置同步信息：

MariaDB [(none)]> reset slave;Query OK, 0 rows affected (0.00 sec)MariaDB [(none)]> change master to master_host='192.168.116.142',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000005', master_log_pos=6931, master_connect_retry=30;MariaDB [(none)]> start slave;Query OK, 0 rows affected (0.00 sec)

配置Server4与Server2的双主同步

Server4节点，批改/etc/my.cnf:

[mysqld]server-id = 4log-bin=mysql-binrelay-log = mysql-relay-binreplicate-wild-ignore-table=mysql.%replicate-wild-ignore-table=information_schema.%log-slave-updates=onslave-skip-errors=allauto-increment-offset=2auto-increment-increment=2binlog_format=mixedexpire_logs_days=10

重启Server4数据库

service mariadb restart

创立replica用于主从同步的用户：

MariaDB [(none)]> grant replication slave, replication client on *.* to 'replica'@'%' identified by 'replica';mysql> flush privileges;

在Server2节点，进行数据全量备份：

mysqldump -uroot -p654321 --routines --single_transaction --master-data=2 --databases smooth > server2.sql

查看并记录master status信息：

...---- Position to start replication or point-in-time recovery from---- CHANGE MASTER TO MASTER_LOG_='mysql-bin.000003', MASTER_LOG_POS=4208;...

将备份的server2.sql通过scp命令拷贝至Server4节点。

scp server2.sql root@192.168.116.143:/usr/local/

将数据还原至Server4节点：

mysql -uroot -p654321 < /usr/local/server2.sql

配置主从同步信息

依据下面的master status信息，在Server4中执行：

MariaDB [(none)]> change master to master_host='192.168.116.141',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000007', master_log_pos=3006, master_connect_retry=30;Query OK, 0 rows affected (0.01 sec)

开启主从同步：

MariaDB [(none)]> start slave;Query OK, 0 rows affected (0.00 sec)

留神，如果呈现问题，还原主从同步信息：

MariaDB [(none)]> reset slave;Query OK, 0 rows affected (0.01 sec)

查看同步状态信息：

MariaDB [(none)]> show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 10.10.20.125                  Master_User: replica                  Master_Port: 3306                Connect_Retry: 30              Master_Log_: mysql-bin.000004          Read_Master_Log_Pos: 11174               Relay_Log_: mysql-relay-bin.000002                Relay_Log_Pos: 1746        Relay_Master_Log_: mysql-bin.000004             Slave_IO_Running: Yes            Slave_SQL_Running: Yes

配置Server2与Server4节点的同步

查看Server4的日志信息：

MariaDB [(none)]> show master status;+------------------+----------+--------------+------------------+|              | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000001 |     3696 |              |                  |+------------------+----------+--------------+------------------+

在Server2节点，配置同步信息：

MariaDB [(none)]> reset slave;Query OK, 0 rows affected (0.00 sec)MariaDB [(none)]> change master to master_host='192.168.116.143',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000005', master_log_pos=5787, master_connect_retry=30;MariaDB [(none)]> start slave;Query OK, 0 rows affected (0.00 sec)

2.2.5 减少KeepAlived服务实现高可用

确保新增的Server3和Server4节点装置Keepalived服务。

批改Server3节点配置

global_defs {   router_id vip3          # 机器标识，个别设为hostname，故障产生时，邮件告诉会应用到。}vrrp_instance VI_1 {            #vrrp实例定义    state BACKUP               #lvs的状态模式，MASTER代表主， BACKUP代表备份节点    interface ens33               #绑定对外拜访的网卡    virtual_router_id 111        #虚构路由标示，同一个vrrp实例采纳惟一标示    priority 98               #优先级，100代表最大优先级， 数字越大优先级越高    advert_int 1              #master与backup节点同步查看的工夫距离，单位是秒    authentication {           #设置验证信息        auth_type PASS         #有PASS和AH两种        auth_pass 6666         #验证明码，BACKUP明码须雷同    }    virtual_ipaddress {         #KeepAlived虚构的IP地址        192.168.116.150    }}virtual_server 192.168.116.150 3306 {       #配置虚构服务器IP与拜访端口    delay_loop 6                 #健康检查工夫    persistence_timeout 0        #会话放弃工夫，这里要做测试， 所以设为0， 理论可依据session无效工夫配置    protocol TCP               #转发协定类型，反对TCP和UDP    real_server 192.168.116.142 3306{    #配置服务器节点VIP3    notify_down /usr/local/shell/mariadb.sh    weight 1               #设置权重，越大权重越高    TCP_CHECK {              #r状态监测设置       connect_timeout 10       #超时配置， 单位秒       retry 3             #重试次数       delay_before_retry 3        #重试距离       connect_port 3306         #连贯端口， 和下面保持一致       }    }}

留神外面IP配置正确，批改实现后重启服务。

创立敞开脚本mariadb.sh

/usr/local/shell/mariadb.sh：

pkill keepalived

退出执行权限：

chmod a+x mariadb.sh

批改Server4节点配置

global_defs {   router_id vip4          # 机器标识，个别设为hostname，故障产生时，邮件告诉会应用到。}vrrp_instance VI_1 {            #vrrp实例定义    state BACKUP               #lvs的状态模式，MASTER代表主， BACKUP代表备份节点    interface ens33               #绑定对外拜访的网卡    virtual_router_id 112        #虚构路由标示，同一个vrrp实例采纳惟一标示    priority 98               #优先级，100代表最大优先级， 数字越大优先级越高    advert_int 1              #master与backup节点同步查看的工夫距离，单位是秒    authentication {           #设置验证信息        auth_type PASS         #有PASS和AH两种        auth_pass 6666         #验证明码，BACKUP明码须雷同    }    virtual_ipaddress {         #KeepAlived虚构的IP地址        192.168.116.151    }}virtual_server 192.168.116.151 3306 {       #配置虚构服务器IP与拜访端口    delay_loop 6                 #健康检查工夫    persistence_timeout 0        #会话放弃工夫，这里要做测试， 所以设为0， 理论可依据session无效工夫配置    protocol TCP               #转发协定类型，反对TCP和UDP    real_server 192.168.116.143 3306{    #配置服务器节点VIP4    notify_down /usr/local/shell/mariadb.sh    weight 1               #设置权重，越大权重越高    TCP_CHECK {              #r状态监测设置       connect_timeout 10       #超时配置， 单位秒       retry 3             #重试次数       delay_before_retry 3        #重试距离       connect_port 3306         #连贯端口， 和下面保持一致       }    }}

创立敞开脚本mariadb.sh

/usr/local/shell/mariadb.sh：

pkill keepalived

给所有的用户组退出执行权限：

chmod a+x mariadb.sh

批改完后重启Keepalived服务。

2.2.6 清理数据并验证

通过应用服务动静扩容接口做调整和验证
在Server1节点清理数据
依据取模规定，保留accountNo为偶数的数据
```
delete from t_trade_order where accountNo % 2 != 0
```
在Server2节点清理数据
依据取模规定，保留accountNo为奇数的数据
```
delete from t_trade_order where accountNo % 2 != 1
```

3.keepalived高可用配置大全

在Server1（192.168.116.140）中执行：

MariaDB [(none)]> change master to master_host='192.168.116.141',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000005', master_log_pos=3207, master_connect_retry=30;

在Server2（192.168.116.141）中执行：

MariaDB [(none)]> change master to master_host='192.168.116.140',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000012', master_log_pos=1951, master_connect_retry=30;

在Server3（192.168.116.142）中执行：

MariaDB [(none)]> change master to master_host='192.168.116.140',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000013', master_log_pos=2781, master_connect_retry=30;Query OK, 0 rows affected (0.01 sec)

在Server4（192.168.116.143）中执行：

MariaDB [(none)]> change master to master_host='192.168.116.141',master_user='replica', master_password='replica', master_port=3306, master_log_='mysql-bin.000005', master_log_pos=7358, master_connect_retry=30;Query OK, 0 rows affected (0.01 sec)