Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What does Redis mean by data persistence in Docker?

2025-01-27 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the meaning of data persistence of Redis in Docker". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what is the meaning of data persistence in Redis in Docker"?

Project Github address: github/booklet

Redis provides two different persistence methods to store data on your hard disk. One method is called snapshotting,RDB, which can write all the data that exists at a certain time to the hard disk.

Another method is called append-only file (append-only file,AOF), which copies the write command to the hard disk when the write command is executed.

This article combs the knowledge points of the two persistence methods of Redis, and simulates the environment through Docker + Docker-Compose to backup and restore data.

As for the test data, I input 3 million key-value key-value pairs in batches through a python script (which consumes 719.42m memory and comes from redis-cli info information). Students without python environment can use another shell script I prepared in the project.

Python script code:

#-*-coding: UTF-8-*-# file write.py# author liumapp # github https://github.com/liumapp# email liumapp.com@gmail.com# homepage http://www.liumapp.com # date 2019/9/9#import redisr = redis.Redis (host= "127.0.0.1", port=6379, db=0, password= "admin123") print ("start inserting 3 million pieces of data Every 100000 pieces of data are submitted for batch processing ") with r.pipeline (transaction=True) as p: value = 0 while value

< 3000000: print("开始插入" + str(value) + "条数据") p.sadd("key" + str(value), "value" + str(value)) value += 1 if (value % 100000) == 0: p.execute()RDB RDB持久化是通过创建快照来获得数据副本,即简单粗暴的直接保存键值对数据内容 要启用RDB(并关闭AOF),我们需要修改Redis的配置文件(./redis_config/redis.conf): requirepass admin123save 60 1000stop-writes-on-bgsave-error nordbcompression nodbfilename dump.rdbappendonly noappendfsync everysecno-appendfsync-on-rewrite noauto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mbdir /data/ 上述配置会通过docker-compose的配置,映射到Redis容器中并启用,具体在下面的实操中介绍 RDB配置说明 上述配置中与RDB相关的配置如下 save: 多久执行一次自动快照操作 比如设置为 save 60 1000 ,那么就表示在60秒之内,如果有1000次写入的话,Redis就会自动触发BGSAVE命令 一般来说,我们都会希望Redis可以有一个固定的周期来创建快照,那么可以这样设置 save 900 1 ,意思就是让Redis服务器每隔900秒,并且至少执行了一次写入操作后,就触发BGSAVE指令 stop-writes-on-bgsave-error: 在创建快照失败后是否仍然继续执行写命令 rdbcompression: 是否对快照文件进行压缩 yes: 开启,这种情况下,Redis会采用LZF算法对rdb文件进行压缩 no: 关闭 dbfilename: 快照文件名 dir: 快照文件存放目录 RDB触发条件 RDB的触发条件会比AOF麻烦,大致可以分为以下几种: 通过redis-cli等客户端直接发送指令: BGSAVE BGSAVE指令,会让Redis调用fork创建一个子进程在后台运行,子进程将会负责创建快照到磁盘中 在演示案例中,启动redis的docker容器后,在redis-cli中输入 BGSAVE 后,能够在./redis_data目录下生成一个temp-17.rdb文件(或者其他以rdb结尾的) 通过redis-cli等客户端直接发送指令:SAVE SAVE指令**(注意跟配置中的save没有半毛钱关系)**,会让Redis主进程直接开始创建快照,但在创建快照的过程中,Redis不会响应其他命令请求 在演示案例中,启动redis的docker容器后,在redis-cli中输入 SAVE 后,能够在./redis_data目录下生成一个temp-17.rdb文件(或者其他以rdb结尾的) 通过配置项save进行触发 具体请参照上文的参数说明 通过SHUTDOWN命令关闭Redis服务器时,Redis会自动触发一个SAVE指令 通过标准TERM信号kill掉Redis服务时,Redis也会自动触发一个SAVE指令 通过Redis主从服务器的复制请求 主服务器收到从服务器的复制请求时,会触发一次BGSAVE指令(当且仅当主服务器没有子进程在执行BGSAVE) RDB-Docker实操 通过docker-compose启动Redis容器 docker-compose.yml配置如下 version: "2" services: redis: image: 'redis:3.2.11' restart: always hostname: redis container_name: redis ports: - '6379:6379' command: redis-server /usr/local/etc/redis/redis.conf volumes: - ./redis_config/redis.conf:/usr/local/etc/redis/redis.conf - ./redis_data/:/data/ 我将Docker容器中的redis服务所产生的备份文件,映射在宿主机的./redis_data目录下 修改redis配置文件,使AOF生效,并关闭RDB 这里将上面的redis.conf内容复制替换到./redis_config/redis.conf文件中即可 启动redis服务,并观察redis_data目录下是否有dump.rdb文件生成,有生成,则证明备份成功 数据恢复的话,我们不需要做其他操作,只要确保该dump.rdb存在,redis便会自动去读取其中的数据 AOF AOF持久化会将被执行的写命令写到AOF文件的末尾,以此来记录数据发生的变化。因此,Redis 只要从头到尾重新执行一次AOF 文件包含的所有写命令,就可以恢复AOF文件所记录的数据集。 要启用AOF(并关闭RDB),我们需要修改Redis的配置文件(./redis_config/redis.conf) requirepass admin123#save 60 1000stop-writes-on-bgsave-error nordbcompression nodbfilename dump.rdbappendonly yesappendfsync everysecno-appendfsync-on-rewrite noauto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mbdir /data/ 上述配置会通过docker-compose的配置,映射到Redis容器中并启用,具体在下面的实操中介绍 AOF配置说明 上述配置中与AOF相关的配置如下 appendonly: 是否启用AOF yes: 启用AOF no: 关闭AOF appendfsync: 启用AOF后的数据同步频率 alaways: 每个Redis写命令都要同步写入硬盘。这样做会严重降低Redis 的速度 (不建议) everysec: 每秒执行一次同步,显式地将多个写命令同步到硬盘 (推荐,对性能没有太大影响) no: 让操作系统来决定应该何时进行同步。(不建议) Redis将不对AOF文件执行任何显式的同步操作,如果用户的硬盘处理写入操作的速度不够快的话,那么当缓冲区被等待写入硬盘的数据填满时,Redis的写入操作将被阻塞,并导致Redis处理命令请求的速度变慢 no-appendfsync-on-rewrite:在对AOF进行压缩(也被称为重写机制)的时候能否执行同步操作 yes: 不允许 no: 允许 auto-aof-rewrite-percentage:多久执行一次AOF压缩,单位是百分比 auto-aof-rewrite-min-size:需要压缩的文件达到多少时开始执行 auto-aof-rewrite-percentage跟auto-aof-rewrite-min-size需要配套使用,比如当我们设置auto-aof-rewrite-percentage为100,设置auto-aof-rewrite-min-size为64mb时 redis会在AOF产生的文件比64M大时,并且AOF文件的体积比上一次重写之后至少增大了一倍(100%)才执行BGREWRITEAOF重写命令 如果觉得AOF重写执行得过于频繁,我们可以把auto-aof-rewrite-percentage设置100以上,比如200,就可以降低重写频率 这里可以参考Redis的官方手册,写的非常清楚:https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-1-persistence-options/4-1-3-rewritingcompacting-append-only-files/ dir:备份文件存放目录 AOF触发条件 直接根据appendfsync的设置进行触发 AOF重写机制 在上面的配置中,已经通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数,简单介绍了Redis的BGREWRITEAOF重写命令 那么,为什么要用AOF重写机制呢? 因为AOF持久化是通过保存被执行的写命令来记录Redis数据库状态的,所以AOF文件随着时系统运行会越来越大 而过于庞大的AOF文件会产生以下不良影响 影响Redis服务性能; 占用服务器磁盘空间; AOF还原数据状态的时间增加; 所以Redis提供了一套AOF重写机制,通过创建一个新的AOF文件来替换掉旧的AOF文件,这两个文件所保存的数据状态是相同的,但新的AOF文件不会包含冗余命令,所以体积会较旧AOF文件小很多 但在实际的使用中,我们需要非常小心,不能让Redis的重写命令执行的过于频繁 (注意:auto-aof-rewrite-percentage的单位是百分比,值越大,重写频率越低,也千万别出现0这种值) 因为BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似:Redis会创建一个子进程,然后由子进程负责对AOF文件进行重写,因为AOF文件重写也需要用到子进程,所以快照持久化因为创建子进程而导致的性能问题和内存占用问题,在AOF持久化中也同样存在 更具体的AOF重写工作原理: Fork主进程,产生一个带有数据副本的子进程在后台执行 Redis这样设计可以确保在重写过程中,不影响Redis主进程的服务正常运行,同时通过处理数据副本来保证数据的安全性**(注意,重写是针对数据副本来进行处理,而不是针对旧的AOF文件)** 子进程Fork完成后,Redis将启用AOF重写缓冲区,此刻开始,新的写入命令会被写入AOF缓冲区和AOF重写缓冲区中 这里启用的AOF重写缓冲区可以确保:在执行AOF重写的过程中,任何新的写入命令产生,都不会导致新AOF文件的数据状态与Redis数据库状态不一致 子进程完成对AOF文件的重写后,通知父进程 父进程收到通知后,将AOF重写缓冲区的内容全部写入新的AOF文件中 父进程将新的AOF文件替换掉旧的AOF文件**(注意,这一步会造成Redis阻塞,但问题不大)** BGREWRITEAOF的工作流程图如下所示**(绘图源代码在项目的./articles/bgrewriteaof.puml文件下)**:

AOF-Docker practical operation

Start the Redis container through docker-compose

The docker-compose.yml configuration is as follows

Version: "2" services: redis: image: 'redis:3.2.11' restart: always hostname: redis container_name: redis ports: -' 6379 redis 6379' command: redis-server / usr/local/etc/redis/redis.conf volumes: -. / redis_config/redis.conf:/usr/local/etc/redis / redis.conf -. / redis_data/:/data/

I map the backup files generated by the redis service in the Docker container to the host's. / redis_data directory

Modify the redis configuration file to make AOF effective and close RDB

Here, copy and replace the above redis.conf content into the. / redis_config/redis.conf file.

Start the redis service and observe whether any appendonly.aof files are generated in the redis_data directory, which proves that the backup is successful.

In addition, we can find that the backup files of 3 million pieces of data (700m) actually occupy about 170m of disk space, which is where the Redis rewriting mechanism is powerful.

If the data is restored, we don't need to do anything else. As long as we make sure that the appendonly.aof exists, redis will automatically read the data in it.

Summary

Both RDB and AOF can ensure the persistence of Redis data, but each has its own characteristics.

Because RDB has default instructions SAVE and BGSAVE support, it is more suitable for full backup of the database, such as BGSAVE starting at 3: 00 a. M. every day

Because AOF is a saved write command, it is more suitable for real-time backup. In fact, enterprise applications basically use AOF.

But using RDB or AOF, or even both, is not enough.

For a distributed platform that needs to support extensibility, we also need to provide a replication backup mechanism that allows AOF or RDB files to be automatically backed up to different servers within a cycle.

In this case, we need to use Redis's replication and data copy function, which I will record in the next article.

At this point, I believe you have a deeper understanding of "what is the meaning of data persistence in Redis in Docker". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report