此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

时间  2019-11-08
标签 此次 必定 搭建 redis 集群 mysql 主从 同步 docker 栏目 Redis 繁體版
原文   原文链接

前言

一直都想本身动手搭建一个Redis集群和MySQL的主从同步，固然不是依靠Docker的一键部署（虽然如今企业开发用的最多的是这种方式），因此本文就算是一个教程类文章吧，但在动手搭建以前，会先聊聊理论的东西，以便于你们有一个集群和主从同步的概念，若是有同窗不了解Redis和MySQL，能够看一下我以前的两篇文章。java

Redis由浅入深深深深深剖析node

从入门到入土：使人脱发的数据库底层设计mysql

什么是Redis集群

简介

Redis是一个快速高效的NoSQL型数据库，因为其基于内存存储、单线程、多路IO复用的特性，其QPS能够达到惊人的100000+（官方数据），可是即便有这么高的速度，在中国这么大的网民基数环境下，也存在着性能瓶颈。nginx

首先抛开服务器故障不谈，Redis集群首先可使Redis性能获得线性提升，这是毋庸置疑的，其次Redis集群除了解决了效率问题，还能够解决服务器宕机形成的数据丢失问题，当某个Redis节点宕机，剩下的节点会继续工做，并不会影响总体集群的使用，从而实现高可用。程序员

Redis单机模式有什么问题

单机故障redis

在单机模式下的Redis，咱们的应用中全部须要缓存的数据都依赖一台Redis服务器，应用的流量小可能看不出什么问题，可是随着应用愈来愈大，流量愈来愈大，若是出现服务器宕机或者断电的情况，那么咱们的应用整个一个缓存层在一段时间内（重启）都将不复存在。sql

先不谈基于Redis的分布式Session可能形成的问题，若是刚好赶上流量高峰，这些流量直接打在数据库上，咱们知道数据库的IO效率远不及Redis，这将大大提升应用负载，容易出现数据库服务器的宕机，从而形成应用的宕机。docker

由此看来，单机版Redis若是出现故障，将有可能引发一系列的连锁反应，形成不可逆的损失。数据库

容量瓶颈缓存

咱们知道Redis是基于内存存储的一个NoSQL数据库，基于内存也是其高速高效的缘由之一。虽然容量瓶颈在实际生产中并不常见（一般有意识地将搭载Redis的机器内存容量加高），可是不排除在某些极端条件下Redis会将一台机器的内存耗尽，形成数据丢失，甚至服务器宕机。

性能瓶颈

简介中提到，虽然Redis在官方文档中提到能够达到约100000+QPS，可是首先在平常环境的测试中，咱们可能并达不到文档中宣称的QPS，换言之，这可能也就是一种理论值，就像是4G的理论网速在10-100Mbps，折合下载速度1.5M/s-10M/s。

但在平常生活中咱们极少甚至历来没有达到过这个速度过，同样的道理。其次，在中国巨大的网民基数下，单机Redis知足平常需求尚且捉襟见肘，若是碰上像双11、双12、春运这些特殊的环境，单台Redis显然会有性能不足的现象发生。

Redis集群的三种模式

主从模式

主从模式是最简单的一种Redis集群模式，首先其思想就是一台Redis服务器做为主服务器（Master），一台或多台服务器做为从服务器（Slave）。当以此种方式部署集群时，集群有以下特色：

  • Master能够进行读写操做，当写操做致使数据发生变化时，将自动同步给Slave，Slave一般是只读的，而且接受从Master同步过来的数据。
  • 一台Master能够有多台Slave，但每台Slave只能有一个Master。
  • 某台Slave宕机不影响其余Slave和Master的读写，从新启动后会将数据从新从Master同步过来。
  • Master宕机后不影响Slave的读，但该集群再也不提供对Redis的写入功能。
  • Master宕机后不会从Slave中选举主节点。

在此种模式下，咱们能够对Redis集群作容灾备份和读写分离，可是要注意，容灾备份并不能拯救你的误操做，由于不管增删改，Redis都将其做为写，同步到每一个Slave节点上，因此容灾，是指不可预知的错误致使数据丢失，这种状况下能够从Slave节点中找到原数据的备份，从而进行数据恢复。

而读写分离就比较好理解了，上文中提到，Master节点能够读写，而Slave节点一般只进行读操做，索性直接将全部的读操做都转移到Slave节点上，这样能够减轻Master节点的IO压力。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

主从模式的工做原理（全量同步）:

Redis全量同步通常发生在Slave初始化阶段，但其实在任什么时候候Slave均可以向Master发起全量同步的请求，这时Slave须要将Master上的全部数据都复制一份。

  • Slave链接主服务器，发送SYNC命令。
  • Master接收到SYNC命令后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的全部写命令。
  • Master执行完BGSAVE后，向全部从服务器发送RDB文件，并在发送期间继续记录被执行的写命令。
  • Slave收到RDB文件后丢弃全部旧数据，载入收到的RDB。
  • Master快照发送完毕后开始向Slave发送缓冲区中的写命令。
  • Slave完成对RDB的载入，开始接收命令请求，并执行来自Master缓冲区的写命令。

主从模式的工做原理（增量同步）:

Redis增量同步通常发生在Slave已经初始化完成，开始正常链接Master的阶段

  • Master接收到写请求，将写命令发送到Slave。
  • Slave执行接收到的些命令。

注：若是多个Slave同时宕机重启，那么就会同时向Master发送SYNC命令，那么有可能会形成Master节点的IO剧增，有可能会引发宕机。

哨兵（Sentinel）模式

上文中介绍了Redis主从复制模式下的集群策略，当Master宕机后，不会从Slave节点中选举出Master，因此该集群丧失了写的能力，咱们只能人工去将Slave节点晋升为Master节点，同时要通知应用方更新Master节点的IP地址，对于这种故障处理的方式在如今的环境下一般是不可接受的。因此从Redis2.8开始，Redis正式提供了哨兵模式的架构（故障转移），来解决这个问题。

哨兵模式的工做特色：

  • 哨兵模式是创建在主从模式的基础上，当Master节点宕机以后，哨兵会从Slave节点中选择一个节点做为Master，并修改它们的配置文件，使其余的Slave指向新的Master。
  • 当原先宕机的Master节点从新启动时，他将再也不是Master，而是做为新Master的一个Slave节点存在。
  • 哨兵节点是一个特殊的Redis节点（不存储数据），本质上也是一个进程，因此也有挂掉的可能，因此哨兵也存在集群模式。

哨兵模式工做原理：

  • 每隔10秒，每一个哨兵节点会向Master和Slave节点发送info命令获取最新的拓扑结构。
  • 每隔1秒，每一个哨兵节点会向Master和Slave节点还有其它哨兵节点发送ping命令作心跳检测，看看是否存在不可达的节点。
  • 主观下线，若是某个哨兵向一个节点发出的心跳检测没有获得响应，那么该哨兵认为该节点已经下线。
  • 客观下线，当哨兵主观下线的节点是主节点时，哨兵会向其余的哨兵询问对主节点的判断，当下线判断超过必定个数时，那么哨兵会认为主节点确实已经下线，那么会对主节点进行客观下线的断定。
  • 故障转移，当Master节点客观下线时，哨兵会从Slave节点中选择一个节点做为Master节点，选择规则是选择与主节点复制类似度最高的节点，选择完成后会将其他的Slave节点指向新的Master节点，并监控原来的Master节点，当它回复后做为新Master节点的Slave存在，而且同步新Master节点的数据。
  • 选举领导者哨兵节点：当主节点被判断客观下线之后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操做。
  • 当使用sentinel模式的时候，客户端不用直接链接Redis，而是链接哨兵的ip和port，由哨兵来提供具体的可提供服务的Redis实现，这样当master节点挂掉之后，哨兵就会感知并将新的master节点提供给使用者。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

Cluster模式

在上文的哨兵模式中，哨兵引入了主节点的自动故障转移，进一步提升了Redis的高可用性。可是哨兵的缺陷一样很明显：哨兵没法对Slave进行自动故障转移，在读写分离场景下，Slave故障会致使读服务不可用，须要咱们对Slave作额外的监控、切换操做。

此外，哨兵仍然没有解决写操做没法负载均衡、及存储能力受到单机限制的问题。

Redis Cluster模式是Redis3.0以后推荐的一种解决方案，其是由多个主节点群组成的分布式服务器群，它具备复制、高可用和分片的特性。另外，Redis Cluster集群不须要哨兵也能完成节点移除和故障转移的功能。须要将每一个节点设置为集群模式，这种集群模式没有中心节点，可水平扩展，且集群配置很是简单。

Cluster集群模式工做特色：

  • 多个Redis节点互联，数据共享。
  • 全部的节点都是主从模式，其中Slave不提供服务，只提供备用。
  • 不支持同时处理多个Key，由于须要分发到多个节点上。
  • 支持在线增长、删除节点。
  • 客户端能够链接任何一个Master节点进行读写。

Cluster集群模式工做原理：

Redis Cluster有固定的16384个hash slot(槽)，对每一个key计算CRC16值，而后对16384取模，能够获取key对应的hash slot。每一个master都会持有部分slot，好比有3个master，那么可能每一个master持有5000多个hash slot，在redis cluster写入数据的时候。

实际上是你能够将请求发送到任意一个master上去执行。可是，每一个master都会计算这个key对应的CRC16值，而后对16384个hashslot取模，找到key对应的hashslot，找到hashslot对应的master。

主观下线(pfail)：集群中的每一个节点都会按期向其余节点发送ping消息，若是在一段时间内一直通讯失败，则发送节点方认为接收节点存在故障，把接收节点标为主观下线(pfail)状态。

客观下线(fail)：当某个节点判断另外一个节点主观下线后，相应的节点状态就会在集群中进行传播，若是集群中全部节点都将它标为主观下线，那么该节点为客观下线，并通知该节点的Slave进行故障转移操做。

故障转移：在某个节点客观下线后，该节点的从节点开始故障转移流程，首先进行资格检查，每一个从节点检查与主节点的断开时间，超过必定时间的取消选举资格，而后一样在全部从节点中寻找复制偏移量最大的节点先开始进行选举，只有持有槽的主节点才有投票权，当从节点收集到过半的票数时，即晋升为Master，随即通知Slave当前Master变为本身。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

搭建Redis集群

上文中说了三种Redis搭建的模式，分别是主从模式、哨兵模式、Cluster模式，关于前两种网上有着很是多的教程，这里就再也不从新演示了，这里着重演示一下如何去搭建一个Redis Cluster集群。

环境准备

CentOS 7，Redis5.0.4

场景描述

本次会启动三台CentOS 7服务器，每台服务器上搭载三个Redis实例，一主二从，一共三个Master实例，六个Slave实例。

清单以下：

Master 1：IP：192.168.43.101 Port：7001

Master 2：IP：192.168.43.102 Port：7002

Master 3：IP：192.168.43.103 Port：7003

Slave 1：IP：192.168.43.101 Port：6001

Slave 2：IP：192.168.43.102 Port：6002

Slave 3：IP：192.168.43.103 Port：6003

Slave 4：IP：192.168.43.101 Port：6004

Slave 5：IP：192.168.43.102 Port：6005

Slave 6：IP：192.168.43.103 Port：6006

 

修改配置文件

熟悉Redis的应该明白，所谓Redis实例，实际上就是一个又一个的配置文件。要在服务器上启动多台不一样Redis，实际上就是使用不一样的配置文件来启动Redis，因此第一步咱们要先对集群中的每个Redis实例配置不同的配置文件。

绑定Redis地址

下列三台主机上的配置文件均为Master节点配置文件（修改bind属性）

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

修改端口号

将端口号修改成自定义的端口号，默认为6379,修改成咱们自定义的端口号。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

开启集群模式并设置集群配置文件

将cluster-enabled 设置为yes，并将cluster-config-file设置为自定义的文件。

这里定义为nodes-端口号.conf

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

修改集群RDB快照和AOF文件的存放位置

修改dir属性，这里定义为/home/redis-cluster/redis-master/

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

修改集群密码

修改masterauth属性为Redis（RequirePass）密码。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

开启AOF持久化

修改appendonly属性

appendonly yes

 

对六台Slave节点进行一样的修改配置操做

注意：上述指定的文件夹和文件名原则上对于每一个redis实例都应该是惟一的，便于区分。

启动Redis实例

运行命令：

#第一台主机
/usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7001.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6001.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6004.conf

#第二台主机
/usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7002.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6002.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6005.conf

#第三台主机
/usr/local/bin/redis-server /home/redis-cluster/redis-master/redis-master-7003.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6003.conf
/usr/local/bin/redis-server /home/redis-cluster/redis-slave/redis-slave-6006.conf

 

查看进程 ps -ef | grep redis：

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

能够看到如今启动的redis实例已是集群模式的了。

搭建集群

输入命令：

/usr/local/bin/redis-cli -a Object 
--cluster create --cluster-replicas 2 192.168.43.101:7001 
192.168.43.102:7002 192.168.43.103:7003 192.168.43.101:6001 
192.168.43.102:6002 192.168.43.103:6003 192.168.43.101:6004 
192.168.43.102:6005 192.168.43.103:6006

 

其中 --cluster-replicas 2表明每一个Master携带2个Slave，那么就是三个Master，每一个Master携带两个Slave。

示意图以下：

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

咱们能够看到，Redis将三台机器连成了一个总体，Master7001的Slave指向了其它两台服务器上的Slave，而其它两台服务器的Master也一样跨服务器指向了，这就是RedisCluster高可用的策略，假设有一台服务器完整地宕机了，因为本身的Slave节点存在于别的服务器上，数据也能从新经过选举选举的方式恢复，不易引发数据的丢失。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

另外咱们能够看到，咱们在上文说过，Cluster集群模式将集群分为16384个槽，这里体现为0-16383，分布到了每个Master节点上，这对咱们以前的理论部分作了验证。

测试

测试环节经过客户端测试和Java程序测试，来模拟集群模式下Redis的存储策略。

客户端测试

开启客户端，随意链接一个master节点

/usr/local/bin/redis-cli -c -a 密码 -h IP -p 端口

 

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

咱们能够看到，当咱们set一个键值对的时候，Redis会自动为咱们的key计算CRC16值，而后对16384取模，获取key对应的hash slot，而后经过判断该槽被那个Master所占用，帮咱们重定向到那个Master节点，将键值对存入。

程序测试

在测试以前先把Redis中的数据清空，对三个Master节点分别执行flushall命令。

启动程序：

1.正常存入数据时关闭某Master节点（模拟宕机）：

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

程序打印正在选举…

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

2.选举结束后继续IO

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

代码：

public class JedisDemo {
    public static void main(String[] args) {

         JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); 
         Set<HostAndPort> nodes = new HashSet<>();
         nodes.add(new HostAndPort("192.168.43.101",7001));
         nodes.add(new HostAndPort("192.168.43.102",7002)); 
         nodes.add(new HostAndPort("192.168.43.103",7003)); 
         nodes.add(new HostAndPort("192.168.43.101",6001)); 
         nodes.add(new HostAndPort("192.168.43.102",6002)); 
         nodes.add(new HostAndPort("192.168.43.103",6003)); 
         nodes.add(new HostAndPort("192.168.43.101",6004)); 
         nodes.add(new HostAndPort("192.168.43.102",6005)); 
         nodes.add(new HostAndPort("192.168.43.103",6006)); 
         JedisCluster jedisCluster = new JedisCluster(nodes,100,1000,100,"Object","rediscluster",jedisPoolConfig,false);
         for(int i = 0;i<2000;i++) {
             try {
            System.out.println("存入数据:"+i);
             jedisCluster.set(String.valueOf(i),String.valueOf(i));
                 try {
                    Thread.sleep(300);
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
            e.printStackTrace();
                }
                 String res = jedisCluster.get(String.valueOf(i)); 
                 System.out.println("取出数据:"+res);
             }catch(Exception e) {
                 //出现节点宕机
                 System.out.println("正在选举...");
                 System.out.println(new Date());
                 continue;
             }
         }

         jedisCluster.close();
    }
}

 

注意事项

在搭建集群的过程当中有可能会遇到一直等待链接，可是集群没法链接成功的情况，这是由于咱们在搭建集群的时候防火墙没有开启对应的端口号致使的，咱们不光要开启咱们对外链接的端口号，如700一、700二、7003，还要开启对外链接端口号+10000的端口，用于集群内部相互通讯，如节点端口为700一、700二、7003，那么咱们还应该开启1700一、1700二、17003这些端口。

若是遇到搭建失败的状况，从新搭建的时候必定要到dir指向的文件夹中将快照和AOF还有node.conf文件删干净，不然没法从新搭建。

搭建完毕

至此咱们已经完成了Redis集群的搭建，在私下实践的时候能够试试使用Redis客户端直接操做集群时手动关闭某个Master，会出现什么样的情况，这个是文章中没有提到的内容。

什么是MySQL主从同步

数据是一个应用相当重要的一部分。从目的出发，主从同步有那么点备份的意思，主库（Master）将本身库中的写入同时同步给本身的从库（Slave），当主库发生某些不可预知的情况，致使整个服务器没法使用时，因为从库中也有一份数据，因此数据能够作到快速恢复，不形成或者减小形成数据的损失。

固然，这只是第一个层面，若是主从库的做用仅限于此，那么我我的认为没有必要分为两个数据库，只须要按期将数据库内容做为快照发送到另外一台服务器，或者每次写入时将写入内容实时发送到另外一台服务器不就行了吗，这样不但能够节约资源，也能够起到容灾备份的目的。

固然主从同步的做用毫不可能仅限于此，一旦咱们配置了主从结构，咱们一般不会让从节点仅仅只做为备份数据库，咱们应该还会相应地配置上读写分离（可使用MyCat或者其它中间件，能够本身了解一下，关于MyCat我在下一篇博客中会说这个，篇幅可能会有点长，因此就再写一篇吧）。

在实际环境下，对于数据库的读操做数目远大于对数据库的写操做，因此咱们可让Master只提供写的功能，而后将全部的读操做都移到从库，这就是咱们平时常说的读写分离，这样不但能够减轻Master的压力，还能够作容灾备份，一箭双雕。

MySQL主从同步的原理

说完了主从同步的概念，下面来讲说主从同步的原理，其实原理也很是简单，没有Redis集群那么多的概念。

实际上当咱们在MySQL中配置了主从以后，只要咱们对Master节点进行了写操做，这个操做将会被保存到MySQL的binary-log（bin-log）日志当中，当slave链接到master的时候，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，Master的dump线程会通知slave，并将相应的binlog内容发送给Slave。而Slave节点在主从同步开启的时候，会建立两个线程，一个I/O线程，一个SQL线程，这在咱们后面的搭建中能够亲眼看到。

  • I/0线程：该线程连接到master机器，master机器的binlog发送到slave的时候，IO线程会将该日志内容写在本地的中继日志（Relay log）中。
  • SQL线程：该线程读取中继日志中的内容，而且根据中继日志中的内容对Slave数据库作相应的操做。
  • 可能形成的问题：在写请求至关多的状况下，可能会形成Slave数据和Master数据不一致的状况，这是由于日志传输过程当中的短暂延迟、或者写命令较多，系统速度不匹配形成的。

这大体就是MySQL主从同步的原理，真正在其中起到做用的实际上就是这两个日志文件，binlog和中继日志。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

手动搭建MySQL主从同步

环境准备

本次搭建主从同步的环境：CentOS 7 ,MySQL 8.0.18（使用二进制包安装）。

场景介绍

本次将会搭建MySQL的主从同步，其中一台Master，两台Slave。

Master:IP :192.168.43.201 Port:3306
Slave1:IP:192.168.43.202 Port:3306
Slave2:IP:192.168.43.203 Port:3306

 

开始搭建

修改配置文件

当咱们安装好MySQL以后，在/etc/目录下会有一个my.cnf文件，打开文件，加入以下内容(别忘了修改以前作好备份)：

x

#该配置为Master的配置
server-id=201 #Server id 每台MySQL的必须不一样
log-bin=/var/lib/mysql/mysql-bin.log #表明开启binlog日志
expire_logs_days=10 #日志过时时间
max_binlog_size=200M #日志最大容量
binlog_ignore_db=mysql #忽略mysql库，表示不一样步此库

y

#该配置为Slave的配置,第二台Slave也是这么配置，不过要修改一下server-id
server-id=202
expire_logs_days=10 #日志的缓存时间
max_binlog_size=200M #日志的最大大小
replicate_ignore_db=mysql #忽略同步的数据库

新增Slave用户

打开Master节点的客户端 ，mysql -u root -p 密码

建立用户 create user 'Slave'@'%' identified by '123456';

给新建立的用户赋权：grant replication slave on '*.*' to 'Slave'@'%';

查看Master节点状态

以上操做都没有问题后，咱们在客户端中输入show master status查看master的binlog日志。

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

配置两个Slave节点

打开两个Slave节点客户端，在咱们的另外两个Slave节点中输入以下命令：

change master to master_user='Slave',master_password='123456',master_host='192.168.43.201',master_log_file='mysql-bin.000005',master_log_pos=155,get_master_public_key=1;
#注意，这里的master_log_file，就是binlog的文件名，输入上图中的mysql-bin.000005,每一个人的均可能不同。
#注意，这里的master_log_pos是binlog偏移量，输入上图中的155，每一个人的均可能不同。

 

配置完成后，输入start slave;开启从节点，而后输入show slave statusG;查看从节点状态

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

能够看到，在两台Slave的状态中，咱们能亲眼看到IO线程和SQL线程的运行状态，这两个线程必须都是yes，才算配置搭建完成。

搭建完成

经过上述步骤，就完成了MySQL主从同步的搭建，相对Redis而言MySQL配置至关简单。下面咱们能够进行测试。

先看看三个MySQL的数据库状态：SHOW DATABASES;

此次必定要教会你搭建Redis集群和MySQL主从同步(非Docker)

能够看到如今数据库都是初始默认状态，没有任何额外的库。

在Master节点中建立一个数据库，库名能够本身设置。

CREATE DATABASE testcluster;

能够看到，在Slave中也出现了Master中建立的数据库，说明咱们的配置没有问题，主从搭建成功。这里就再也不建立表了，你们能够本身试试，建立表再往表中插入数据，也是没有任何问题的。

注意事项

若是出现IO线程一直在Connecting状态，能够看看是否是三台机器没法相互链接，若是能够相互链接，那么有多是Slave帐号密码写错了，从新关闭Slave而后输入上面的配置命令再打开Slave便可。

若是出现SQL线程为NO状态，那么有多是从数据库和主数据库的数据不一致形成的，或者事务回滚，若是是后者，先关闭Slave，而后先查看master的binlog和position，而后输入配置命令，再输入set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;，再从新start slave;便可，如经过是前者，那么就排查一下是否是存在哪张表没有被同步，是否存在主库存在而从库不存在的表，本身同步一下再从新配置一遍便可。

结语

在写这篇文章以前本身也被一些计算机领域的“名词”吓到过，相信有很多同窗都有同样的体会，碰上某些高大上的名词老是先被吓到，例如像“分布式”、“集群”等等等等，甚至在没接触过nginx以前，连”负载均衡“、”反向代理“这样的词都让人以为，这么高达上的词，确定很难吧，但其实本身了解了nginx、ribbon等以后才发现，其实也就那么回事吧，没有想象中的那么难。

因此写这篇文章的初衷是想让你们对集群化或者分布式或者其余的一些技术或者解决方案不要有一种望而却步的感受（感受计算机领域的词都有这么一种特色，词汇高大上，可是其实思想是比较好理解的），其实本身手动配置出一个简单的集群并无那么难。

若是学会docker以后再来配置就更加简单了，可是更但愿不要只局限于会配置，配置出来的东西只能说你会配置了，可是在这层配置底下是前人作了至关多的工做，才能使咱们经过简单配置就能实现一些功能，应该要深刻底层，了解配置下面的工做原理，这个才是最重要的，也是体现一个程序员水平的地方。

 

最后，欢迎关注个人公众号： Java知音

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程