There are four situations in the use of keepalived + redis:
1. keepalived is suspended, and redis is also suspended. In this case, redis data synchronization is not required after the VIP is directly migrated, because redis is suspended, you cannot synchronize data on the master node, but the data that has been written on the master node but has not been synchronized to the slave node.
2. The other is keepalived, but redis does not. After the VIP leaves, the Master/Slave of redis is still the old ing relationship. If it does not change, the data will be written to the redis slave, so as not to synchronize to the master, this requires the use of monitoring scripts to reverse the redis Master/Slave relationship. At this time, we need to reserve a little time for data synchronization, and then reverse the Master/Slave.
3. Another type is keepalived and redis fails. At this time, according to the monitoring script, redis crashes and the priority of the keepalived master is reduced, which also causes the VIP to flow away, in the same case as in the second case, data synchronization is also required, and then the Master/Slave relationship of the current redis is reversed.
4. Later, keepalived was not suspended, and redis was not suspended. It was a great deal of luck and there was no operation required.
Keepalived + redis Problems