坐等恢复结果，好场景
标注一下，看看如何解决
刮擦，赶紧备份下中控机。没想过这个问题。
tiup作为单点的管理组件，应该要备份一下，不过这个点很多人很容易忽略。
在另外一台机器重新下载tiup，逆向重新编辑集群拓扑和写入配置参数，应该可以恢复，大佬可以在测试环境试试。
直接执行tiup cluster deploy tidb-xxx ./topology.yaml不报错吗？该命令不是会在部署路径(比如tidb-deploy目录)生成部署文件夹吗？那之前部署的集群原来各实例节点上的文件名不需要重新命名吗，会不会报端口冲突之类的？
大佬你好，请问需要备份的文件在哪个目录呢？比如我安装时目录如下：
那么需要将中控机哪个目录下的数据备份？此外，集群运行过程中，备份目录下的文件或数据会不会发生变化，如果有变化那么用之前的备份恢复时会有额外问题吗
备份使用命令 tiup cluster meta backup，然后将备份出的压缩包找个地方放起来，最好不要放tiup当前的中控机上，放到其他机器上，如果原中控机异常，只需要随便找个机器安装tiup，之后，运行 tiup cluster meta restore命令即可将原集群管控起来。
https://docs.pingcap.com/zh/tidb/v7.1/tiup-component-cluster-meta-backup#tiup-cluster-meta-backup
https://docs.pingcap.com/zh/tidb/v7.1/tiup-component-cluster-meta-restore#tiup-cluster-meta-restore
1 个赞
不会报错，生成的只是可执行命令的脚本，你并没有启动集群，你执行tiup cluster start tidb-test --init才会重新安装集群，deploy只是重新往你yaml文件里的机器重新放了一遍你的可执行文件，同时在本地生成meta文件，端口不会冲突，因为你启动才会去检测端口。如果你不确定你的yaml文件和原来完全一致，确实需要去原来每个节点的机器保存一份每个节点的depoly目录。确定没问题可以省略这一步。
可以按照原来的配置环境重新安装一下，然后把相关配置复制过来试试
所以tiup 的元数据也是要纳管的
不能恢复嘛
只需要备份meta.yaml就可以，不知道路径可以find找下.tiup
对的，应该要纳管的，建议生产环境都定期备份一下~/.tiup目录
如果要备份tiup元数据，避免中控机宕机，实现可以有两个方式：
- 备份使用命令 tiup cluster meta backup
- 写脚本，直接定期备份一下~/.tiup目录就行，里面包含了纳管集群的拓扑信息和配置文件。
1 个赞
学习了 
方案2中的tiup目录下文件或者数据会随着集群运行发生变化吗，如果当前时间备份，那么集群运行一个月或者半年后集群中该目录中内容和之前的是否一致呢？
大佬你好，这个目录找不到，我部署时拓扑文件配置的部署目录是/data/tidb-deploy，部署后如何找到你说的这个目录呢
大佬你好，有个疑问想确认下，该备份命令备份集群meta数据，那么集群运行中元数据是否会一直变化？比如我现在备份，那么tiup所在中控机挂了，但是集群却在一直运行，一个月后才发现，那我使用之前的备份文件进行恢复tiup，然后会不会和现有的集群匹配不上，因为损失了一个月的元数据，这部分可能没有备份
如果期间你没有用tiup执行过 扩容、缩容、调整配置文件等内容，那就没有变化。如果有用tiup调整过，内容就会有变化。建议是定期备份。tiup 这里记录是运维管理相关的元数据，DBA有过操作，这里的元数据才会有变化。和集群数据的元数据不是一个概念，集群的元数据是存在在pd集群，和这里讨论的内容没有一点关系。
~/.tiup 目录是在你集群的中控机机器、安装集群的用户上，到那台机器上去查就行。
没法子