Chapter 11, AOF persistence

In addition to the RDB persistence function, Redis also provides AOF (Append Only File) persistence function (record-keeping database state).

And RD persistence by saving the database of key state for different databases to record, AOF write command is executed by saving Redis server to record the state of the database.

as the picture shows:

For example: the implementation of some three commands in redis client

RDB persistent state of the database is to save SET, SADD, RPUSH three command msg, fruits, numbers three keys to save them to the RDB file, and save the AOF persistent state of the database server to perform sucked method of preservation to AOF file.

When the server is started, can be saved by loading and executing AOF file command to restore the database state before the server shuts down, the following is a log of the print server load AOF files and restore the database state:

[8321] 05 Sep 11:58:50.448 # Server started,Redisversion 2.9.11
[8321] 05 Sep 11:58:50.448 * DB loaded from append only file: 0.000 seconds
[8321] 05 Sep 11:58:50.448 * The server is now ready to accept connections on port 6379

11.1 persistence implementation capabilities, AOF file write, save, load realization of the principle of operation

  AOF achieve persistence function may be added into the command (the append), the file is written, the file synchronization (sync) three steps;

11.1.1 instruction adding

  When AOF persistence feature is turned on, the server performs the end aof_buf buffer after completing a write command, it will form the agreement will write commands are executed appended to the state of the server.

. 1  struct {redisServer
 2          // ...
 . 3          // AOF of buffer 
. 4          SDS aof_buf;    
 . 5          //
 . 6 }

Write and file synchronization 11.1.2 AOF

  Redis server process is a time cycle (loop), this cycle of file events responsible for receiving client command requests, and want the client to send commands reply; and the time the event is responsible for executing functions like serverCron function so requires regular implementation;

  Because the file server when processing events may write command, so that some of the content is appended to aof_buf buffer, so a server before the end of each event loop will call flushAppendOnlyFile function, consider whether to write the contents of the buffer and aof_buf AOF saved to a file inside;

  FlushAppendOnlyFile behavior is a function of the value of the option appendfsync server configuration to determine the behavior of the respective different values ​​in the following table:

Value appendfsync options Behavior flushAppendOnlyFile function Efficiency and security
always Every event loop will have to write all the content aof_buf buffer and synchronize files to AOF; Write slowest; safest (a loss of up to command data in the event loop generated)
everysec (default value) Every event loop will have to write all the content aof_buf buffer AOF documents; AOF every second of every file in the sub-thread synchronization, and the synchronization operation is performed by a thread dedicated to the 2; Write fast enough, and calculates the appearance downtime, lost up to one second command data in the database;
no Every event loop will have to write all the content aof_buf buffer AOF file; when to synchronize files AOF determined by the operating system; Write the fastest; synchronizing the longest duration, and calculates the failure downtime, server data l lose all write commands since the last synchronization AOF documents;
Operating system - Inhalation and synchronize files

 In order to improve the efficiency of space write the file, the operating system now, when the user calls the write function to write some data to a file, OS data will usually be written temporarily stored in a memory cache inside the area, such as buffer after being filled, or more than the specified limit, it actually writes data to the disk buffer them;

  Although such an approach increases the efficiency, it also brings security issues as data is written, if a computer sends downtime, then stored in the memory buffer write data will be lost;

  To this end, OS provides the fsync and fdatasync two synchronization functions, they can force the operating system immediately writes data to the hard disk buffer which, in order to ensure the security of data is written;

Loading and restore 11.2 AOF documents

  Because AOF file which contains all the write command to rebuild the database state needs, so long as the server reads and re-run it again AOF files saved inside a write command, you can restore the database state before the server shuts down;

  AOF Redis read the file and restore the state of the database detailed steps:

  

11.3 AOF rewrite

  Over time, the contents of the file AOF more and more documents become bigger and bigger, if not controlled, oversized AOF file is likely to Redis service area, and even affect the entire host computer, and the AOF the larger the file size, file data using AOF time required to reduce more.

  In order to solve the problem of volume expansion AOF, Redis provides file AOF rewrite (rewrite) function: Redis server to replace the existing file AOF AOF by creating a new file, the same file saved in the old and new state of the database, but the new AOF file command does not save any redundant waste of space;

  The principle: This function does not require any conventional AOF file read or write operation Xu; instead achieved by reading the current state of the database server.

  AOF 后台重写:AOF 重写程序 aof_rewrite 函数可以很好的完成创建一个新 AOF 文件的任务,但是因为该函数会进行大量的写入操作,所以调用此函数的线程将会长时间被阻塞;

    因为Redis服务器使用单线程处理命令请求,所以如果由服务器直接调用 aof_rewrite 函数。那么在重写期间,服务器将无法处理客户端发送来的命令请求;

    所以Redis决定将AOF重写程序放入到子进程中去执行;

  使用子进程所带来的问题:

    新的客户端命令请求会修改当前数据库的状态,引发服务器当前数据库状态与重写后 AOF 文件保存的数据库状态不一致!

    为了解决这个问题,Redis服务器设置类以一个 AOF 重写缓冲区,该缓冲区是在服务器创建子进程之后开始使用,当服务器执行完一个写命令之后,它会同时将这个写命令发送给 AOF 缓冲区和 AOF 重写缓冲区,如图所示:

  

  在子进程执行 AOF 重写期间,服务器进程需要执行一下三个工作:

  (1)执行客户端发送得命令;

  (2)将执行后得写命令追缴到 AOF 缓冲区;

  (3)将执行后得写命追加到 AOF 重写缓冲区;

  当子进程完成 AOF 重写工作之后,它会给父进程发送一个信号,父进程在接受到信号之后,会调用一个信号处理函数,并执行以下工作:

  (1)将 AOF 重写缓冲区得所有内容写入到新 AOF 文件中,这时,新AOF文件所保存的数据库状态和服务器当前数据库状态保持一致;

  (2)对新 AOF 文件改名:原子地覆盖现有 AOF 文件,完成新旧两个 AOF 文件的替换;

  信号处理函数执行完成之后,父进程就可以正常处理接受命令请求了;

  在整个 AOF 后台重写过程中,只有信号处理函数会对服务器进程(父进程)造成阻塞,在其它时候,AOF 后台重写都不会阻塞父进程,这将 AOF 重写对服务器的性能造成的影响降到了最低;

Guess you like

Origin www.cnblogs.com/luoshengjie/p/11114074.html