redis8--data persistence in two ways

Persistence features
For internal data security considerations, Redis saves its own data as a file to a hard disk on the server
After a reboot, the data in the hard drive is restored to the inside of the memory (Redis).

The process of saving data to a hard disk is called a "persistence" effect.

Redis has two persistence features, one is "snapshot persistence" and one is "aof persistence".

1.snap shotting Snapshot Persistence
This persistence is turned on by default, one-time storage of all data in Redis is stored on the hard disk, if there is a lot of data
(10-20g) is not appropriate for frequent operation of this persistence operation.

Our snapshot persistence keeps backups on the hard disk in:

The default file name is Dump.rdb

There is a redis.conf configuration file in our Redis installation directory, which has the configuration of snapshot persistence:

The "Backup frequency" of snapshot persistence is configured.
The meaning of the above three Save:
Very high frequency of data modification and high frequency of backups
Low frequency of data modification and low frequency of backups

The above configuration three can not be missing, this will ensure that regardless of the frequency of modification data is high or low, the data will be saved.

The name and storage location of the file where the snapshot persisted is also configured in the configuration file:


To manually initiate snapshot persistence:
We first add some data to Redis:

We have added a lot of TESTN data, in order to persist these changes, we manually initiate snapshot persistence:


As you can see, the original backup file time has not been November 12, now changed to the program modified 20th:

Let's take a look at what's stored in our cache file:

All of our previous changes have been recorded in the backup file.

Persistence-related directives for Redis:
Bgsave asynchronously saves data to disk (snapshot Save)
Lastsave returns the last Unix timestamp that was successfully saved to disk
Shutdown synchronizing to the server and shutting down the Redis server
bgrewriteaof optimization of aof log file storage when journal files are too long

Snapshot Persistence Disadvantages:
The simulation of a snapshot:

Snapshot persistence every one hours


As you can see, we had a power outage at 10:00-11:00, according to our snapshot persistence every one hours,
The 10:00-10:55 data is not retrieved until the snapshot is executed 11:00.

Solution:
Snapshot persistence every one hours


In every one hours, we do "fine persistence", that is, every change of a key to save,
And the frequency can reach the second level. No matter how many keys you've modified in 1 seconds, just do it once, so
It also saves more memory.

The above-mentioned "fine persistence" is the second persistence method of Redis---Append only file (aof persistence).

2.append only file (aof persistent)
Recall that the backup of the MySQL database is the backup of some SQL statements, the time to restore the execution of SQL statements on the line.
In fact, aof persistence is a similar operation.

AOF Persistence essence: Each "write" instruction (Add/modify/delete) executed by the user is backed up to a file, when the data is restored
is to execute specific written instructions.

Turn on aof persistence (clears the data inside Redis, preferably before Redis is used)
We can find it in the redis.conf configuration file:

Change "no" to "yes" to turn on snapshot persistence.
We can also change the AOP persistence file name (the file location is the same directory as DUMP.RDB).

After the configuration file has been modified, to delete the old process, and then start the new process according to the new configuration file:


You can then find a aof persistent backup file in the sibling directory appendpnly.aof


And then we found out all the data was emptied (default)

The database 0-15 database is empty.

We have created three keys in database 0


Then go back to the root directory and look at the backup file and find that the time and size have changed:


Then take a look at the content:

Found that the instructions we wrote are all backed up, indicating that the backup frequency is still very high.

In redis.conf, you can adjust the frequency of aof backups:

There are three ways to back up:
(1) always
A write command is backed up once. This is safe, but the performance of the system is reduced. Not recommended for use

(2)everysec
Back up once in every second. No matter how many keys are changed in a second, backup only once, performance is protected by some. Recommended use.

(3)No
The current server status is checked and is backed up (randomly) if it is in good condition. This backup method data is not guaranteed.

Compare down, Performance: Always<everysec<no, and data security: Always>everysec>no.


Let's do an example of creating a num data that uses the incr instruction to increment it every second:


We look at our appendonly.aof file to see the backup situation:


In fact, since the increment of 10 times (10 incr num) is equivalent to a set num 10, if only "set num 10" is stored, then
The storage space for backup files can be saved. This involves how we "optimize Processing for aof backup files".

3. Optimized processing for AOF backup files
The so-called optimization, in fact, is to aof backup files of all the contents of the backup data for a processing.

When you start the Redis client, you can use the BGREWRITEAOF directive to make the contents of the AOF backup file
Optimize compression processing.


We can see that the size of the AOF is changed from byte to Byte, proving its contents are compressed.


Take a look at the contents and discover that the backup data store directive has changed:

Sure enough, 10 times incr num became a set num 10

Summarize:
Snapshot persistence and aof persistence are complementary relationships, and snapshot persistence is used for larger backups,
and aof persistence is used to make fine backups.
When data is restored, snapshot persistence and aof persistence can be restored together.
Restore is also very simple, on any one server, as long as the backup file, you can make data backup.

At this point, two persistence methods are described.

redis8--data persistence in two ways