Home  >  Article  >  Database  >  Check whether redis is persistent

Check whether redis is persistent

anonymity
anonymityOriginal
2019-06-04 16:11:005552browse

infoView persistence information

Check whether redis is persistent

##redis-cli info persistence

#loading: Is the server loading? Into the persistent file


rdb_changes_since_last_save: The number of write commands since the last successful generation of the rdb file, that is, how many write commands have not been persisted


rdb_bgsave_in_progress : Whether the server is creating an rdb file


rdb_last_save_time: The timestamp of the most recent successful creation of an rdb file. Current timestamp - rdb_last_save_time=how many seconds it took to successfully generate the rdb file


rdb_last_bgsave_status: whether the latest rdb persistence was successful


rdb_last_bgsave_time_sec: the time it took to successfully generate the rdb file Seconds


rdb_current_bgsave_time_sec: If the server is creating an rdb file, then this field records the number of seconds that the current creation operation has taken


rdb_last_cow_size: The parent in the RDB process How many modifications the process has performed compared to the child process (including read buffers, write buffers, data modifications, etc.).


aof_enabled: Whether aof is enabled


aof_rewrite_in_progress: Identifies whether the rewrite operation of aof is in progress


aof_rewrite_scheduled: rewrite task plan, When the client sends the bgrewriteaof command, if the current rewrite sub-process is executing, then the bgrewriteaof requested by the client will be turned into a scheduled task, and rewrite will be executed after the aof sub-process ends.


aof_last_rewrite_time_sec: the most recent aof rewrite Time spent


aof_current_rewrite_time_sec: If the rewrite operation is in progress, record the time used, in seconds

aof_last_bgrewrite_status: The status of the last bgrewriteaof operation

aof_last_write_status : Last aof write status

aof_last_cow_size: How many modifications were performed by the parent process compared with the child process during the AOF process (including read buffer, write buffer, data modification, etc.).

appendfsync has three options: always, everysec and no:

1. When selecting always, the server will force the contents of the AOF buffer every time an event is executed. Permanently written to the AOF file on the hard disk, it can be seen as recording this command in the AOF file every time you execute a redis write command. This ensures the integrity of data persistence, but the efficiency is the slowest, but It is also the safest;

2. If configured as everysec, every time the server performs a write operation (such as set, sadd, rpush), the command will be appended to the end of a separate AOF buffer, and Write the AOF buffer to the AOF file, and then perform file synchronization every second to actually write the AOF cache data in the memory buffer to the AOF file. This mode takes into account efficiency while ensuring data integrity. , even if the server is down, only the modifications made to the redis database within one second will be lost;

3. Configuring appendfsync to no means that you can accept the loss of the data in the redis database, and it will Append each write command to the end of the AOF buffer and then write it to the file. However, it is up to the system itself to decide when to perform file synchronization and actually write the data to the AOF file, that is, when the space in the memory buffer is filled or when The system automatically synchronizes after the set time limit. This mode is the fastest efficient, but it is also the most unsafe for the data. If the data in redis is taken out from the background database such as mysql, and it is data that can be retrieved at any time or is not important, then You can consider setting it to this mode.

The above is the detailed content of Check whether redis is persistent. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Previous article:Is redis thread safe?Next article:Is redis thread safe?