redis主从和哨兵

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；

b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

c,查看状态：info replication

d,断开主从复制：在slave节点，执行6380:>slaveof no one

e,断开后再变成主从复制：6380:>slaveof 192.168.152.128 6379

f,数据较重要的节点，主从复制时使用密码验证： requirepass

e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致

h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭

参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，

参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制

全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）

部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步

心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主

b)主从复制主节点的写能力单机，能力有限

c)单机节点的存储能力也有限

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；

b)其它的节点成为新主节点的从节点，并从新节点复制数据；

c)需要人工干预，无法实现高可用。

1. 为什么要有哨兵机制？

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线 *** 作，也就说是客观下线

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

1. 将slave-1脱离原从节点，升级主节点，

d) 故障转移后的redis sentinel的拓扑结构图

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

1. 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：

A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：

修改 requirepass 12345678，注释掉#bind 127.0.0.1

B) 从节点redis6380.conf和redis6381.conf: 配置都一样

修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,

加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379

2. redis sentinel哨兵机制核心配置 (也是3个节点)：

将三个文件的端口改成: 26379 26380 26381

然后：sentinel monitor mymaster 192.168.152.128 6379 2 //监听主节点6379

三个配置除端口外，其它一样。

3. 哨兵其它的配置 ：只要修改每个sentinel.conf的这段配置即可：

sentinel monitor mymaster 192.168.152.128 6379 2

//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码

sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA **180000 **//故障转移超时时间180s，

a,如果转移超时失败，下次转移时时间为之前的2倍；

b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败

c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

4. 启动redis服务和sentinel服务:

a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件

b)启动主从复制服务，先启动主再启动从

主：./redis-server conf/redis6379.conf &

从：

./redis-server conf/redis6380.conf &

./redis-server conf/redis6381.conf &

c）启动sentinel服务:

./redis-sentinel conf/sentinel_26381.conf &

到此服务全部启动完毕

连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点

5. 测试： kill -9 6379 杀掉6379的redis服务

可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点

重新启动6379以后变为6380的从节点

看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:进入6380>info replication 可以看到role:master

打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2

打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380

注意：生产环境建议让redis Sentinel部署到不同的物理机上。

a，sentinel节点应部署在多台物理机（线上环境）

b，至少三个且奇数个sentinel节点

c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点

sentinel参考资料：

redis sentinel的机制与用法一： https://segmentfault.com/a/1190000002680804

redis sentinel的机制与用法二： https://segmentfault.com/a/1190000002685515

Slave_IO_Running,一个负责与主机的io通信,一个负责自己的slave mysql进程.

下面写一下,这两个要是有no了,怎么恢复.

如果是slave_io_running no了,那么就我个人看有三种情况,一个是网络有问题,连接不上,像有一次我用虚拟机搭建replication,使用了nat的网络结构,就是死都连不上,第二个是有可能my.cnf有问题,配置文件怎么写就不说了,网上太多了,最后一个是授权的问题,replication slave和file权限是必须的.如果不怕死就all咯.

一旦io为no了先看err日志,看看爆什么错,很可能是网络,也有可能是包太大收不了,这个时候主备上改max_allowed_packet这个参数.

如果是slave_sql_running no了,那么也有两种可能,一种是slave机器上这个表中出现了其他的写 *** 作,就是程序写了,这个是会有问题的,今天我想重现,但是有时候会有问题,有时候就没有问题,现在还不是太明了,后面再更新,还有一种占绝大多数可能的是slave进程重启,事务回滚造成的,这也是mysql的一种自我保护的措施,像关键时候只读一样.

这个时候想恢复的话,只要停掉slave,set GLOBAL SQL_SLAVE_SKIP_COUNTER=1再开一下slave就可以了,这个全局变量赋值为N的意思是：

This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.

This statement is valid only when the slave thread is not running. Otherwise, it produces an error.

呵呵,讲的比我清楚.

MYSQL镜像服务器因错误停止的恢复

下午主服务器,由于一些原因,导致死机,重启后,发现从服务器的数据没有跟上.

配好MYSQL主从也才前几天的事,没多少经验,第一次碰上这问题,有点焦急.不过,自己试了下,还算解决了：）

从服务器上

Master_Log_File: mysqlhxmaster.000007

Read_Master_Log_Pos: 84285377

看一下主服务器：mysqlhxmaster.000007 | 84450528 |

已经过后很多了,确实没跟上.

show slave status\G

Slave_IO_Running: Yes

Slave_SQL_Running: No

有问题了,Slave_SQL_Running应该是Yes才对.

再往下看,有错误的提示：

Last_Errno: 1053

Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1START SLAVE. Query: 'INSERT INTO hx_stat_record .(一句SQL语句)'

这里有说明要怎么 *** 作了：）

先stop slave,然后执行了一下提示的语句,再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1START SLAVE

show slave status\G

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

OK了,从服务器也在几分钟内把堆积的log处理完了,两边又同步了：)

从MYSQL服务器Slave_IO_Running: No的解决2

早晨机房意外断电,导致了发现mysql从服务器同步异常.使用以前碰到的Slave_SQL_Running为No的解决办法无效,仍然无法同步.

查看一下状态show slave status

Master_Log_File: mysqlmaster.000079

Read_Master_Log_Pos: 183913228

Relay_Log_File: hx-relay-bin.002934

Relay_Log_Pos: 183913371

Relay_Master_Log_File: mysqlmaster.000079

Slave_IO_Running: No

Slave_SQL_Running: Yes

主服务器show master status\G

File: mysqlmaster.000080

Position: 13818288

Binlog_Do_DB:

Binlog_Ignore_DB: mysql,test

mysql错误日志：

100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371

100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228

100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)

100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log

100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228

这次是Slave_IO_Running为No,从日志上来看,服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误,这个位置不存在,于是无法同步.

查看一下这个Log的最后几行：

/*!40019 SET @@session.max_insert_delayed_threads=0*/

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/

# at 4

#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15

# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.

尝试从损坏之前的位置开始

SLAVE STOP

CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220

SLAVE START

无效!

只好从新的日志开始

SLAVE STOP

CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0

SLAVE START

此时Slave_IO_Running恢复为Yes,同步进行了!观察了会儿,没有任何出错迹象,问题解决.

另外,出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据. 您可能感兴趣的文章:

mysql主从同步复制错误解决一例

win2003 安装2个mysql实例做主从同步服务配置

Mysql主从同步备份策略分享

windows环境下mysql数据库的主从同步备份步骤(单向同步)

mysql主从同步快速设置方法

MySQL 数据库双向镜像、循环镜像(复制)

Mysql 主从数据库同步(centos篇)

解读mysql主从配置及其原理分析(Master-Slave)

mysql SKIP-NAME-RESOLVE 错误的使用时机造成用户权限

mysql 有关“InnoDB Error ib_logfile0 of different size”错误

MYSQL同步 Slave_IO_Running: No 或者Slave_SQL_Running: No的解决方法[已测]

Windows mysql 双向同步设置方法 详细篇

win2003 mysql单向同步配置步骤[已测]

项目上 MySQL 还原 SQL 备份经常会碰到一个错误如下，且通常出现在导入视图、函数、存储过程、事件等对象时，其根本原因就是因为导入时所用账号并不具有SUPER 权限，所以无法创建其他账号的所属对象。ERROR 1227 (42000) : Access deniedyou need (at least one of) the SUPER privilege(s) for this operation常见场景：1. 还原 RDS 时经常出现，因为 RDS 不提供 SUPER 权限；2. 由开发库还原到项目现场，账号权限等有所不同。

处理方式：

1. 在原库中批量修改对象所有者为导入账号或修改 SQL SECURITY 为 Invoker；2. 使用 mysqldump 导出备份，然后将 SQL 文件中的对象所有者替换为导入账号。

二、问题原因我们先来看下为啥会出现这个报错，那就得说下 MySQL 中一个很特别的权限控制机制，像视图、函数、存储过程、触发器等这些数据对象会存在一个 DEFINER 和一个 SQL SECURITY 的属性，如下所示：

--视图定义CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW v_test

--函数定义CREATE DEFINER=`root`@`%` FUNCTION `f_test()` RETURNS varchar(100) SQL SECURITY DEFINER

--存储过程定义CREATE DEFINER=`root`@`%` PROCEDURE `p_test`() SQL SECURITY DEFINER

--触发器定义CREATE DEFINER=`root`@`%` trigger t_test

--事件定义CREATE DEFINER=`root`@`%` EVENT `e_test`

DEFINER：对象定义者，在创建对象时可以手动指定用户，不指定的话默认为当前连接用户；

SQL SECURITY：指明以谁的权限来执行该对象，有两个选项，一个为 DEFINER，一个为 INVOKER，默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行； INVOKER：表示按调用者的权限来执行。

如果导入账号具有 SUPER 权限，即使对象的所有者账号不存在，也可以导入成功，但是在查询对象时，如果对象的 SQL SECURITY 为 DEFINER，则会报账号不存在的报错。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist

三、改写内容上述这个 DEFINER 问题，个人想到最简单的解决方式就是 mysqldump 导出时直接摘除掉相关属性，但是 mysqldump 本身并不提供对应参数，所以比较蛋疼，无论是原库走脚本变更或是备份后修改 SQL 文件都不是非常方便，尤其是触发器的 DEFINER，只能先 DROP 再 CREATE 才可以变更。只能看下是否可以从 mysqldump 源码中去掉 DEFINER 定义。本次 mysqldump 改写主要有 2 个目的：1. 摘取备份中视图、函数、存储过程、触发器等对象的 DEFINER 定义；2. 尝试加上比较简单的备份进度显示（原生 mysqldump 的 verbose 参数不是非常清晰，想要实现 navicate 备份时的那种行数显示）。

改写好处：1. 可以避免还原时遇到 DEFINER 报错相关问题；2. 根据输出信息知道备份是否正常进行，防止备份中遇到元数据锁无法获取然后一直卡住的情况。

---