• redis 持久化+主从


    Redis持久化

    1.RDB和AOF优缺点
    RDB: 快照,把当前内存里的状态快照到磁盘上
    优点: 压缩格式/恢复速度快
    缺点: 可能会丢失数据
    
    AOF: 类似于mysql的binlog,重写,、每次操作都写一次/1秒写一次
    优点: 安全,有可能会丢失1秒的数据
    缺点: 文件比较大,恢复速度慢 
    

    持久化RDB

    1.配置
    [root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf 
    save 900 1
    save 300 10
    save 60 10000
    
    

    背景:

    1.配置文件里设置了数据目录和持久化文件名

    现象:

    1.直接关闭重启,数据丢失

    2.执行了bgsave之后。数据目录持久化了,重启数据不丢失

    背景:

    1.配置文件设置了数据目录和持久化文件名

    2.设置了触发条件

    现象:

    1.触发条件都不满足,但是重启之后数据还在,持久化了

    结论:

    1.如果不设定触发条件,关闭redis不会持久化

    2.如果设定了触发条件,即使触发持久化,但是关闭的时候,redis会替你执行一次bgsave

    2.结论:
    1.执行shutdown的时候,内部会自动执行bgsave,然后再执行shutdown
    2.pkill  会持久化
    kill     会持久化
    killall  会持久化
    shutdown  会持久化.会触发bgsave持久化
    kill -9 不会持久化
    
    
    3.恢复的时候,rdb文件名称要和配置文件里写的一样
    4.如果没有配置save参数,执行shutdown不会自动bgsave持久化 
    5.如果没有配置save参数,可以手动执行bgsave触发持久化保存
    
    常用命令:
    ll /data/redis_6379/
    cat /opt/redis_6379/conf/redis_6379.conf 
    vim /opt/redis_6379/conf/redis_6379.conf 
    pkill redis
    redis-server /opt/redis_cluster/redis_6379/conf/redis_6379.conf 
    redis-cli -h db01
    redis-cli -h db01 shutdown
    bash for.sh 
    
    
    3.配置AOF
    appendfilename "redis_6379.aof"
    appendonly yes
    appendfsync everysec
    
    3.实验
    设置数据
    127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
    OK
    #关机
    [root@db01 redis_6379]# redis-cli
    127.0.0.1:6379> SHUTDOWN
    not connected> 
    #开机
    [root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf 
    #查看
    [root@db01 redis_6379]# ll
    total 4
    -rw-r--r-- 1 root root 102 Dec 25 15:17 redis_6379.rdb
    [root@db01 redis_6379]# redis-cli
    127.0.0.1:6379> KEYS *
    1) "k1"
    2) "k2"
    3) "k3"
    127.0.0.1:6379> 
    
    实验:
    如果aof和rdb文件同时存在,redis会如何读取:
    
    实验步骤:
    1.插入一条数据
    aof: 有记录
    rdb: 没有记录 
    2.复制到其他地方 
    3.把redis停掉
    4.清空数据目录
    5.把数据文件拷贝过来
    aof: 有记录
    rdb: 没有记录
    6.启动redis
    7.测试,如果有新插入的数据,就表示读取的是aof,如果没有,就表示读取的是rdb
    
    实验结论:
    如果2种数据格式都存在,优先读取aof
    
    
    官方文档:
    https://redis.io/topics/persistence
    
    如何选择:
    好的,那我该怎么用?
    通常的指示是,如果您希望获得与PostgreSQL可以提供的功能相当的数据安全性,则应同时使用两种持久性方法。
    如果您非常关心数据,但是在灾难情况下仍然可以承受几分钟的数据丢失,则可以仅使用RDB。
    有很多用户单独使用AOF,但我们不建议这样做,因为不时拥有RDB快照对于进行数据库备份,加快重启速度以及AOF引擎中存在错误是一个好主意。
    注意:由于所有这些原因,我们将来可能会最终将AOF和RDB统一为一个持久性模型(长期计划)。
    以下各节将说明有关这两个持久性模型的更多详细信息。
    
    

    持久化AOF

    开启AOF功能需要设置配置:

    appendonly yes,默认不开启.AOF文件名通过appendfilename配置设置,默认文件名是appendonly.aof. 保存路径通RDB持久化方式一致,通过dir配置指定.

    1.AOF的工作流程

    1.所有写入命令会追加到aof_buf(缓冲区)中.

    2.AOF缓冲区根据对应的策略向硬盘做同步操作

    3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的.

    4.当Redis服务重启时,可以加载AOF文件进行数据恢复.

    2.配置
    [root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf 
    appendfilename "redis_6379.aof"
    appendonly yes
    appendfsync everysec
    
    3.实验
    #开机
    [root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
    [root@db01 redis_6379]# ll
    total 4
    -rw-r--r-- 1 root root   0 Dec 25 16:05 redis_6379.aof
    -rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb
    #插入数据
    [root@db01 redis_6379]# redis-cli
    127.0.0.1:6379> KEYS *
    (empty list or set)
    127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
    OK
    127.0.0.1:6379> 
    #查看
    [root@db01 redis_6379]# ll
    total 8
    -rw-r--r-- 1 root root  85 Dec 25 16:07 redis_6379.aof
    -rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb
    #再次插入
    [root@db01 redis_6379]# redis-cli set k4 v4
    OK
    #再次查看发现.aof 有变化 而.rdb没有变化
    [root@db01 redis_6379]# ll
    total 8
    -rw-r--r-- 1 root root 114 Dec 25 16:09 redis_6379.aof
    -rw-r--r-- 1 root root 102 Dec 25 16:04 redis_6379.rdb
    
    
    #for循环插入数据
    for i in {1..10000}; do redis-cli set k_${i} v_${i};echo ${i};done
    
    

    4.结论

    .aof 是实时记录的
    .rdb 是关机或者pkill 做的一个备份
    
    测试,如果有新插入的数据,就表示读取的是aof,如果没有,就表示读取的是rdb
    
    实验结论:
    如果2种数据格式都存在,优先读取aof
    

    官方解释:

    https://redis.io/topics/persistence

    安全认证

    #配置密码
    [root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf 
    requirepass 123456
    
    
    
    [root@db01 redis_6379]# pkill redis
    [root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
    
    #登录发现需要认证
    [root@db01 redis_6379]# redis-cli 
    127.0.0.1:6379> KEYS *
    (error) NOAUTH Authentication required.
    #输入密码登录
    [root@db01 redis_6379]# redis-cli -a 123456
    127.0.0.1:6379> get k1
    "v1"
    
    
    
    禁用危险命令
    配置文件里添加禁用危险命令的参数
    [root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf
    
    rename-command KEYS ""
    rename-command FLUSHALL ""
    
    rename-command FLUSHDB ""
    
    rename-command CONFIG ""
    
    
    #关机
    [root@db01 redis_6379]# pkill redis
    #启动
    [root@db01 redis_6379]# redis-server /opt/redis_6379/conf/redis_6379.conf
    [root@db01 redis_6379]# redis-cli -a 123456
    #查看
    127.0.0.1:6379> KEYS *
    (error) ERR unknown command 'KEYS'
    
    
    
    设置一个别名
    [root@db01 redis_6379]# vim /opt/redis_6379/conf/redis_6379.conf 
    
    rename-command KEYS "AA"
    rename-command FLUSHALL ""
    
    rename-command FLUSHDB ""
    
    rename-command CONFIG ""
    
    就是 输入 AA*的时候,才可以看到keys *的所有内容
    
    

    主从复制

    快速创建第二台redis节点命令:

    [root@db01 redis_6379]# yum install -y rsync
    利用rsync 传到对端
    [root@db01 redis_6379]# rsync -avz /opt/* db02:/opt/
    [root@db01 redis_6379]# rsync  -avz /data db02:/
    
    
    

    db02 操作

    [root@db02 ~]# cd /opt/redis
    [root@db02 redis]# make install
    
    修改端口
    [root@db02 redis]# sed -i 's#51#52#g' /opt/redis_6379/conf/redis_6379.conf
    
    [root@db02 redis]# rm -rf /data/redis_6379/* 
    
    启动
    [root@db02 redis]# redis-server /opt/redis_6379/conf/redis_6379.conf 
    
    进入查看
    [root@db02 redis]# redis-cli
    127.0.0.1:6379> KEYS *
    (empty list or set)
    开始做主从
    
    #临时生效
    127.0.0.1:6379> SLAVEOF 10.0.0.51 6379 
    ok
    127.0.0.1:6379> get k1
    "v1"
    #永久生效 将SLAVEOF 10.0.0.51 6379  写入配置文件中
    
    
    

    注意:做主从的时候,从的配置文件一定要跟主的一模一样,要不然做不了

    主的配置文件

    [root@db01 redis_6379]# !v
    vim /opt/redis_6379/conf/redis_6379.conf 
    
    ### 监听端口
    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
    #save 900 1
    #save 300 10
    #save 60 10000
    #
    #appendfilename "redis_6379.aof"
    #appendonly yes
    #appendfsync everysec
    #requirepass 123456
    
    

    通过看日志来分析主从复制的原理

    [root@db02 ~]# cat /opt/redis_6379/logs/redis_6379.log 
    
    从节点日志
    
    9744:S 25 Dec 19:03:53.501 * Connecting to MASTER 10.0.0.51:6379
    9744:S 25 Dec 19:03:53.502 * MASTER <-> SLAVE sync started
    9744:S 25 Dec 19:03:53.502 * Non blocking connect for SYNC fired the event.
    9744:S 25 Dec 19:03:53.502 * Master replied to PING, replication can continue...
    9744:S 25 Dec 19:03:53.503 * Partial resynchronization not possible (no cached master)
    9744:S 25 Dec 19:03:53.505 * Full resync from master: cbd36d5d4638a5433f3e6bbaf1e402fe8abb5ee4:1
    
    #从节点接收主节点发送的数据,然后载入内存:
    
    9744:S 25 Dec 19:03:53.602 * MASTER <-> SLAVE sync: receiving 147898 bytes from master
    9744:S 25 Dec 19:03:53.604 * MASTER <-> SLAVE sync: Flushing old data
    9744:S 25 Dec 19:03:53.604 * MASTER <-> SLAVE sync: Loading DB in memory
    9744:S 25 Dec 19:03:53.616 * MASTER <-> SLAVE sync: Finished with success
    
    
    
    ======================================================================================
    主节点日志
    [root@db01 ~]# cat /opt/redis_6379/logs/redis_6379.log 
    33819:M 25 Dec 19:02:56.917 * DB loaded from disk: 0.013 seconds
    
    #主节点收到请求之后开始持久化保存数据:
    33819:M 25 Dec 19:02:56.917 * The server is now ready to accept connections on port 6379
    33819:M 25 Dec 19:03:53.815 * Slave 10.0.0.52:6379 asks for synchronization
    33819:M 25 Dec 19:03:53.815 * Full resync requested by slave 10.0.0.52:6379
    33819:M 25 Dec 19:03:53.815 * Starting BGSAVE for SYNC with target: disk
    33819:M 25 Dec 19:03:53.815 * Background saving started by pid 33826
    33826:C 25 Dec 19:03:53.830 * DB saved on disk
    33826:C 25 Dec 19:03:53.831 * RDB: 8 MB of memory used by copy-on-write
    
    #主节点收到从节点同步完成的消息
    33819:M 25 Dec 19:03:53.913 * Background saving terminated with success
    33819:M 25 Dec 19:03:53.915 * Synchronization with slave 10.0.0.52:6379 succeeded
    
    

    主从复制流程:

    1.从节点发送同步请求到主节点
    2.主节点接收到从节点的请求之后,做了如下操作
    
    - 立即执行bgsave将当前内存里的数据持久化到磁盘上
    - 持久化完成之后,将rdb文件发送给从节点
      3.从节点从主节点接收到rdb文件之后,做了如下操作
    - 清空自己的数据
    - 载入从主节点接收的rdb文件到自己的内存里
      4.后面的操作就是和主节点实时的了
    
    取消主从复制
    SLAVEOF no one
    

    查看取消主从复制日志

    [root@db02 ~]# cat /opt/redis_6379/logs/redis_6379.log 
    
    9744:M 25 Dec 19:25:12.655 # Connection with master lost.
    #缓存断开连接的主状态
    9744:M 25 Dec 19:25:12.655 * Caching the disconnected master state.
    #丢弃以前缓存的主状态。
    9744:M 25 Dec 19:25:12.655 * Discarding previously cached master state.
    9744:M 25 Dec 19:25:12.656 * MASTER MODE enabled (user request from 'id=5 addr=127.0.0.1:53702 fd=6 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')
    
    
    
    
    [root@db01 ~]# cat /opt/redis_6379/logs/redis_6379.log
    #连接从10.0.0.52:6379丢失。
    33819:M 25 Dec 19:25:12.967 # Connection with slave 10.0.0.52:6379 lost.
    
    

    注意!!!
    1.从节点只读不可写
    2.从节点不会自动故障转移,它会一直同步主
    10.0.1.52:6379> set k1 v1
    (error) READONLY You can't write against a read only slave.
    3.主从复制故障转移需要人工介入

    • 修改代码指向REDIS的IP地址
    • 从节点需要执行SLAVEOF no one

    注意!!!
    1.从节点会清空自己原有的数据,如果同步的对象写错了,就会导致数据丢失

    安全的操作:
    1.无论是同步,无论是主节点还是从节点

    2.先备份一下数据

  • 相关阅读:
    Image Processing and Analysis_8_Edge Detection:Finding Edges and Lines in Images by Canny——1983
    2019年C题 视觉情报信息分析
    Image Processing and Analysis_8_Edge Detection:Theory of Edge Detection ——1980
    Computer Vision_2_Active Shape Models:Active Shape Models-Their Training and Application——1995
    Computer Vision_1_Active Appearance Models:Active Appearance Models——2001
    Computer Vision_1_Active Appearance Models :Active Appearance Models——1998
    这群程序员疯了!他们想成为IT界最会带货的男人
    阿里云视频云正式支持AV1编码格式 为视频编码服务降本提效
    Knative Serverless 之道:如何 0 运维、低成本实现应用托管?
    千呼万唤始出来——DataV私有部署功能
  • 原文地址:https://www.cnblogs.com/223zhp/p/12098894.html
Copyright © 2020-2023  润新知