今天给4.0.0版本升级到4.0.9 检查一下发现好多错误。
THP和numctl还可以理解，端口号正在使用是什么意思，tidb自己不是正在使用吗。难道要这些端口全部未使用状态：
tiup cluster check test-cluster --cluster
这个check是全新安装集群的check,你升级不需要check直接升级就行。
1 个赞
这个是升级后的？
不是，升级前操作的命令
全新安装的check是这个吧：
tiup cluster check ./topology.yaml --apply --user tidb -p
升级用的官方文档写的是这两个： 如果直接升级会报错吧
tiup cluster check test-cluster --cluster
tiup cluster upgrade tidb-test v4.0.9 --transfer-timeout=3600
tiup cluster check --cluster
这个不会检查端口号吧，你当前的clster-name是test-cluster吗？
你的是没有端口。我自己虚拟机的测试4.0.2–4.0.9 和4.0.2–5.0.0升级检查都没有检查端口。。但是这个公司测试环境4.0.0检查就有这个提示。。
我也不知道为啥，这个4.0.0是之前3.0版本升级上来的。
我去看了一下3.0升级4.0没有check命令。吧ansible init文件导入。然后直接tiup 升级的。
这是我之前的升级检查：
如果不管他直接升级。如果不报错那就直接使用，如果报错了。能回退吗？官方文档没找到回退方法
不能回退，不过端口冲突感觉没啥问题吧，你组件会滚动重启，重启的时候端口自然就不会占用了。
那如果升级失败呢。影响使用吗？就怕升级到一半有些文件替换了然后失败。有些文件没替换。真就尴尬了。中途夭折~万一再不能用~
升级前，先备份数据
1 个赞
可以把数据先备份出来，升级失败再灌回来
1 个赞
我是这么想的，但是如果升级失败了。那是不是这个集群就有问题了。要重新搭建呢。不能影响开发他们使用和测试。得专门扣一个时间。还要和领导说一下申请一下，我现在准备找一个空间服务器。直接安装一个单节点的tidb。然后吧这个4.0.0备份恢复过去。做一个cdc实时同步，如果没问题在升级。找了一下午了没有资源
你现在是4.0.0升级到4.0.9我感觉问题不大，如果跨版本可能不同版本的组件真会有问题，你这可以考虑备份所有的组件，万一失败直接还原组件应该也能行
组件可以全部备份？你意思是 直接cp还是说 tidb的备份工具？
实在不行本机装个mysql同步一样的
tidb本地是有空间。装一个myslq没啥问题。。你是啥意思，tidb同步到这个mysql？？然后升级失败的话。怎么回滚？
直接把本地的组件都cp备份一下，升级失败直接cp回来，数据库应该也能正常用