redis基础：8、主从复制

是什么？

主机数据更新后根据配置和策略，自动同步到备机的master/salve机制。Master以写为主，Slave以读为主。

能干嘛？

• 读写分离
• 容灾恢复

怎么玩之一主二仆

1、配从不配主

2、从库配置：slaveof 主库ip 主库端口

每次与master断开之后，都需要重新连接，除非配置进redis.conf文件

3、修改配置文件细节操作

•  cp redis.conf redis6379.conf
   cp redis.conf redis6380.conf
   cp redis.conf redis6381.conf
  

  然后将三个配置文件的port、pidfile、logfile、dbfilename分别修改或添加为6379、6380、6381

•  [79]终端
   redis-server /opt/redis-3.0.4/redis6379.conf
   redis-cli -p 6379
   
   [80]终端
   redis-server /opt/redis-3.0.4/redis6380.conf
   redis-cli -p 6380
   
   [81]终端
   redis-server /opt/redis-3.0.4/redis6381.conf
   redis-cli -p 6381
  

4、修改80、81的主从关系

[80]
slaveof 127.0.0.1 6379

[81]
slaveof 127.0.0.1 6379

可以使用info replication查看主从关系：

主机的replication信息：

从机的replication信息：

5、发现[80][81]里面有[79]中保存的数据。并且往[79]中写的数据，在[80][81]中都能get到，但是[80][81]不能写数据了。

6、发现：如果主机掉线，从机会等待主机上线，并依然保持slave模式，主机上线后，依然保持原先的状态运行；如果从机掉线，主机失去了那个从机，尽管从机再次上线，依然连接不上主机，且已经退出了slave模式，除非重新连接上主机。

怎么玩之薪火相传

啥意思？

前一个输入slave可以是下一个slave的master，slave同样可以接受其它slave的连接和同步请求，那么该slave作为链条中下一个的master，可以有效减轻master的写压力。

中途变更转向：

会清除之前的数据，重新建立拷贝最新的。

现在，我们让[79]作为[80]的主机，[80]作为[81]的主机

[81]
slaveof 127.0.0.1 6380

可以看到[80]这个时候既作为了主机，也作为了从机

怎么玩之反客为主

假设现在是一仆二主的模式，我们让[80]成为新主机：

[80]
slaveof no one

这段命令的作用是使当前数据库停止与其它数据库的同步，转成为主数据库

复制原理

• Slave启动成功并连接到master后会发送一个sync命令
• master接到命令启动后台的存盘进程，执行完毕后传送整个数据文件到slave，以完成一次完全同步。
• 全量复制：将目前的所有数据发送给slave
• 增量复制：将新的修改命令传给slave，以完成同步
• slave首次连接到master，启动全量复制，之后使用增量复制。

哨兵模式（sentinel）

1、是什么

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

2、怎么玩

• 调整结构，6379带着80、81

• 在redis文件夹下新建sentinel.conf文件，名字不能取错

• 填写内容：sentinel monitor [被监控数据库的名字（自己起）] 127.0.0.1 6379 1。这里的数字1表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机。

• 启动哨兵：redis-sentinel /opt/redis-3.0.4/sentinel.conf

• 把79主机强行下线：

  哨兵开始组织投票

• 查看80的info replication发现它上位成老大了！！
  

• 查看81的info replication发现它成了80的走狗了！！
  

• 搞笑的事情发生了！！！现在将79服务器重新上线，发现它变成80的走狗了！！

缺点

• 延时：由于所有的写操作都是先在Master上操作的，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延时，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。