redis persistent storage

A. Redis high availability

　　In Redis, the realization of high availability technologies include persistence, replication, and clustering Sentinel

1. Persistence: Persistence is the easiest method for high-availability (sometimes not even be classified as a means of highly available), the main role is data backup, which stores data in the hard drive to ensure data is not lost due to the process of withdrawal.

2. Copy: Copies Redis is highly available basis, Sentinel high availability and cluster are in the replication basis. Copy the main achievement of the multi-machine backup data, and recovery for load balancing read operation and simple troubleshooting. Defects: Recovery can not be automated; not write load balancing; stand-alone storage capacity is limited.

3. Sentinel: Based on the copy, Sentinel automates failover. Defects: can not write load balancing; stand-alone storage capacity is limited.

4. Cluster: The cluster, Redis write operation can not solve the load balancing, as well as being a stand-alone issue storage capacity constraints, to achieve a more complete high availability solution.

II. Redis two kinds of persistent storage

　　Persistence functions: Redis is an in-memory database, data is stored in memory, in order to avoid the process exits lead to permanent loss of data, the need for regular Redis data in some form (data or command) saved from memory to the hard disk; The next time you restart Redis by persistent file for data recovery.

　　RDB persistence: the data is a snapshot of the current process is saved to the hard disk (and therefore also known as persistent snapshots); saved file suffix is ​​rdb; when Redis is restarted, you can read the snapshot file recovery data.

　　AOF persistence: AOF persistence (ie Append Only File persistence), Redis is executed each time a write command recorded in a separate log file (a bit like the MySQL binlog); Redis restart when executed again AOF file command to restore the data.

Three. RDB persistent storage

　　1. Manual triggering execution instruction, stores

　　　　save this directive will block redis, no longer receive additional processing before executing the

　　　　bgsave This command creates a child process to deal with persistent storage, online use

　　2. Configure the conf file triggers automatic storage

yes daemonize                     # running in the background 
the bind 127.0.0.1                    # Redis bound address 
Port 6379                         # port 
requirepass RedHat                 # Redis password 
logfile /data/6379/redis.log     # log file 
dir / the Data / 6379                   # define persistent file storage location 

dbfilename dbmp .rdb             # RDB persistent file 
Save 900. 1                     
Save 300 10                         
Save 60 10000                    Save Mn when m seconds, to reach the n memory, the instruction is executed bgsave, persistent storage

Other optional configuration

stop-writes-on-bgsave-error yes # When bgsave error, Redis whether to stop the execution write command; set to yes, then when there is a problem hard drive, you can discover, thus avoiding the loss of data; set to no, Redis errors continue to ignore bgsave write command, when using the Redis server monitoring system (especially the hard disk), this option is set to no consideration

rdbcompression yes # RDB file compression is turned on

rdbchecksum yes # RDB check whether open files, when files are written to the file and read the works; closed checksum can bring about a 10% performance boost when writing to files and startup files, but can not be found when data corruption

Four. AOF persistent storage

　　1. trigger configuration

　　　　Redis service enabled by default RDB, close AOF; AOF open only added appendonly yes in the configuration file

　　　　Priority will be loaded at startup AOF Redis service

　　2. AOF of common configuration

NO appendOnly         # whether to open the AOF of 

appendFileName " appendonly.aof "     # AOF of file name 

dir / the Data / 6379                   # define persistent file storage location 

appendfsync everysec     # persistence strategy, are deposited per second, always always 

NO -appendfsync-ON-rewrite NO      # prohibit during AOF rewrite fsync; if this option is turned on, when overwriting files can reduce CPU and hard disk load (especially the hard disk), but may lose data during AOF rewrite; need to load and safety of balance between 

Auto -aof the rewrite-PERCENTAGE-100     # performing rewriting AOF, AOF current size (i.e. aof_current_size) ratio of AOF size (aof_base_size) and rewriting the first time. 

Auto -aof the rewrite-min-size-64MB      # performing rewriting AOF, minimum file size, default is 64MB. 

aofyes-truncated -load     # If the AOF files ending corruption, whether still loaded when Redis start AOF file

Five. RDB and AOF persistent storage of the advantages and disadvantages

RDB persistence

　　Advantages: RDB file compact, small size, network transmission speed, for the whole amount of replication; recover much faster than AOF. Of course, compared with the AOF, one of the most important advantages RDB is a relatively small impact on performance.

　　Disadvantages: fatal flaw RDB files in persistent mode snapshot of its data can not necessarily determine the real-time persistence, and data increasingly important today, a large number of data loss is often unacceptable, and therefore AOF persistence into the mainstream. In addition, RDB files need to meet certain format, compatibility is poor (such as the old version of Redis is not compatible with the new version of RDB file).

AOF persistence

　　Pros: AOF advantage is that the second-level support persistence, good compatibility,

　　Disadvantages: large file, recovery is slow, high-impact performance right.