In windows, basic redis operations and master-slave replication allow data backup and read/write splitting, and redis Data Backup
Crawlers reprinted address this article address-blog garden snail http://www.cnblogs.com/tdws/p/5705782.html
When the ECS instance expires, this test will be conducted locally (127.0.0.1 ). There are three redis clients with ports 6, 6381, and respectively.
First, copy three copies of your redis instance (redis3.2.1 is used). If you cannot download it, you can leave an email or send a private message to me.
First open cmd and use cd to find your redis folder. My operation is
In the configuration file of your first redis client folder, search for port and find the following location:
Set the port number to 6379 (default. The next one, two or more clients respectively modify the port number you want to use. Here I use)
In this way, the 6379 rendi client has been started. You only need to modify the port number in the configuration file and then open redis in the same way.
Next, open the client operation console corresponding to each apsaradb for redis, enable the new cmd, and switch to the drive letter you need. The method is as follows.
In this way, the redis client console has been started, and we can operate set get flushdb save and so on normally.
Of course, the redis operation console of the other two port ports also starts like this, But modify your port number to your corresponding.
Next I will use 6379 as the master node, and as the slave node of slave.
The test procedure is as follows:
First, flushall ensures that the cache is cleared. Next, set three data items and run the "keys *" command to view all current key val values.
Next, let's manually make redis of port 6380 as the slave node of port 6379. The operation is as follows:
Use the slaveof command to achieve the goal. Of course, in such a command, after redis crashes, their master-slave relationship does not exist. Later, we will talk about how to permanently determine the master-slave relationship.
Let's test whether the data is synchronized.
Still use the keys * command. We can see the result. Data is successfully synchronized from the master node to the slave node. The same applies to port 6381 synchronization.
Now I add data in master 6379 and then view the contents of the slave node.
Run the "keys *" command again from the node to View Details:
You can see that 6380 data has been synchronized to the master node.
Next we are trying an operation:
I am trying to set the value in the slave node, prompting that the slave server is read-only. But we can operate save from the node, which is also a type of redis data backup.
Now, the master-slave replication configuration is complete. This is also the principle of implementing read/write splitting. Data is read from multiple servers and manipulated in the master.
However, I don't think this can be used in common scenarios. Unless the write volume is relatively small and the read volume is special, we choose read/write splitting.
Finally, you can set the permanent master-slave relationship by searching the slaveof keyword in the configuration file of the slave node:
Perform the preceding configuration to automatically synchronize all data whenever you restart the redis service.
In the case of general configuration policies, the master and slave nodes are all mounted. Of course, we can solve this problem.
If you have any questions or suggestions, please contact us.