Overview
This article is the first time to engage in redis master and slave mistakes made by Xiaobai, and the great god can ignore it. Record in order to let Xiaobai learn from the past who saw this blog post
software resources
cents：6.5
redis：2.8.10
background
The company's existing architecture is in stand-alone mode. This article only introduces the pit that redis stands on - that is, the production application redis is a single instance, and once the instance hangs up, the function will not be available. Now the company's business uses one instance (business instance) and one session sharing instance (session instance).
Now it is necessary to upgrade the existing architecture (the related blog about the entire architecture upgrade will be published later), start with the simplest redis, use master-slave replication, and enable sentinel monitoring to perform master-slave switching (there will be related detailed blogs later).
fundamental issue
- Online redis only enables rdb persistence and needs to enable AOF
- Online business instance and session instance keys<1W, you can combine business instance and session instance to save resources
Step on the pit
AOF digging
The master-slave mode has been set up, and it is no problem to create multiple keys for verification. I am very happy. I found that AOF needs to be enabled. I think it is so easy to check the official documentation. So I changed the configuration, restarted the service, and added a key to the master node. Master-slave verification passed, very happy.
[Knock on the blackboard and start digging a hole] At this time, an extreme failure was simulated, the master and slave nodes were stopped, and the services were started in sequence. It was found that there was only one key added after the AOF was turned on, and the tears collapsed. . . .
AOF filling pit
After many attempts, finally found the problem
Problem analysis: Redis runs for a period of time and then starts AOF. The AOF persistent file is an empty file. It only appends the operation records after opening AOF, and the operations before opening AOF will not be recorded, so I opened AOF during the digging process. Afterwards, no operation was performed on those old keys, resulting in no operation of the old keys being recorded. When restarting, only the keys operated after AOF are turned on are restored.
Solution: After running redis for a period of time, before enabling AOF, you must remember to perform AOF persistence on the instance first, that is, persist the data before enabling AOF persistence
He library digging
Because it is too lazy to do a data merge of session instance and business instance, I don't want to write a script for redis data migration. . Thinking of the AOF persistent file, merge the AOF files of the two instances once, and then restart the service to do the database merge operation?
[Knock on the blackboard and start digging a hole]
The content of the AOF file of the business instance is as follows
The content of the AOF file of the session instance is as follows:
Copy the content of the session instance AOF file to the business instance AOF, the content is as follows:
There is also a 25-line blank line at the end of the file itself. I am a clean freak, so I am happy to delete it.
Put the file on the server to replace the AOF file and restart the redis service
AOF corruption error reported
Pool filling pit
Executed the repair command according to the prompt, checked the repaired file and my merged file, and found that the last command was repaired and deleted by itself. It is inferred that there is a problem with the last command.
Problem analysis: Since I deleted the last blank line, the AOF test failed. Looking at the AOF file format, I infer that the blank line is the identification line of redis, which is specially used for appending new commands.
Solution: Add a newline character at the end. Practice has proved that hand-cheap comes at a price! ! ! Hand - cheap is to pay the price! ! ! Hand - cheap is to pay the price! ! !