Feelings about Remote Disaster Recovery
1. Use N nodes to accommodate M nodes. For example, if three nodes have 50% redundancy, one node can be taken down;
2. Frequent drills. For example, if you switch one time in a month, if you don't have any problems, you will be hesitant to switch for an hour. The evaluation cycle is too long;
3. Try to be homogeneous among nodes. Otherwise, synchronization between nodes is very painful;
4. Ensure full synchronization between nodes. For example, if the Cache is not synchronized, one node is down. After the switchover, all the caches are worn out. The original Redundancy cannot be supported, resulting in all the data being down;
5. Prepare for downgrade. The redundancy you assume is an ideal vacuum environment. It only exists theoretically and must be prepared for degradation.
In addition, I shared my feelings with a Teacher Zhang yesterday. I recorded the following information:
1. All technical specifications and requirements are nonsense. You must use technical means to convert them into executable things, for example, it is abstracted into a unified security access service, a unified lib library for encryption and decryption, and a unified input parameter verification library.
2. Ask different people to write different codes. The technical backbone should write the CBB content, and ordinary technicians should write other business logic.