本文目录
linux配置系列之redis哨兵配置
很精辟的一段话,"未曾清贫难做人,不经打击永天真；成熟不过是善于隐藏,沧桑不过是无泪有伤。"
redis的主从配置比较容易，主从配置后，主主要进行写的操作,从主要进行读的操作,那么如果主挂了,是不是就没法进行写了？所以redis中可以进行哨兵的配置,具有高可用性，即是在主挂了之后,哨兵检测到后，会在从中进行投票,投票数多的晋升为主。这个配置可折腾我了，按照找的资料进行了哨兵的配置，可是当我把主服务停掉之后，从还在一致尝试连接主
启动哨兵日志
停掉主后从的日志
停掉后哨兵中,日志情况
就是这个问题我一直尝试找到解决办法，看了其中" sentinel-16379.conf"中的配置差不多，跟网上的一样。但是就是不行。 sentinel-16379.conf配置如下
这是我把这个配置文件的注释和空格都去掉后的结果 实际中我修改了如下几个配置
其他的可能都是自动生成的。当然你也可以自己指定日志位置。 auth-pass是因为我的主中做了配置密码了。***隐藏网址***
所以那为什么我的哨兵没有起作用了,最后我找了公司运维一起看,问题的原因就是我的从中的bind的这个属性没有做配置。
加上了这个，all done!!! 如果你直接使用
报错如下
因为bind只配置了10.10.39.105所以连接如下
哨兵启动结果
干掉主进程
哨兵的日志打印状况
从服务器的日志情况：
连接39.105设置数据如下
哨兵监控如下：
测试从是否可以设置数据
在主上设置数据
在从上get数据
三：问题说明 上面也说了，第一次没有成功的原因是因为bind问题
我尝试翻译下如下
redis和mysql主从配置怎么写
1.master可以有多个slave2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余5.可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。
redis主从+哨兵
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
首先配置Redis的主从服务器，修改redis.conf文件如下 主从服务器都需要配置
配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改
上述关闭了保护模式，便于测试。
Redis主从复制与一致性
数据的同步过程一般都涉及到全量数据的迁移以及后续增量数据的同步。 在主Master接收到SYNC命令之后，它会执行bgsave在后台生成一个RDB文件，并且使用一个缓冲区记录从现在开始执行所有写命令。当bgsave生成的RDB文件完成了之后，它就发送给从服务器去进行载入。在更新状态完成之后，Master再将记录在缓冲区里面的新命令发送给从服务器，这样从服务器进行执行，主从服务器就保持了一致状态。 从服务器到主服务器的复制可以分为两种情况: 为了解决SYNC在处理断线重复制时候的低效问题，Redis从2.8版本之后开始使用PSYNC命 令，它支持完整重同步和部分重同步。 完整重同步和SYNC一样，部分重同步就是在处理断 线重新连接之后，主节点只向从节点发送链接断开期间的写命令，它的实现基于以下三部分: 缺点： 注：上述所有场景的前提是数据依然保存在backlog中，否则还是会进行完全重同步。 如果slave可以收到每条传播指令，并执行成功，便可以保持与master的数据一致状态。但是master并不等待slave节点的返回，master与slave是通过网络通信，由于网络抖动等因 素，命令传播过程不保证slave真正接收到，那如何在传播阶段确保主从数据一致呢? 在命令传播阶段，每隔一秒slave节点向master节点发送一次心跳信息，命令格式为 REPLCONF ACK 《offset》。其中offset指从节点保存的复制偏移量。REPLCONF ACK命令的作用包括: 在全量复制阶段，主节点会将执行的写命令放到复制缓冲区中，该缓冲区存放的数据包括了以下几个时间段内主节点执行的写命令:bgsave生成RDB文件、RDB文件由主节点发往从 节点、从节点清空老数据并载入RDB文件中的数据。当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接;这种情况可能引起全量复制→复制缓冲区溢出导致连接中断→重连→全量复制→复制缓冲区溢出导致连接中断......的循环。 复制缓冲区的大小由client-output-buffer-limit slave{hard limit}{soft limit}{soft seconds}配 置，默认值为client-output-buffer-limit slave 256MB 64MB 60，其含义是:如果buffer大于 256MB，或者连续60s大于64MB，则主节点会断开与该从节点的连接。该参数是可以通过 config set命令动态配置的(即不重启Redis也可以生效)。 Redis为复制积压缓冲区设置的默认大小为1MB，如果主服务器需要执行大量写命令，又或者主从服务器断线后重连接所需的时间比较⻓，那么这个大小也许并不合适。如果复制积压 缓冲区的大小设置得不恰当，那么PSYNC命令的复制重同步模式就不能正常发挥作用，正确估算和设置复制积压缓冲区的大小非常重要。 复制积压缓冲区的最小大小可以根据公式second*write_size_per_second 来估算:
