Redis replication (replica)
what is it
It is master-slave replication, the master is mainly for writing, and the slave is mainly for reading. When the master data changes, automatically synchronize the new data to other slave databases asynchronously
Separation of reading and writing
Disaster recovery
Data backup
Horizontal expansion to support high concurrency
Case demonstration
Architecture description
One Master, two Slaves, and three virtual machines, each of which is installed with redis and
copies multiple redis.conf files
redis6379.conf、redis6380.conf、redis6381.conf
Tips
The three virtual machines need to be able to ping each other and pay attention to the firewall configuration
Three commands:
master-slave replication
replicaof main library IP main library port, with slave (library) not with master (library)
Change door
slaveof new main library IP new main library port
self-made king
slaveof no one
Modify the details of the configuration file and operate
redis6379.conf as an example. The steps are as follows:
Open daemonize yes
Comment out bind 127.0.0.1
protected-mode no
specify the port
to specify the current working directory, dir
pid file name, pidfile
log file name, logfile. If the log file is at the same level as the startup file, it can be configured as ./6379.log, otherwise the absolute path must be written here, which is a huge pit! ! !
requiredpass
dump.rdb name
aof file, appendfilename
The password masterauth for the slave to access the master must
be configured for the slave, not for the master
One master and two slaves
Solution 1: The configuration file is fixed to write the master-slave relationship.
Configuration file execution: replicaof master library IP master library port
Configure the slave (library) but not the (master) library: configure the slave machine
first master, and then start the two slaves in turn
View the master-slave relationship
log
Host log, vim 6379.log
standby log tail -f 6380.log
command
127.0.0.1:6379> info replication
Solution 2: Command operation manual master-slave relationship instruction. The slave
machine is shut down and the configuration items in the configuration file are removed. The 3 machines are currently in the master state, and each is not subordinate.
3 masters
Execute command on preset slave
salveof main library IP main library port
Configure the difference between VS commands
Configuration, lasting and stable and permanently effective;
command, as effective
The torch is passed
on. The previous slave can be the master of the next slave, and the slave can also receive connection and synchronization requests from other slaves. Then the slave acts as the next master in the chain, which can effectively reduce the writing pressure of the main master and change the direction in the middle
: The previous data will be cleared, the master-slave relationship will be re-established, and the latest
slaveof new master database IP will be copied, and the new master database port
will be reversed
. slaveof no one will stop the current database from synchronizing with other databases
Replication Principles and Workflow
Slave starts, and at the beginning of the
synchronization, the slave will send a sync command after successfully connecting to the master.
The slave will connect to the master for the first time. A complete synchronization (full copy) will be automatically executed, and the original data of the slave will be overwritten and cleared by the master data.
For the first connection, the full replication
master node will start saving snapshots in the background after receiving the sync command (that is, RDB persistence, RDB will be triggered during master-slave replication), and at the same time collect all received commands for modifying the data set and cache them. After the master node executes RDB persistence, the master sends the RDB snapshot file and all cached commands to all slaves to complete a complete synchronization. After the
slave service receives the database file data, it saves it and loads it into the memory, so that complete replication initialization
The heartbeat continues, and the communication
repl-ping-replica-period 10
is kept stable. The incremental replication
master continues to automatically transmit all the new collected modification commands to the slave one
by one. After completing the synchronization, the slave goes offline, and
the master will check the backlog for re-transmission. Inside the offset, master and slave will save a copied offset and a masterId, and the offset is saved in the backlog. The master will only copy the data behind the cached offset to the slave, similar to a breakpoint resume
downside of copying
Replication Delay, Signal Attenuation
Since all write operations are performed on the Master first, and then updated to the Slave synchronously, 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, and the number of Slave machines will increase. It will also make this problem worse.
What should I do if the master hangs up?
By default, a master is not automatically selected in the slave node
Does it require manual intervention every time? -> Unattended becomes rigid demand