一、环境准备

搭建俩台Redis相同的数据库，Redis数据库搭建请参考：https://www.jianshu.com/p/204dcfc4d0ab；

1.环境说明

安装包存放路径：/server/tools
配置文件：/opt/redis_6379/conf/redis_6379.conf
应用软件包路径：/opt/redis（软连接文件）
数据存储路径：/data/redis_6379
Redis主数据库：db01:10.0.0.51
Redis从数据库：db02:10.0.0.52

2.测试数据生成

使用脚本或命令在主数据库中插入key，从数据库为无数据的状态，并且此时主从数据库均不开启认证功能
db01：

for i in `seq 1000`;do redis-cli set k$i v$i;done
redis-cli 
127.0.0.1:6379> DBSIZE
(integer) 1000

cat /opt/redis_6379/conf/redis_6379.conf|grep "^#r"
#requirepass "123456"

db02：

cat /opt/redis_6379/conf/redis_6379.conf|grep "^#r"
#requirepass "123456"

redis-cli 
127.0.0.1:6379> DBSIZE
(integer) 0

二、主从复制命令

1.主从复制开启

方法1:临时生效：SLAVEOF 主库IP地址 端口号

SLAVEOF 10.0.0.51 6379
127.0.0.1:6379> SLAVEOF 10.0.0.51 6379
OK
127.0.0.1:6379> DBSIZE
(integer) 1000

说明：在主从复制过程中是由从库起始发出请求信息，因此临时开启的命令需要在从库上进行

方法2:写入配置文件

说明：当临时开启主从复制后，再将从库的Redis数据库关闭，此时重新启动数据库后，主从复制关系取消，如图所示：

image.png
因此，使Redis数据库永久生效需在配置文件中添加参数

### 以守护进程模式启动，在后台运行
daemonize yes
### 绑定的主机地址
bind 10.0.0.52 127.0.0.1
### 监听端口
port 6379
### pid文件和log文件的保存地址
pidfile /opt/redis_6379/pid/redis_6379.pid
logfile /opt/redis_6379/logs/redis_6379.log
### 设置数据库的数量，默认数据库为0
databases 16
### 指定本地持久化文件的文件名,默认是dump.rdb
dbfilename redis_6379.rdb
### 本地数据库的目录
dir /data/redis_6379
### 触发RBD持久化保存条件
#900S内有一个key生成触发RDB快照持久化
save 900 1
#300S内有十个key生成触发RDB快照持久化
save 300 10
#60S内有一万个key生成触发RDB快照持久化
save 60 10000
### 开启AOF独立日志持久化功能
##设置AOF独立日志名称
appendfilename "redis_6379.aof"
##AOF持久化功能开关
appendonly yes
##AOF重写时间设置--everysec每秒重写 
appendfsync everysec
##AOF回写机制算法及触发条件，默认AOF文件大小超过64MB时触发
#auto-aof-rewrite-percentage 100
#auto-aof-rewrite-min-size 64mb
###永久开启主从复制
SLAVEOF 10.0.0.51 6379
### 登陆密码
#requirepass "123456"

2.取消同步命令：

10.0.0.52:6379> SLAVEOF no one
OK

说明：当从库开启主从复制后，从库就不具备写或删除的权限，变为只读权限，而当主库发生故障时，从库会不断的一直向主库发生连接请求，不会自动识别主库宕机的问题，因此此时需要手动取消同步，使得从库恢复单节点状态，变为可读可写

10.0.0.52:6379> SLAVEOF 10.0.0.51 6379
OK
10.0.0.52:6379> 
10.0.0.52:6379> set kc vc
(error) READONLY You can't write against a read only slave.
10.0.0.52:6379> get ka
"va"
10.0.0.52:6379> del  ka
(error) READONLY You can't write against a read only slave.

生产环境中正是因为这个缺陷，导致Redis数据库主从复制应用场景极少，为了改善这个缺陷，Redis哨兵概念产生。

3.主从复制流程:

从库发起同步请求
11:55:12.686 * Connecting to MASTER 10.0.0.51:6379
11:55:12.687 * MASTER <-> SLAVE sync started
11:55:12.687 * Non blocking connect for SYNC fired the event.
11:55:12.687 * Master replied to PING, replication can continue...
11:55:12.688 * Partial resynchronization not possible (no cached master)
11:55:12.690 * Full resync from master: c63b80909e49adfa3880dcc87ccffb89d148a564:436

主库接收请求
11:55:12.694 * Slave 10.0.0.52:6379 asks for synchronization
11:55:12.694 * Full resync requested by slave 10.0.0.52:6379

主库开始BGSAVE
11:55:12.694 * Starting BGSAVE for SYNC with target: disk
11:55:12.695 * Background saving started by pid 13009
（生成子进程开始进行BGSAVE，持久化操作）
11:55:12.700 * DB saved on disk
11:55:12.700 * RDB: 6 MB of memory used by copy-on-write

从库接收主库的数据,清空自己的数据,然后将主库发送过来的RDB文件加载到内存中
11:55:12.780 * MASTER <-> SLAVE sync: receiving 12887 bytes from master
11:55:12.781 * MASTER <-> SLAVE sync: Flushing old data
（刷新以前的数据，此时正在进行清空从库数据操作）
11:55:12.781 * MASTER <-> SLAVE sync: Loading DB in memory
（将从主库复制来的RBD文件写入到内存中，生成数据）
11:55:12.782 * MASTER <-> SLAVE sync: Finished with success

主库接收从库消息,主从复制成功
11:55:12.786 * Background saving terminated with success
11:55:12.786 * Synchronization with slave 10.0.0.52:6379 succeeded
注意：在进行主从复制的过程中，由于从库会进行清空旧数据的操作，因此在手动执行临时开启主从复制的同时，一定要注意是否在从库上开启的，否则会导致，主库清空数据，后果严重。