NoSQL主从复制、持久化

主从赋值结构模式

主从复制工作原理

• 工作原理
  -slave向master发送sync命令
  -master启动后台存盘进程,并收集所有修改数据命令
  -master完成后台存盘后,传送整个数据文件到Slave
  -Slave接收数据文件,加载到内存中完成首次完全同步
  -后续有新数据产生时,master继续收集数据修改命令依次传给slave,完成同步.

配置主从复制

• 配置从库
  -Redis服务运行后,默认都是master服务器

192.168.4.52:6352> info replication  //查看赋值信息

#Replication

role: //角色
master_host: //主库ip地址
master_port: //主库端口号
master_link_status: //与主库连接状态

[root@redis52~]# redis-cli -h 192.168.4.52
192.168.4.52:6352> slaveof 192.168.4.51 6351 //命令行配置
OK

]# vim /etc/redis/6379.conf
slaveof 192.168.4.51:6351 //永久配置

• 反客为主
  -将从库恢复为主库

[root@redis52~]# redis-cli -h 192.168.4.52
192.168.4.52:6352> slaveof no one //命令行临时设置
OK
]# vim /etc/redis/6379.conf
 #slaveof 192.168.4.51:6351 //永久设置

配置带验证的主从复制

• 配置master
  -设置连接密码,重启服务
  ]# sed -n ‘501p’ /etc/redis/6379.conf
  requirepass 123456 //定义连接密码
• 配置slave
  -设置连接密码,重启服务
  ]# vim +289 /etc/redis/6379.conf
  masterauth 123456 //主库密码

哨兵服务

• 哨兵服务介绍
  -监视master服务器
  -发现maste宕机后,将从服务器升级为主服务器
  -主配置文件 sentinel.conf
  -模板文件:redis-4.0.8/sentinel.conf
  
• 配置哨兵服务
  -创建主配置文件
  -启动服务

]# vim /etc/sentinel.conf
     sentinel monitor server51(主机名) 192.168.4.51(ip地址):6351(端口)   1(票数)
     bind   0.0.0.0  //服务地址
     sentinel auth-pass server51 123456  //连接服务密码
 ]# redis-sentinel  /etc/sentinel.conf  //启动服务

持久化

• RDB介绍

• Redis数据库文件,全程Redis DataBase
  -数据持久化方式之一
  -数据持久化默认方式
  -按照指定时间间隔,将内存中的数据集快照写入硬盘
  -快照术语叫Snapshot
  -恢复时,将快照文件直接读入内存

• 定义RDB文件名

• -dbfilename “dump.rdb” //文件名

使用RDB文件恢复数据

• 备份数据
  -备份dump.rdb 文件到其他位置
  ]# cp 数据库目录/dump.rdb 备份目录
• 恢复数据
  -拷贝备份文件到数据库目录,重启redis服务
  ]# cp 备份目录/dump.rdb 数据库目录/
• 优化设置
  -数据从内从保存到硬盘的频率
  -save 900 1 //15分钟且有1个key改变
  -save 300 10 //5分钟且有10个key改变
  -save 60 10000 //1分钟且有10000个key改变
• 手动存盘
  -save //阻塞写存盘
  -bgsave //不阻塞写存盘

RDB优点与缺点

• RDB优点
  -高性能的持久化实现-----创建一个子进程来执行持久化,先将数据写入临时文件,持久化进程结束后,再用这个临时文件替换上次持久化号的文件,过程中主进程不做任何IO操作
  -比较适合大规模数据恢复,且对数据完整性要求不是非常高的场合
• RDB的缺点
  -意外宕机时,丢失最后一次持久化的所有数据.

AOF介绍

• Append Only File
  -追加方式记录写操作的文件
  -记录redis服务所有写操作
  -不断地将新的写操作,追加到文件的莫问
  -默认没有启用
  -使用cat命令可以查看文件内容
• 启用AOF

config set appendonly yes //启用
config rewrite //写进配置文件

• 备份数据
  -备份appendonly.aof文件到其他位置
  ]# cp 数据库目录/appendonly.aof 备份目录

• 恢复数据
  -拷贝备份文件到数据库目录
  -重启redis服务
  ]# cp 备份目录/appendonly.aof 数据库目录
  ]# /etc/redis/redis_端口 start

• 优化配置

• 定义文件名
  -appendonly yes //启用aof,默认no
  -appendfilename “appendonly.aof” //指定文件名

• AOF文件记录写操作的方式
  -appendfsync always //时时记录,并完成磁盘同步
  -appendfsync everysec //每秒记录依次,并完成磁盘同步
  -appendfsync no //写入aof,不执行磁盘同步

• 日志文件不断增大,合适触发日志重写?
  -auto-aof-rewrite-min-size 64mb //首次重写触发值
  -auto-aof-rewrite-percentage 100 //再次重写,增长百分比

• 修复AOF 文件
  -把文件恢复到最后依次的正确操作

]# redis-check-aof --fix appendonly.aof

Ox 83:Expected\r\n,got:6166
AOF analyzed:size=160,ok_up_to=123,diff=37
This will shrink the AOF from 160 bytes,with 37 bytes,to 123 bytes
Continue>[y/N]:y
Successfully truncated AOF

AOF优点与缺点

• AOF优点
  -可以灵活设置持久方式
  -出现意外宕机时,仅可能丢失1秒的数据
• AOF缺点
  -持久化文件的体积通常会大于RDB方式
  -持久fsync策略时的速度可能回避RDB方式慢