Redis simple HA solution Summary

Policy summary

The master and slave nodes are mutually standby, with no read/write splitting. The slave database is only synchronous and does not provide external services. The master database has no persistence policy, and the backup database uses RDB.

HA solution

The original cache01 is used as the master,Persistence is not required to provide optimal read/write performance.

Apply for a new cache02 slave, Persistence uses RDB, Data synchronized from cache01 is not provided for external services, Only used as backup.The application points to the VIP on F5 and indirectly calls the master. NOTE 1: The configuration file uses the master configuration ( In addition to the memory usage restrictions), after starting the service, run the corresponding command to switch to the role.Note 2: The RDB persistence trigger policy is: There are n updates in a minute or updates in B minutes. The startup command is ConfIG set save "B 1 A N" ; Close the command Config set save "" .Step 1: copy the configuration file of the master, Modify the memory usage restriction configuration item maxmemory. 2. Start the slave Redis Service process, execute commands SlaveoF masterip masterport . 3. Start the RDB persistence policy. 4. Verify that the data synchronization is complete. If the master node fails, perform the following steps: 1. Run the command on the original slave. Slaveof no one Disable synchronization and upgrade to new master2 and F5 to point to the original slave to ensure that the application can continue to provide external services. 3. After the original master is restored, start Redis Service Process and execute commands Slaveof original slaveip original slaveport To downgrade to a new slave, And synchronize data from the master. 4. Shut down the master and open the RDB on the slave, To ensure the read/write performance of the master.

Q &

1. Why is it not persistent in the master, but in the slave?Persistence? What is the meaning of persistence in slave? A: Redis Persistence supports two modes: Rdb (memory snapshot) And aof (similar to redo log), which have certain performance overhead. In the case of highly concurrent access, The RDB mode causes significant service performance indicators to jitter or even stop for 1 second; Aof has better performance overhead than RDB, However, the time when the data is reloaded to the memory during data recovery is proportional to the amount of data. To ensure the best performance of the master, you can disable persistence, Data security is not a problem because of master-slave mutual backup. Regular backup has additional benefits, For example, you can easily roll back data to a certain time point, It also facilitates online real data testing in the offline environment. 2. The principle of master-slave synchronization uses replication.Does read/write splitting improve performance, rather than disaster recovery? A: Replication Supports both disaster recovery and read/write splitting, The two do not conflict. At present, the application layer is not provided Redis Causing great pressure, Read/write splitting is not considered for the moment. . In fact, it is also possible for a single machine to use persistence for disaster recovery, However, the availability is lower ( Re-loading data to memory is similar to restoring the PC from sleep state ), Secondly, in extreme cases, if the hard disk breaks down, it will be too much trouble. Yes. Redis Replication has nothing to do with persistence. . Once the master-slave connection is recovered from the disconnected state, Slave does not care whether this is the first connection. It always performs full synchronization. So in the synchronization process, Slave cannot provide data consistent with the master. Redis Two policies are available for slave: The system responds to the old data or returns an error and prompts that synchronization is in progress, Different applications have different levels of tolerance for data consistency and can be flexibly selected.