Risks arising from configuring the Read mode in spring for data migration

Risks arising from configuring the Read mode in spring for data migration
After the database migration, modify the Hibernate configuration file context-hibernate.xml connection string, the file is backed up before modification,
The backup file is the recovery context-hibernate.xml, And the backup location is the current folder.
When the original database is not stopped, restart the application and find that the application is connected to both databases. Check whether other configuration files have not been modified,
Development indicates that only connections are configured in this place, and there are no omissions. No other configuration items need to be found in the search for the entire folder. Later, I thought about whether there is a problem with the application's read configuration method settings,
This won't read all. xml in the configuration folder, so I moved the "Replica context-hibernate.xml" to another place, restarted the application, and found that the application is completely connected to the new application.


Afterwards, we found that the spring configuration reading method was set as follows:
-<! -- Set the spring configuration file
-->
-<Context-param>
<Param-name> contextConfigLocation </param-name>
<Param-value> classpath *: **/* context *. xml </param-value>
</Context-param>
 
Fortunately, our database is basically static and only synchronizes data from other places in the early morning. If it is an online system with many transactions, this situation is likely to result in the latest transaction data in both databases,
Serious consequences.
Remember:
1. It is best not to back up the configuration file in the same directory.
2. After you modify the configuration and restart the database, check the connection conditions on both sides in a timely manner.
3. Stop the original database immediately to avoid data confusion.