Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 从 2.0 到 6.0 最省人力最稳的升级方式是什么？
|
username: Billmay表妹
Are there any good methods for upgrading TiDB 2.0 to TiDB 6.0? Besides the upgrade path of 2.0 → 3.0 → 4.0 → 5.0 → 6.0
Requirements:
The most stable and labor-saving method, I think, is to set up a 6.0 cluster and use the TiCDC synchronization tool to synchronize the data from 2.0. When switching over, pause the business to compare the data, and if there are any issues, you can roll back.
I agree more with the solution of synchronizing with a new cluster and then switching over, but for some resource-constrained colleagues, what is the best solution for an in-place upgrade?
Is it as the documentation says, 2.0-3.0-4.0-6.1? Or 2.0-3.0-4.0-5.0-6.0?
+1 Data synchronization, switching clusters, higher efficiency
Upgrading from 2.0 to 6.0 indicates that the original cluster has been running for several years, and the hardware resources might also need an update. From this perspective:
Applying for new resources, setting up a new cluster, synchronizing data, and switching over at an appropriate time is the most reliable approach.
Building a new one directly is indeed the fastest, least labor-intensive, and most appropriate approach.
It is necessary to set up a new cluster, as each major version upgrade has many considerations, especially involving the switch from the management tool Ansible to TiUP.
Considering comprehensively, in-place upgrades have a significant impact and complex procedures. We need to consider rollback in case of unsuccessful upgrades, downtime, etc. Setting up a new cluster with real-time synchronization means the downtime is just the switchover time. The original cluster can still serve as a backup. If the new version doesn’t work well, we can switch back to the original cluster as a backup plan.
Generally, version upgrades need to go through various testing environments such as SIT, BBIT, and UAT to ensure everything is foolproof.
You can’t upgrade directly on the spot; you must set up a test environment and run all the business SQL queries. Otherwise, changes in the execution plan might cause some issues.
Yes, smoke testing, regression testing, performance stress testing, a bunch of processes.
Upgrading from version 2 to 6 spans multiple versions, and you need to upgrade one version at a time, i.e., 2.0-3.0-4.0-5.0-6.0. However, multiple upgrades can indeed be quite troublesome.
To save effort, you might consider directly setting up a version 6 cluster and then migrating the business data from version 2 to the version 6 cluster. This would indeed save a lot of effort, but whether it is the most stable approach is uncertain.
The best way is to set up a new cluster, run a bunch of tests, and then switch over after passing the tests.
This topic will be automatically closed 60 days after the last reply. No new replies are allowed.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: