Kept to implement redis autofailover (redisha) 14

Here are the differences

4c4

< router_id LVS_redis-b

---

router_id LVS_redis-a 19c19

< priority 139

---

priority 138priority The range is 1-255

Note: priority High values will automatically become master , So when assigning priorities master To set a relatively high value , But it can't be compared with backup Higher than weight Adjustment value , otherwise keepalived The check found that the service was unavailable , Corresponding priority After reducing , It's still better than backup High priority , So I will continue to act as master , Don't let go VIP, At this point, the client access will not achieve the desired results

Startup sequence

This redis+keepalived The start-up sequence of the cluster is quite particular , Otherwise, there will be an accident

Start as master Of redis ( Or there is just one running in production redis)

Start as slave Of redis

stay slave On the implementation SLAVEOF And master To synchronize ( Select a service low peak point )

adjustment master Upper keepalived priority Make its value s.priority < m.priority < s.priority+weight ( In order to master By keepalived After checking and confirming the failure ,slave You can become a new candidate by your own priorities master)

start-up master Upper keepalived

start-up slave Upper keepliaved

Note: This way you can only fight once master Unplanned failover of , Or planned switching , If you want to use it again , You have to manually build again in the above order , Why not automate , Because ,SLAVEOF It's a lethal order , Normal conditions can cause significant stress on the server , Accidents can ruin master The data on the , For example, with an empty redis To synchronize , Will cause their own data to be erased