RDB persistent shortcomings
RDB persistent, this persistence data can be stored inside the database inside the hard disk in the form of a binary file.
RDB persistence has one drawback, and that is because the data needs to be created RDB file server for all databases are saved, this is a very time-consuming and resource operations, so the server needs from time to time only to create a new RDB file, That is, create RDB file operation can not be performed too frequently, otherwise it will seriously affect server performance.
For example, default settings save configuration options, even if there are more than 10,000 modification operation occurs, the server will be at least at intervals of one minute to create the next RDB file:
save 900 1
save 300 10
save 60 10000
a creation if waiting for the next process RDB file, the server encountered an unexpected shutdown, the user will lose all changes since the last RDB file is created, the database occurs.
Examples of data loss
Solution
In order to solve the problem RDB persistent loss of large amounts of data in the event of unplanned downtime, Redis provides AOF persistence function.
Compared to RDB persistence, persistence AOF has a huge advantage, that is, the user can AOF persistent adjusted according to their needs, so that Redis no data is lost in the event of unplanned downtime, or lose only one second data when this ratio RDB persistence suffered unplanned downtime, data loss is much less.
AOF operation principle of persistence
Data storage and data reduction
save data
AOF method persistently saved data in the database is: whenever a command is executed to modify the database, the server writes the command to be executed to the end of AOF documents.
Data Restore
Because AOF file stored inside the database server performs all over the modification command, so given a AOF file, the server simply rerun the command again all AOF file contains, you can achieve the purpose to restore database data.
For example, for AOF file that contains the following terms:
SELECT 0
SET msg “hello”
INCR counter
SADD alphabets “a” “b” “c”
INCR counter
As long as the server re-execute these commands, you can restore the database shown in FIG.
Security Issues
通过配置选项来调整 AOF 持久化的安全性
AOF 持久化的安全性问题
虽然服务器每执行一个修改数据库的命令，就会将被执行的命令写入到 AOF 文件，但这并不意味着AOF 持久化不会丢失任何数据。
在目前常见的操作系统中，执行系统调用 write 函数，将一些内容写入到某个文件里面 时，为了提高效率，系统通常不会直接将内容写入到硬 盘里面，而是先将内容放入到一个内存 缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行 fsync 调用和 fdatasync 调用时，才将储存在缓冲区里面的内容真正地写入到硬盘里面。
对于 AOF 持久化来说，当一条命令真正地被写入到硬 盘里面时，这条命令才不会因为停机而意外丢 失。
因此，AOF 持久化在遭遇停机时丢失命令的数量，取决于命令被写入到硬 盘的时间：
• 越早将命令写入到硬盘，发生意外停机时丢失的数据就越少；
• 而越迟将命令写入到硬盘，发生意外停机时丢失的数据就越多。
安全性控制
为了控制 Redis 服务器在遇到意外停机时丢失的数据量，Redis 为 AOF 持久化提供了 appendfsync 选项，这个选项的值可以是 always 、 everysec 或者 no ，这些值的意思分别为：
always ：服务器每写入一个命令，就 调用一次 fdatasync ，将缓冲区里面的命令写入到硬 盘里面。在这种模式下，服务器即使遭遇意外停机，也不会 丢失任何已经成功执行的命令数据。
everysec ：服务器每秒钟调用一次 fdatasync ，将缓冲区里面的命令写入到硬 盘里面。在这种模式下，服务器遭遇意外停机时，最多只丢失一秒钟内执行的命令数据。
no ：服务器不主动调用 fdatasync ，由操作系统决定何时将缓冲区里面的命令写入到硬 盘里面。在这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的。
运行速度： always 的速度慢， everysec 和 no 都很快。
默认值： everysec 。
停机示例
AOF 重写
创建一个没有冗余内容的新 AOF 文件
AOF 文件中的冗余命令
随着服务器的不断运行，为了记录数据库发生的变化，服务器会将越来越多的命令写入到 AOF 文件里面，使得 AOF 文件的体积不断地增大。为了让 AOF 文件的大小控制在合理的范 围，避免它胡乱地增长，Redis 提供了 AOF 重写功能，通过 这个功能，服务器可以产生一个新的 AOF 文件：
• 新 AOF 文件记录的数据库数据和原有 AOF 文件记录的数据库数据完全一样；
• 新的 AOF 文件会使用尽可能少的命令来 记录数据库数据，因此新 AOF 文件的体积通常会比原有 AOF 文件的体积要小得多。
• AOF 重写期间，服务器不会被阻塞，可以正常 处理客户端发送的命令请求。来看一个 AOF 重写的示例。
AOF 重写示例
AOF 重写的触发
有两种方法可以触发 AOF 重写：
- 客户端向服务器发送 BGREWRITEAOF 命令。
- 通过设置配置选项来让服务器自动执行 BGREWRITEAOF 命令，它们分别是：
• auto-aof-rewrite-min-size ，触发 AOF 重写所需的最小体积：只有在 AOF 文件的体积大于等于 size 时，服务器才会考虑是否需要进行 AOF 重写。这个选项用于避免对体积过小的 AOF 文件进行重写。
• auto-aof-rewrite-percentage ，指定触发重写所需的 AOF 文件体积百分比：当 AOF 文件的体积大于 auto-aof-rewrite-min-size 指定的体积，并且超过上一次重写之后的 AOF 文件体积的 percent% 时，就会触发 AOF 重写。（如果服务器刚刚启动不久，还没有进行过 AOF 重写，那么使用服务器启动时载入的 AOF 文件的体积来作为基准值。）将这个值设置为 0 表示关闭自动 AOF 重写。
例子：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
复习
创建 RDB 文件需要将服务器包含的所有数据全部写入到硬 盘里面，这是一个非常耗费资源和时间的操作，因此服务器通常需要每隔一段时间才创建一个新的 RDB 文件，这使得服务器在遭遇意外停机时，可能会丢失大量数据。
AOF 持久化会将每个修改了数据 库的命令都写入到 AOF 文件末尾，在启动服务器的时候，只要重新执行 AOF 文件包含的命令，就可以 还原服务器原有的数据库数据。
Because there is a write buffer, AOF persistent security depends on the command buffer zone inside when they will actually be written to the hard drive inside, by setting appendfsync configuration options, the user can make persistent AOF has not lost any success execution of the command data, or loss of data only command to be executed in one second, or do not take the initiative to perform fdatasync call, the posting timing of the hard disk to the operating system to manage.
With the server running, AOF file will produce more and more redundant command, so that the file size is increasing, and by performing AOF rewrite operation, the server can create a database to save the same data, but does not contain any redundant command AOF new file, and use this new AOF AOF file to replace the original file.
Persistence contrast
The good news: You can use both persistent, be judged based on your needs. Restore data precedence AOF file.
