Due to the use of the local environment, a local Redis cluster is built. This article explains the establishment of a Redis master-slave replication cluster. The platform used is Windows, and the idea of building is basically the same as that on Linux!
(It may take you 15 minutes to read this article intensively, and about 5 minutes to skim through)
A brief introduction
to Redis master-slave replication. In order to make the cluster work normally even when some nodes are offline or unable to communicate with most of the nodes in the cluster, Redis cluster uses the master-slave replication function for nodes: each node in the cluster There are 1 to N replicas, one of which is the master, and the remaining N-1 replicas are slaves. [From master-slave replication in Redis cluster]
So the above is master-slave replication. Simply put, a master node master can have one or more slave nodes, and a slave can have multiple slaves. In this way, a powerful multi-level server cluster architecture is formed. .
Among them, the master node is mainly writing (writable or read), and the slave node can only read but not write! [Read-write separation scenario]
The data written by the master node will be synchronized (not quasi-real-time) to the Salve, so that if the master node fails and the data is lost, it can be restored through the Salve. [Disaster recovery scenario, note: Because the data is not synchronized in real time, there may be data loss problems after recovering data from the Salve]
In summary: The following are some features of redis master-slave replication:
1. A master can have multiple slaves
2. In addition to multiple slaves connected to the same master, slaves can also connect to other slaves to form a graph structure
3. Master-slave Replication does not block the master. That is to say, when one or more slaves and the master synchronize data for the first time, the master can continue to process the request sent by the client. On the contrary, when the slave synchronizes the data for the first time, it will block the request from the client that cannot be processed.
4. Master-slave replication can be used to improve the scalability of the system. We can use multiple slaves specifically for client read requests. For example, the sort operation can be handled by slaves. It can also be used for simple data redundancy.
5. You can disable data persistence in the master, just comment out all save configurations in the master configuration file, and then configure data persistence only on the slave.
6. It can be used for read-write separation and disaster recovery.
Several commonly used methods of Redis master-slave replication
One master and two servants A (B, C), one Master and two slaves
(decentralized) A-B-C, B is both the master node (the master node of C), It is also the slave node (A's slave node) to the
guest-oriented (after the master node is down, manually upgrade the slave node to the master node) & sentinel mode (after the master node is down, the slave node is automatically upgraded to the master node)
This time I mainly introduce one The master and second servant, and the operation of anti-guest-oriented, are passed down without introduction. Write an introduction after the sentinel mode!
Redis master-slave replication construction (one master and two servants)
1. Download the Redis installation package of the Windows environment, and download it from Baidu
2. After the download is complete, unzip the
unzipped directory as shown in the figure below:
3. Related configuration operations
(1) After copying three copies,
I modified the name of Redis locally after unzipping , and the folder name after copying is displayed as follows:
Redis-x64-3.2.100-6379
Redis-x64-3.2.100-6380
Redis-x64-3.2.100-6381
(2) Modify the redis.windows.conf
6379 folder without modification!
6380 folder, amended as follows:
port 6380
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379
6381 folder, amended as follows:
port 6381
slaveof 127.0.0.1 6379
I assume that everyone knows the relevant configuration of redis.xx.conf! If you don’t know, please see:
Redis learning-introduction to redis.conf configuration file
(3) Add a simple window script to facilitate quick start!
Create a new one under the corresponding redis folder
startRedisServer.bat
The content of the script is:
@echo off
redis-server.exe redis.windows.conf
@pause
Then create a new directory in the same level of the redis folder
start6379.cmd
@echo off
cd Redis-x64-3.2.100-6379
startRedisServer.bat
Then 6380 and 6381 are the same as the above operations. After the operation is completed, the following figure is shown:
4. Start the test
Start rule: start the master node first, then start the slave node!
(1) You can use the command to start
Enter the corresponding folder directory, and use the start command:
(2) Use the script to start
As shown in the picture above, execute start6379.cmd,
start6380.cmd, and start6381.cmd respectively.
(3) If you can't start three redis on this machine at the same time using the above method, then please see here
Start the Master first. Use the client to log in and view the information as shown in the figure:
then start 6380 and 6381, and then you can see: as shown
in the figure. View the master-slave replication information of 6378 here: as shown
in the figure. In the client of 6380 and 6381, check the node information: as shown in the figure.
Test read and write, [the master node can read and write, the slave node can only read and not write], as shown in the figure below:
test the status of the slave node after the master node is shut down [the slave node is readable, and the slave node will not be upgraded to the master node] :
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381> get hello
"world"
Test the status of the slave node after the master node restarts [the slave node can still connect to the master node]:
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=43,lag=0
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
127.0.0.1:6379>
Episode [Anti-customer-oriented]
Test when the master node is shut down, use slave of no one. Yes, 6380 becomes the master node, but it is only the master node, without any slave nodes! ：As shown
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:155
master_link_down_since_seconds:jd
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381>
127.0.0.1:6381> slave no one
(error) ERR unknown command 'slave'
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381> set test 11
OK
127.0.0.1:6381> get test
"11"
127.0.0.1:6381>
For details, please refer to the content in Redis master-slave replication !
The principle of Redis master-slave replication The
first introduction
When the slave server is set up, the slave will establish a connection with the master, and then send the sync command.
The master receives the command to start the background save process, and at the same time collects all the received commands for modifying the data set. After the background process is executed, the master will transmit the entire data file to the slave to complete a complete synchronization.
Full copy: After the slave service receives the database file data, it saves it and loads it into the memory. (First full amount)
Incremental replication: The Master continues to pass all the new collected modification commands to the slave in turn to complete the synchronization. (Increment afterwards)
But as long as the master is reconnected, a complete synchronization (full replication) will be executed automatically.
When the slave server is set up, the slave will establish a connection with the master and then send the sync command. Whether it is the connection established for the first time or the reconnection after the connection is disconnected, the master will start a background process to save the database snapshot to a file, and the master master process will start to collect new write commands and cache them. After the background process finishes writing the file, the master sends the file to the slave, and the slave saves the file to the disk, and then loads it to the memory to restore the database snapshot to the slave. Then the master will forward the cached commands to the slave. And subsequent write commands received by the master will be sent to the slave through the connection established at the beginning. The command to synchronize data from the master to the slave and the command sent from the client use the same protocol format. When the connection between the master and the slave is disconnected, the slave can automatically re-establish the connection. If the master receives simultaneous connection commands from multiple slaves at the same time, it will only start a process to write database mirroring, and then send it to all slaves.
The second introduction: the
source network of the image content: the
third introduction:
Redis master-slave synchronization has two methods (or two stages): full synchronization and partial synchronization.
When the master and slave are just connected, perform full synchronization; after the full synchronization ends, perform partial synchronization. Of course, if necessary, Slave can initiate full synchronization at any time. The Redis strategy is, in any case, it will first try to perform partial synchronization. If it is unsuccessful, the slave is required to perform full synchronization and start BGSAVE... After BGSAVE is over, the RDB file is transferred; if successful, the slave is allowed to perform partial synchronization and transfer Data in the backlog space.
Redis master-slave replication (one-master, two-slave/one-master, multiple-slave) analysis
IO surges.
Every time the slave is disconnected (either actively disconnected or network failure) and then connected to the master, all the masters must be dumped out of RDB, In aof, the synchronization process must be executed again; so remember that multiple slaves should not be started all at once, otherwise the master may increase IO sharply (1-2 minutes apart)
Replication delay
Because all write operations are performed on the Master first, and then synchronized to the Slave, there is a certain delay in synchronizing from the Master to the Slave machine. When the system is very busy, the delay problem will be more serious. The number of Slave machines The increase will also make this problem more serious.
Low availability
When an abnormal situation occurs on the master node, it will not be able to write, leading to business errors! [The solution is to use the Redis-Sentinel mode, see the second article of the series for details]
Note:
Redis cluster does not guarantee strong data consistency (strong consistency) Redis cluster consistency guarantee (guarantee) : Under certain conditions, Redis cluster may lose the write commands that have been executed.
————————————————
Copyright Statement: This article is the original article of the CSDN blogger "Afeiyun", and it follows the CC 4.0 BY-SA copyright agreement. Please attach the original source link and this for reprinting. statement.
Original link: https://blog.csdn.net/u010648555/article/details/79427606
The author’s stuff is very interesting, you can look at the content inside