redis演练(6) redis复制（主备模式）

redis是一款面向分布式的Nosql产品，天生对主备模式有很好的支持，而且配置一套完整的主备模式，非常简单。针对redis，主备模式配置非常简单，但线上意义重大。

主要内容

1.CAP理论

2.简单redis的复制原理

3.redis replaction相关配置参数解析

4.配置星型模型主备模式

5.配置有向无欢模型主备模式

1.研磨redis的复制与集群概念

redis的复制与集群，刚开始我把两者闹了个误会，在不断深入学习过程中及时改正了。

简单区分一下。

redis复制：可以理解为把redis服务copy多份，供客户端访问。但服务器间持有的数据时一样的。可以类比下oracle的RAC，和mysql数据库中的主备模式。主要解决redis服务的可靠性，扩展性上。

redis集群：集群主要解决大数据量问题。一个机器内存和存储往往是有限的，但数据量的增长往往是“无限”的，可以使用集群，将数据分散到多个redis服务中。如果你能想到memcached的一致性哈希算法，那就对了。

不管redis 复制核集群，都会涉及到节点信息的同步，不得不要受到CAP理论的影响。

2.CAP理论介绍

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer‘s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

  • 一致性（Consistence) （等同于所有节点访问同一份最新的数据副本）
  • 可用性（Availability）（对数据更新具备高可用性）
  • 容忍网络分区（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[3]。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[4]。

redis 的设计和配置，也是在尽量解决CAP引起的问题，但不可能彻底决绝，只能在三者中进行平衡。

3.Redis复制概论

数据库复制指的是发生在不同数据库实例之间，单向的信息传播的行为，通常由被复制方和复制方组成，被复制方和复制方之间建立网络连接，复制方式通常为被复制方主动将数据发送到复制方，复制方接收到数据存储在当前实例，最终目的是为了保证双方的数据一致、同步。

复制示意图

Redis的复制方式有两种，一种是主（master）-从（slave）模式，一种是从（slave）-从（slave）模式，因此Redis的复制拓扑图会丰富一些，可以像星型拓扑，也可以像个有向无环：


Redis集群复制结构图
通过配置多个Redis实例独立运行、定向复制，形成Redis集群（这儿集群的概念是广义上的概念），master负责写、slave负责读。

通过复制，可以达成以下目标

1、高可用性(如果master宕机，slave可以介入并取代master的位置)
2、高性能(主备分离，分担master压力)
3、水平扩展性(按二八定律，增加slave机器可以横向（水平）扩展Redis服务的整个查询服务的能力)

带来的问题：

1.同步开销
2.数据不一致性问题
3.编程复杂

4.redis replaction相关配置参数解析

slaveof <masterip> <masterport> #设置该数据库为其他数据库的从数据库时启用该参数。
#设置当本机为slave服务时，设置 master 服务的 IP 地址及端口，在 Redis 启动时，它会自动从 master 进行数据同步
slave-serve-stale-data yes #当从库同主机失去连接或者复制正在进行，从机库有两种运行方式：
#1)如果 slave-serve-stale-data 设置为 yes( 默认设置 ) ，从库会继续响应客户端的请求
#2)如果 slave-serve-stale-data 是指为 no ，出去 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误 "SYNC with master in progress"
slave-read-only yes #配置 slave 实例是否接受写。写 slave 对存储短暂数据（在同 master数据同步后可以很容易地被删除）是有用的，但未配置的情况下，客户端写可能会发送问题。
repl-ping-slave-period 10 #从库会按照一个时间间隔向主库发送 PINGs. 可以通过 repl-ping-slave-period 设置这个时间间隔，默认是 10 秒
repl-timeout 60 #repl-timeout  设置主库批量数据传输时间或者 ping 回复时间间隔，默认值是 60 秒
# 一定要确保 repl-timeout 大于 repl-ping-slave-period
repl-diskless-sync no 启动无磁盘复制。往备节点同步，不需要中间先生成文件再进行同步。
repl-diskless-sync-delay 5
同步前的延时, 以等待其他的要链接的slave

配置传输开始的延迟时间，以便等待更多的从服务器连接
repl-disable-tcp-nodelay no #在 slave socket 的 SYNC 后禁用 TCP_NODELAY
#如果选择“ yes ” ,Redis 将使用一个较小的数字 TCP 数据包和更少的带宽将数据发送到 slave ， 但是这可能导致数据发送到 slave 端会有延迟 , 如果是 Linux kernel 的默认配置，会达到 40 毫秒 .
#如果选择 "no"，则发送数据到 slave 端的延迟会降低，但将使用更多的带宽用于复制.
repl-backlog-size 1mb #设置复制的backlog(后台日志)大小。
#复制的后台日志越大， slave 断开连接及后来可能执行部分复制花的时间就越长。
#后台日志在至少有一个 slave 连接时，仅仅分配一次。
repl-backlog-ttl 3600 #在 master 不再连接 slave 后，后台日志将被释放。下面的配置定义从最后一个 slave 断开连接后需要释放的时间（秒）.#0意味着从不释放后台日志
slave-priority 100 #如果 master 不能再正常工作，那么会在多个 slave 中，选择优先值最小的一个 slave 提升为 master ，优先值为 0 表示不能提升为 master
min-slaves-to-write 0
执行写操作所需的至少从服务器数量

#如果少于 N 个 slave 连接，且延迟时间 <=M 秒，则 master 可配置停止接受写操作。

#例如需要至少 3 个 slave 连接，且延迟 <=10 秒的配置：
#设置 0 为禁用
min-slaves-max-lag 10 指定网络延迟的最大值

上面所列参数，虽然对本文涉及的内容一 一不大，但对运维和调优却非常重要。

4.配置星型模型主备模式

#为了区分，有的不需要指定，我也进行了修改。

#主(Master)节点,开启AOF,禁用RDB
port 6379
pidfile /var/run/redis_6379.pid
logfile "redis6379.log"
save 900 1
save 300 10
save 60 10000
save ""
dbfilename dump6379.rdb

appendonly yes
appendfilename "appendonly6379.aof"

------------------------------------------------
#备(Slaver1)节点,开启RDB,禁用AOF
port 6380
pidfile /var/run/redis_6380.pid
save 900 1
save 300 10
save 60 10000
dbfilename dump6380.rdb
logfile "redis6380.log"
appendonly no
appendfilename "appendonly6380.aof"
slaveof 127.0.0.1 6379
----------------------------------------------------
#备(Slaver2)节点,禁用RDB,禁用AOF
port 6381
pidfile /var/run/redis_6381.pid
logfile "redis6381.log"
save 900 1
save 300 10
save 60 10000
save ""
dbfilename dump6381.rdb
appendonly no
appendfilename "appendonly6381.aof"
slaveof 127.0.0.1 6379

#配置完了三个配置文件，启动
[[email protected] redis]# bin/redis-server  redis.conf 
[[email protected] redis]# bin/redis-server  redis6380.conf 
[[email protected] redis]# bin/redis-server  redis6381.conf

查看Master(6379)日志

[[email protected] redis]# cat redis6381.log
2925:M 03 Sep 20:53:44.398 * The server is now ready to accept connections on port 6379
2925:M 03 Sep 20:53:55.042 * Slave 127.0.0.1:6380 asks for synchronization
2925:M 03 Sep 20:53:55.042 * Full resync requested by slave 127.0.0.1:6380
2925:M 03 Sep 20:53:55.042 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:55.043 * Background saving started by pid 2933
2933:C 03 Sep 20:53:55.055 * DB saved on disk
2933:C 03 Sep 20:53:55.055 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:55.106 * Background saving terminated with success
2925:M 03 Sep 20:53:55.106 * Synchronization with slave 127.0.0.1:6380 succeeded
2925:M 03 Sep 20:53:57.772 * Slave 127.0.0.1:6381 asks for synchronization
2925:M 03 Sep 20:53:57.772 * Full resync requested by slave 127.0.0.1:6381
2925:M 03 Sep 20:53:57.772 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:57.772 * Background saving started by pid 2938
2938:C 03 Sep 20:53:57.784 * DB saved on disk
2938:C 03 Sep 20:53:57.785 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:57.833 * Background saving terminated with success
2925:M 03 Sep 20:53:57.833 * Synchronization with slave 127.0.0.1:6381 succeeded

查看Slave1(6380)日志

[[email protected] redis]# cat redis6380.log
2930:S 03 Sep 20:53:55.041 * The server is now ready to accept connections on port 6380
2930:S 03 Sep 20:53:55.041 * Connecting to MASTER 127.0.0.1:6379
2930:S 03 Sep 20:53:55.042 * MASTER <-> SLAVE sync started
2930:S 03 Sep 20:53:55.042 * Non blocking connect for SYNC fired the event.
2930:S 03 Sep 20:53:55.042 * Master replied to PING, replication can continue...
2930:S 03 Sep 20:53:55.042 * Partial resynchronization not possible (no cached master)
2930:S 03 Sep 20:53:55.043 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2930:S 03 Sep 20:53:55.106 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Flushing old data
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Loading DB in memory
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Finished with success

查看Slave2(6381)日志

[[email protected] redis]# cat redis6381.log

2935:S 03 Sep 20:53:57.771 * The server is now ready to accept connections on port 6381
2935:S 03 Sep 20:53:57.771 * Connecting to MASTER 127.0.0.1:6379
2935:S 03 Sep 20:53:57.771 * MASTER <-> SLAVE sync started
2935:S 03 Sep 20:53:57.771 * Non blocking connect for SYNC fired the event.
2935:S 03 Sep 20:53:57.771 * Master replied to PING, replication can continue...
2935:S 03 Sep 20:53:57.771 * Partial resynchronization not possible (no cached master)
2935:S 03 Sep 20:53:57.772 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Flushing old data
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Loading DB in memory
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Finished with success
[[email protected] redis]# cat redis6382.log

通过查看日志，可以很形象的学习底层实现过程。

测试（通过复制，修改值确认是否同步）

[[email protected] redis]# bin/redis-cli -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set title "replaction"
OK
127.0.0.1:6379> exit

[[email protected] redis]# bin/redis-cli -p 6380
127.0.0.1:6380> keys *
1) "title"
127.0.0.1:6380> get title
"replaction"

[[email protected] redis]# bin/redis-cli  -p 6381
127.0.0.1:6381> keys *
1) "title"
127.0.0.1:6381> get title
"replaction"
127.0.0.1:6381> set title 111
(error) READONLY You can‘t write against a read only slave.

修改下值
127.0.0.1:6379> set title "replaction 1"
OK
127.0.0.1:6380> get title
"replaction 1"
127.0.0.1:6381> get title
"replaction 1"

验证通过

5.配置有向无欢模型主备模式

基本上和星型模型主备模式，没有差别。

变更点
#备(Slaver2)节点,禁用RDB,禁用AOF
slaveof 127.0.0.1 6379 改为 slaveof 127.0.0.1 6380

测试略

参考资源

http://my.oschina.net/andylucc/blog/683631

时间： 2024-08-03 21:59:43

redis演练(6) redis复制（主备模式）的相关文章

3.redis单节点及主备模式

1.单节点模式 单节点模式的配置,使用redis通用配置即可. (1)启动命令: 1 /path/to/redis-server /path/to/redis-6379.conf 注:配置文件名称只是示例,一般一台机器不止启动一个redis实例,使用端口区分配置文件是比较好的方式 (2)关闭命令: 1 /path/to/redis-cli -h <host> -p <port> -a '<password>' shutdown save 注:建议不要直接kill进程,会

测试redis+keepalived实现简单的主备切换

转自: 测试redis+keepalived实现简单的主备切换 - Try My Best 尽力而为 - ITeye技术网站http://raising.iteye.com/blog/2311757 keepalived是一个是集群管理中保证集群高可用的一个服务软件,它具备心跳检测的功能.运用在redis上,则是具备主备切换的控制功能. keepalived的主备切换方案的设计思想如下: 当 Master 与 Slave 均运作正常时, Master负责服务,Slave负责Standby: 当 

redis演练(7) redis Sentinel实现故障转移

书接上文<redis演练(6) redis主从模式搭建>. <redis演练(6) redis主从模式搭建>中仅仅配置了redis主从环境.分别配置了2个主从结构. 分别是1.有向无环,2星型模型.配置起来非常简单.但是,遗留了一个尾巴,没有阐述.如果master宕掉了怎么办?redis如何实现fail-over故障转移?本文,就重点说一下这块.主要内容 手动实现fail-over效果 sentinel实现自动fail-over效果 手动实现fail-over效果 #有向无环模型(

redis演练(9) redis Cluster 集群管理&failover情况

<redis演练(8) redis Cluster 集群环境安装>,简单阐述了如何安装redis集群环境. 集群环境,主要包括2部分. 1.配置每个节点的配置信息(redis.conf),尤其开启cluster 2.创建集群redis-trib.rb创建集群. 过程非常简单,但非常繁琐,尤其配置各个集群节点的配置信息,如果有一定数量,工作量也不小. 没关系,redis提供了一款cluster工具,能快速构造集群环境.本章的主要内容是介绍redis提供的集群工具. 1.使用create-clus

L10 keepalived 基本使用(主备模式)

配置keepalive基本主备模式 配置说明: 要求默认情况下由节点node1提供服务,当节点node1不可用时,由节点node2提供服务(即虚拟IP漂移至节点node2). 节点node1 192.168.0.20 (主节点) 节点node2 192.168.0.21(备用节点) 虚拟IP(对外提供服务的IP 192.168.0.60 ping node 192.168.0.22(用于节点自身状态监测) 内容: 1,节点node1上的配置文件 2,节点node2配置 3,使用脚本防止脑裂. 4

centos6上实现双网卡绑定-主备模式

网卡绑定,将多块物理网卡绑定,对外呈现为一块逻辑网卡.这样做的好处一是增加带宽,二是提供冗余增加安全性.一般多用棱块网卡做绑定. 常见的网卡绑定模式有如下三种: mode0:轮询链路 mode1:主备链路 node3:广播链路 绑定后多块网卡对外提供一个ip地址个一个mac地址 本实验中以model1为例进行操作: 第1步: 在/etc/sysconfig/network-scripts/目录下创建绑定网卡文件,如 ifcfg-bond0 第2步; 编辑ifcfg-bond0 DEVICE=bo

Linux RHEL6.4绑定双网卡主备模式

1.查看服务器版本 lsb_release -a 2.然后进入网卡信息目录:cd /etc/sysconfig/network-scripts 3.接着我们要新建一个文件,文件名为ifcfg-bond0,可以通过三种方式来创建. (vi ifcfg-bond0; touch ifcfg-bond0; cp ifcfg-eth0 ifcfg-bond0)这里我选择最后一种 执行 cp ifcfg-eth0 ifcfg-bond0 后在 /etc/sysconfig/network-scripts目

CentOS6.5和CentOS7.0双网卡主备模式配置

双网卡主备模式配置(bond0) 1     简述 通过双网卡设置主备模式,实现当一块网卡宕掉时,另外一块网卡可以自动顶替宕掉的网卡工作,保障网络正常访问. 2     实现 2.1.  查看网卡信息 执行ifconfig -a命令 2.2.  修改网卡配置文件 切换工作目录 cd /etc/sysconfig/network-scripts/ 修改网卡配置文件ifcfg-eth0 ,保证以下几项内容正确: TYPE=Ethernet BOOTPROTO=dhcp ONBOOT=yes MAST

【 Keepalived 】Nginx or Http 主-备模式

一.主-备模式: 操作系统:centos 6.4 x64 ka1: 192.168.2.10 ka2: 192.168.2.11 vip: 192.168.2.200 ka1-master服务器配置 [ka1 [email protected]192.168.2.10 ~]#yum install httpd keepalived -y # 这里使用apache代替nginx,效果是一样的,然后直接yum安装keepalived [ka1 [email protected]192.168.2.1