It's still a matter of migration
Redis master-slave architecture and high availability implementation
introduction
In today's applications, high availability and performance are crucial. This article will explain how to use the Redis master-slave architecture and Linux virtual server (LVS) to achieve high availability, and will also provide detailed descriptions of the recently completed Redis cluster migration deployment.
What is Redis?
Redis is an open source in-memory database that is widely used in cache and data storage. It is well known for its excellent performance and flexible data structure support, so it is widely used by many large-scale applications.
Redis master-slave architecture
Redis adopts a master-slave replication architecture, which is a way to achieve high availability and scale-out. In the Redis master-slave architecture, there is a master server and multiple slave servers, the master server is used for write operations and the slave server is used for read operations. This can improve performance and data redundancy.
Main server
The master server receives write requests from the client and copies these requests to the slave server. It is responsible for the writing and maintenance of data.
From the server
Copy the master server's data from the server and use it for read operations. If the master server fails, the slave server can be upgraded to the master server to maintain high availability.
Redis high availability
High availability is the ability to ensure that the system is still available when facing failure. High availability can be achieved using Redis master-slave architecture. But to further improve availability, we can introduce Linux virtual servers (LVS).
Linux Virtual Server (LVS)
LVS is a Linux kernel module for load balancing. What we are using here is to realize master-slave switching. When the master service redis is abnormal, it can switch the slave server to the master server.
Recent migration deployment process
Migration Plan
After introducing the Redis master-slave architecture and LVS, let's review the recent Redis cluster migration deployment process. Before the migration, we developed a detailed migration plan and testing process.
Data backup
First, we backed up the data of the existing Redis cluster. This is a critical step to ensure that no data is lost during the migration. We used Redis's snapshot feature to create data backups.
Redis deployment
After the backup was completed, we performed a network switch. We switched traffic from the old Redis cluster to the new Redis cluster while introducing LVS for load balancing. This process requires careful adjustment of network configuration to ensure smooth switching.
Redis deployment is very simple, just compile and install it directly. Because we are migrating, we can just take the old packages and use them directly.
Main redis configuration file
# cat daemonize yes pidfile "/var/run/" port 16465 timeout 300 tcp-keepalive 60 loglevel notice logfile "/data/log/" databases 16 stop-writes-on-bgsave-error no rdbcompression yes rdbchecksum yes dbfilename "" dir "/data/datafile" masterauth "password" slave-serve-stale-data yes slave-read-only yes repl-ping-slave-period 10 repl-timeout 600 repl-disable-tcp-nodelay no repl-backlog-size 64mb repl-backlog-ttl 3600 slave-priority 100 requirepass "password" maxmemory 10000000000 maxmemory-policy noeviction appendonly no appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb lua-time-limit 5000 slowlog-log-slower-than 20000 slowlog-max-len 128 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 8gb 4gb 600 client-output-buffer-limit pubsub 32mb 8mb 60 aof-rewrite-incremental-fsync yes lazyfree-lazy-expire yes lazyfree-lazy-server-del yes slave-lazy-flush yes aof-use-rdb-preamble yes maxclients 4064
There will be one more line from the redis configuration file
slaveof hostip 16465
Start Redis
/data/redis/bin/redis-server /data/redis/conf/
Check the info information and confirm that the master can connect to the slave library
lvs deployment and configuration
Keepalive can be installed directly
Then modify the keepalived configuration file
# cat /etc/keepalived/
global_defs {
router_id LVS_DEVEL
script_user root
enable_script_security
}
vrrp_script chk_16465 {
script "/var/keepalived/scripts/redis_check.sh password 16465"
interval 1
weight -20
rise 3
fall 3
}
vrrp_instance redis_6465 {
state BACKUP
interface bond1
virtual_router_id 52
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
vip
}
track_script {
chk_16465
}
notify_master "/var/keepalived/scripts/redis_master.sh password 16465"
notify_backup "/var/keepalived/scripts/redis_slave.sh password 16465 masterip "
notify_fault "/var/keepalived/scripts/redis_falut.sh"
notify_stop "/var/keepalived/scripts/redis_stop.sh"
}If it is the main one, the corresponding modifications need to be as follows:
state MASTER priority 100
Several scripts are involved, as follows:
#cat /var/keepalived/scripts/redis_check.sh
#!/bin/bash
CMD_RES=`/paic/redis/4.0.10/bin/redis-cli -a $1 -p $2 PING 2>/dev/null`
LOG_FILE="/var/keepalived/logs/"
if [ "$CMD_RES"x == "PONG"x ]; then :
echo "[CHECK] `date`, SUCCESS" >> $LOG_FILE 2>&1
exit 0
else
echo "[CHECK] `date`, ERROR" >> $LOG_FILE 2>&1
exit 1
fi
# cat /var/keepalived/scripts/redis_master.sh
#!/bin/bash
CMD="/paic/redis/4.0.10/bin/redis-cli"
LOG_FILE="/var/keepalived/logs/"
echo "[MASTER] `date`" >> $LOG_FILE
echo "Run SLAVEOF NO ONE cmd" >> $LOG_FILE
$CMD -a $1 -p $2 SLAVEOF NO ONE >> $LOG_FILE 2>&1
#cat /var/keepalived/scripts/redis_slave.sh
#!/bin/bash
CMD="/paic/redis/4.0.10/bin/redis-cli"
LOG_FILE="/var/keepalived/logs/"
echo "[BACKUP] `date`" >> $LOG_FILE
echo "Being slave wait to sync data" >> $LOG_FILE
sleep 1
echo "Run SLAVEOF cmd" >> $LOG_FILE
$CMD -a $1 -p $2 SLAVEOF $3 $2 >> $LOG_FILE 2>&
#cat /var/keepalived/scripts/redis_falut.sh
#!/bin/bash
LOG_FILE="/var/keepalived/logs/"
echo "[FAULT] `date`" >> $LOG_FILEtest
After the migration was completed, we conducted a series of tests to ensure that the new Redis cluster works properly. We simulate various failure situations to verify the effectiveness of high availability configurations.
After kiiling the main redis process, you can see that the virtual ip is transferred to the slave machine. After linking through redis-cli, the slave redis can be written normally, and the role is converted to master.
in conclusion
By using Redis master-slave architecture and Linux virtual servers, we successfully achieved high availability and performance scaling. The recent Redis cluster migration deployment process has also been successfully completed. We now have a stable and reliable Redis environment that meets the needs of our applications.
Redis's powerful performance and high availability make it the preferred database engine for many applications. Hope this article helps you understand Redis master-slave architecture, high availability, and migration deployment process.
This is the article about Redis master-slave architecture and high availability implementation. For more related Redis master-slave architecture and high availability content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!