Nosql-redis Backup

Redis Persistence – Two ways

Redis provides two ways to persist, namely, RDB (Redis DataBase) and aof (Append only File).

Official advice: Both options are open and backed up at the same time. The optional snapshot RDB is not high-endurance.

RDB: At different points in time, the Redis stored data is generated and stored on the disk and other media;

Advantages: Small backup file size, fast recovery, fork child process does not affect the parent process IO;

Disadvantage: Loss of data when the fault is more points, the data set is large, because the fork process is slow, resulting in client response delay;

Configuration: Save 600 1, default is Dump.rdb (config get Save && config get dir ...). ）

AOF: It is to record all the written instructions that Redis has performed, and when the next Redis restarts, the write commands are executed again and again, and the data can be restored, similar to the MySQL Binlog. Find cache instruction records based on Fsync policy

Advantages: Good data integrity, the volume is too large will be automatically rewritten (100 write to 1 set), using the Redis protocol easy to read;

Disadvantage: Large file size, slow recovery, the existence of fsync strategy caused by slow speed;

Configuration: appendonly Yes, default file name Appendonly.aof (CONFIG GET appendonly);

Recovery: For example, the Flushall is executed, and the backup file is deleted and restarted.

Note: To rewrite, Redis 2.2 needs to manually execute the bgrewriteaof command itself; 2.4 can automatically trigger AOF overrides.

AOF File Error: (Will refuse to load aof file when Redis restarts)

A, back up the existing AoF file

B, # redis-check-aof--fix command line to perform repair of existing aof files

C, compare two aof file differences, restart the server, load the repaired aof backup file

With two backup strategies in the same time, the default aof is preferred in Redis restart because of high data integrity.

Turning off the use of two backup strategies, Redis becomes a memory database, as memcache.

Master-Slave Backup:

650) this.width=650; "src=" Https://s1.51cto.com/wyfs02/M02/8F/80/wKiom1jh1rmArNcFAABamyv4gEw687.png "title=" Clipboard.png "style=" width:500px;height:275px; "alt=" wkiom1jh1rmarncfaabamyv4gew687.png "vspace=" 0 "hspace=" 0 " height= "275" border= "0" width= "/>"

Architecture and Principle: a master can be more from, can also be equipped with more from;

1, from the connection to the primary server, send Sync command;

2. After the master receives the sync instruction, it starts executing the Bgsave and writes the command to the buffer;

3, after the end of the Bgsave, the Lord will save the. Rdb snapshot file sent to all from, during the continued record write operation, Telnet verifiable;

4. Load the new snapshot from discarding the old snapshot. After completion, the master continues to send a write instruction for the buffer from the incremental backup.

Configuration: The settings from the server are as follows (can also be modified within Redis, but it is recommended to modify the configuration file)

Slaveof 192.168.1.1 6379//Configure the primary IP and port

Masterauth <password>//Configure Master's password

Slave-read-only Yes//Let read-only, 2.4 defaults after reading

Repl-ping-slave-period 10//Set slave the frequency of pings to master, initiated every 10s

For more detailed configuration, see the Redis section.

Synchronization policy:

The policy is to first attempt an incremental synchronization, such as unsuccessful, requiring a full-volume synchronization from the machine, followed by an incremental synchronization.

This article is from the "North Ice--q" blog, please be sure to keep this source http://beibing.blog.51cto.com/10693373/1912969

Nosql-redis Backup