First, Redis persistence
Redis is an in-memory database, and all data is stored in memory, and we know that when the server shuts down unexpectedly, the data in memory is lost, but Redis provides us with persistence so that we can save the data to the hard disk. Redis offers two ways to persist, namely RDB and AOF, each with its own characteristics. Both of these approaches are described below.
1. RDB mode
By default, Redis is enabled for RDB persistence, and is primarily specified by several parameters in the configuration file:
Save the 1 # After the sec (min) if at least 1 key changed Save - Ten # after the sec (5 min) if at least ten keys changed Save - 10000 # After the sec if at least 10000 keys changedStop-writes-on-bgsave-Error Yesrdbcompression Yesrdbchecksum yesdbfilename Dump.rdb # The filename where to dump the DB dir/var/redis/6379 # The data file ' s directory.
The save parameter specifies the snapshot condition, which can have multiple conditions, between a condition or a relationship, as stated above: Save 900 1 means that at least one key in 15 minutes is changed to take a snapshot.
The principle of snapshot execution:
- Redis uses the fork function to copy a copy of the current process (the parent process) (child process)
- The parent process continues to process the task, and the child process begins to write the in-memory data to a temporary file on the hard disk
- When the child process finishes writing all the data, it replaces the old Rdb file with the temporary file, which is done by the snapshot.
When the fork function is executed, the operating system uses a write-time replication policy, that is, when the fork function occurs, the parent process and the child process share the same memory data, and when the parent process needs to modify a piece of data, the slice data is copied to ensure that the child process is not affected. So the new RDB data file is the memory data that executes the fork moment. Through the above process can be known, Redis in the snapshot process will not let the data change, only after the end of the snapshot will be the old file as a new file, that is, any time the Rdb file is complete, so we can use the Redis data backup with a scheduled backup Rdb file.
In addition to automatic snapshots, you can manually send the save and Bgsave commands for Redis to take a snapshot, the difference between the two commands is that the primary process is a snapshot operation that blocks other requests, while the latter executes the snapshot through the child process.
After Redis boots, the Rdb snapshot file is read and the data is loaded into memory from the hard disk. This load time varies depending on the amount of data, structure, and server performance.
By using the Rdb method to persist, once the redis unexpectedly exits, it loses the data modified after the last snapshot, and if it cannot withstand any loss of data, try to use the AoF method.
2, AoF Way
By default, the AOF mode is not enabled and can be opened by adding the AppendOnly parameter to the configuration file:
appendonly Yes " appendonly.aof " Appendfsync everysec Auto #当目前aof文件大小超过上一次重写时aof文件大小百分之多少时进行重写, if you have not previously rewritten, start with a size of auto-aof-rewrite-min- Size 64MB #限制容许重写的最小aof文件大小
Where the appendfsync parameter has three values:
- EVERYSEC: The default value, which is synchronized to the hard disk once per second.
- Always: Perform a synchronization every time the data changes
- No: not synchronized, fully synchronized by OS cache
Redis allows aof to coexist with an RDB, at which time restarting Redis reads the aof file to the in-memory recovery data.
Second, Redis replication
Persistence with aof and RDB can prevent data loss, but for a server, if the hard drive is broken, the data is lost. In order to avoid a single point of failure, you can copy one server data to several other servers, even if there is a failure, others can also provide services. REDIS provides replication capabilities to automatically synchronize data.
1, the Principle of replication
Understanding the principles of replication is useful for operations.
When one starts from the database, the active primary database sends the Sync command, and the master receives the Sync command and starts to save the snapshot in the background (the RDB persistence process) and caches the commands in the snapshot process. When the snapshot is complete, the snapshot and cached commands are sent to the slave database. After receiving from the database, load the snapshot and execute the cache command. When the master-slave database is disconnected, the above steps are re-executed, and the breakpoint is not supported for onward transmission.
2. Configuration replication
Environment Description: IP function 192.168. 245.129 master 192.168. 245.131 Slave
Configuring Master-slave replication in Redis is as simple as adding slaveof <masterip> <masterport> parameters from the database configuration file, without any configuration for the primary database.
In the 192.168.245.131 configuration file, add the following:
192.168. 245.129 6379
Then reboot the slave server ( must be restarted, otherwise the parameter has no effect )
/etc/init.d/redis_6379 Stop/etc/init.d/redis_6379 start
Execute a command in the primary database:
127.0. 0.1:6379> set foo testmasterok
View results from database:
127.0. 0.1:6379> get foo"testmaster"
3. Other instructions
Redis's slave database can also be used as the primary database.
Redis's time-consuming operations are data persistence, and in order to improve performance, we can unify data persistence from the repository and ensure data security. Here's how:
- Create one or several from the database by copying and turn on persistent functionality
- Shutting down the persistence of the primary database
- If the primary database fails, the slaveof no one command from the library is promoted from the database to the primary database
- If the master database is restored, it can be set again to the new primary database from the database
Management of Redis