从运维的角度看Redis

redis运维方面的指令

#查看时间
time #返回时间戳

#获取当前数据库有多少key
dbsize  #当前数据库 默认时16个

#重写aof,即删除key的中间过程
bgrewriteaof 

#手动导出rdp
save #或者使用
lastsave#查看上次保存时间
bgsave #后台导出rdp

#清空数据 （慎用）
flushdb  #清空当前数据库  select id  切换数据库
flushall #清空所有数据库

#查看服务统计信息
info

#获取redis.conf配置
config get port #这里查询配置端口号
config set port 6379

aof恢复与rdb服务器间迁移
一不小心使用了flushall或flushdb

#第一步关闭服务器
#nosave表示这条命令不会写入aof,默认是save
shutdown nosave  #防止请求进入，触发aof重写，使得aof数据丢失
#第二步编辑aof
vim redis.aof  #将flushall或flushdb指令删除
#第三步通过aof恢复数据库数据
#aof和rdb同时存在的情况下使用aof恢复数据
./redis-server #重启服务器

redis数据库的数据迁移（将一台服务器的数据转移到另一台服务器中）

  • redis数据迁移通过复制rdb文件来实现，并在redis.conf开启rdb,并指定rdb文件
  • redis服务器运行时复制rdb文件是有问题的，所以要先关闭原服务器，再复制rdb文件
  • 使用save指令，手动将数据写入rbd中，避免部分新增数据没有被持久化到rdb中

redis异常状况处理（如宕机）

深入学习Redis之redis运维_Redis


情景：当master发生宕机

  • config get/set 可以获取/设置运行时redis的配置
  • info Replication 查看当前redis的集群信息

当master宕机 slave1如何成为master

#第一步
master异常宕机
#第二步
slaveof no one #将slave1的slave角色转换成master
#第二步
config set slave-read-only no #关闭其只读状态
#其他slave重新指向新的master 
slaveof IP port

通过sentinel监控配置，自动完成以上设置
sentinel.conf

启动redis的哨兵模式：(要在redis master节点启动)
 ./redis-server sentinel.conf --sentinel 

#当master失效次数达到2次 开始进行重新选举master 
sentinel monitor def_master 127.0.0.1 6379 2  #master
  
sentinel auth-pass def_master 012_345^678-90  

##master被当前sentinel实例认定为“失效”的间隔时间  
##如果当前sentinel与master直接的通讯中，在指定时间内没有响应或者响应错误代码，那么  
##当前sentinel就认为master失效(SDOWN，“主观”失效)  
##<mastername> <millseconds>  
##默认为30秒  
sentinel down-after-milliseconds def_master 30000  
  
##当前sentinel实例是否允许实施“failover”(故障转移)  
##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover)，  
##全局中至少有一个为yes  
sentinel can-failover def_master yes  

#解决所有的cluster同时导向新的master导致master
#同时只允许1台cluster同master建立新的连接
sentinel parallel-syncs def_master 1

可能出现的问题：
重写选举master是在存活的cluster中随机选举一个，这样的做法不利于生产环境。
解决方法：
redis.conf
slave-priority 100 #设置节点的优先级 越小优先级越高

深入学习Redis之redis运维_服务器_02