方案1：sharding-proxy + sharding-scaling
Other URL
sharding-proxy + sharding-scaling non-stop service sub-library sub-table data migration _HTslide the blog -CSDN blog
ShardingJdbc sub-library sub-table real case analysis (next) blog -51CTO blog -mb5fd8692eb1f28 of
Option 2: Manual operation
Other URL
Downtime migration plan
The big guy starts operation and maintenance at 12 in the morning, and an announcement is posted on the website or app, saying that the operation and maintenance will be carried out from 0 to 6 in the morning and cannot be accessed.
Then it stops at 0 o'clock, the system stops, and no traffic is written. At this time, the old single-database single-table database is static. Then you have to write a one -time derivative tool before , and then run it directly, and then read out the data of the single database and single table, and write it into the sub-database and sub-table.
After the derivative is finished, it is ok. Modify the database connection configuration of the system, including the possible code and SQL. If there is a modification, then you can use the latest code, and then directly start the connection to the new sub-database and sub-table.
Verify it and it’s ok.
Dual-write migration solution (without downtime)
A commonly used migration plan is more reliable, without downtime, and without looking at the scenery at 4 o'clock in the morning.
To put it simply, in the online system, all the places where the library was written before, the addition, deletion and modification operations, in addition to the addition , deletion and modification of the old library , the addition , deletion and modification of the new library are added . This is the so-called double writing . Write both libraries at the same time. Old library and new library.
Then after the system is deployed , the data of the new database is too far away. Use the data guide tool mentioned earlier to run to read the old database data and write the new database. When writing, you must judge the last modification time of this data according to the fields of gmt_modified, unless it is The data read out is not in the new library, or it will be written only if it is newer than the data in the new library. Simply put, it is not allowed to overwrite new data with old data.
After a round of navigation, there may still be inconsistencies in the data, then the program will automatically perform a round of verification, compare each data in each table of the new and old libraries, and then if there are differences, focus on those differences. Read data from the old library and write again. Repeatedly loop until the data in each table of the two libraries are exactly the same.
Then when the data is completely consistent, it is ok. Based on the latest code that only uses the sub-database and sub-table, redeploy once, not just based on the sub-database and sub-table in operation, there is no downtime for a few hours, and it is very stable. .