TIDB4.0.2和4.0.9版本迁移问题

舞动梦灵 · 2023 年9 月 4 日 02:34

目前有两套环境4.0.2和4.0.9 ，准备从阿里云迁移到其他云环境，
看官方文档用BR备份恢复的时候，使用5.0BR恢复是完全兼容，用原版本4.0恢复还有一个小bug。
想问3个问题：
1.tidb4.0版本用BR4.0备份，使用5.0BR恢复到5.0.0版本集群，迁移过程会不会有其他问题
2.tidb 4.0.2 和4.0.9版本能否使用扩容缩容方式进行迁移，使用这种方式有没有问题
3.tidb的DM工具能否迁移tidb到另外一个集群

大飞哥online · 2023 年9 月 4 日 02:36

跨云迁移，之间网络速度要注意看看了，不建议跨云传输的方式。
要是可以停机的话，可以，直接集群数据全备，然后新环境恢复就好

舞动梦灵 · 2023 年9 月 4 日 02:42

业务不能停，停机10分钟都要申请。我是见有朋友说他们公司5.0版本使用扩容缩容方式迁移了。4.0版本太老了不知道行不行，问问看看有没有使用4.0版本库容缩容迁移成功的，会不会产生一些其他问题

大飞哥online · 2023 年9 月 4 日 02:45

1.tidb4.0版本用BR4.0备份，使用5.0BR恢复到5.0.0版本集群，迁移过程会不会有其他问题
答：同版本不会有啥问题，BR 直接全备，在恢复，没问题，但要停机。
2.tidb 4.0.2 和4.0.9版本能否使用扩容缩容方式进行迁移，使用这种方式有没有问题
答：这个就慢喽，而且对当前业务也会影响性能的。低版本木有搞过，需要测试验证。
3.tidb的DM工具能否迁移tidb到另外一个集群
答：可以啊

大飞哥online · 2023 年9 月 4 日 02:46

你可以全备到新集群，然后在搞个cdc这类同步的，把新数据实时同步，需要切换的时候，之间应用改IP指向就好了

像风一样的男子 · 2023 年9 月 4 日 02:51

如果业务不能停，想通过扩缩容方式迁移，那你就要打通2个云环境的网络确保网络延迟很低带宽够大，不然你就只能申请停机通过br迁移数据，二选一，做好方案让领导审批呗

大飞哥online · 2023 年9 月 4 日 02:53

对，方案写好，风险点写到位，剩下就是领导决策了

舞动梦灵 · 2023 年9 月 4 日 03:24

你说的这个我也知道就是BR全备恢复然后CDC实时同步，最后切换IP。你说的“答：同版本不会有啥问题，BR 直接全备，在恢复，没问题，但要停机。” 停机是恢复目标那里要停机吧？ BR备份源端不停吧？
第三个DM，我直接在某个云上部署DM服务器，然后同步源端到目标端，可以全量同步然后自动实时同步吗？
感觉这个比较省力，但是我看DM的官方文档写数据源配置文件中 relay-binlog-name: “” # 拉取上游 binlog 的起始文件名,如果不指定使用当前最新的binlog开始同步。但是创建任务的时候有个task文件task-mode: “all” 说明是全量+增量，有点不理解了，如果没有配置指定数据源的binlog，创建任务使用all模式，那他到底是先全量迁移在同步还是，还是同步当前最新的一个binlog时间的数据
谢谢你

舞动梦灵 · 2023 年9 月 4 日 03:27

BR必须要停机吗？？我还没细看BR 具体操作，想着看哪个方案比较省心然后去看下文档做一遍测试。
我看到迁移方案里面的BR备份说是BR备份到对象存储，备份的时候有个时间点，然后使用CDC从这个时间点开始实时同步，没看到需要停机的步骤

像风一样的男子 · 2023 年9 月 4 日 03:39

br是热备可以不停机，但是为了防止源头还有数据写入直接停机最好，数据迁移完就可以直接切换使用，你这都搬机房了，肯定不止数据迁移啊可以配合其他应用一起迁移

舞动梦灵 · 2023 年9 月 4 日 03:49

对，br的话只能是br热备+cdc实时同步，然后找时机迁应用

舞动梦灵 · 2023 年9 月 4 日 03:53

大飞哥问一下，DM同步工具可以迁移tidb集群，那ti CDC能直接使用他来做tidb到tidb集群的迁移工具吗？我看描述只是说拉取tikv变更信息日志来同步

大飞哥online · 2023 年9 月 4 日 03:54

br是热备份，本身不用停机的。停机是为了防止新数据的产生，旧机房停机br全备，再去新机房恢复，应用直接指新机房ip或域名就好，备份恢复产生的时间，新数据不能入库。这个要评估呢。

DM 可以全量，也可以增量的，配置不同而已

大飞哥online · 2023 年9 月 4 日 03:55

cdc 只能增量的，需要配合全量的数据

舞动梦灵 · 2023 年9 月 4 日 04:58

大飞哥，问下，环境相同配置一样，1T数据使用库容缩容方式和DM，哪个速度相对来说会快一点，我看官方文档写得是DM时每小时30-50G的速度。这两个方式哪个速度可能会更快点，扩容缩容的reblance平衡速度大概多少，这个官方文档有描述吗

像风一样的男子 · 2023 年9 月 4 日 05:10

dm支持上游是mysql的数据库吧不支持tidb

大飞哥online · 2023 年9 月 4 日 05:23

DM 支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量数据迁移和增量数据同步。mysql 8.0 还在实验。

最好还是用BR 全备+ticdc增量，扩缩容，你要考虑到两个云环境之间的网络。
扩缩容的耗时是多个方面的，集群的资源，网络，数据量等等。不好估

Kongdom · 2023 年9 月 4 日 05:34

不停机的话，貌似就扩容缩容了。

舞动梦灵 · 2023 年9 月 4 日 05:46

DM 官方描述支持的上游数据库是这么说的，但是没写源端支不支持tidb，我也是担心的是他只是支持mysql、mariadb数据库，因为他有binlog从0001到最新，但是itdb貌似没有binlog的增长。

大飞哥online · 2023 年9 月 4 日 05:59

是呢
扩缩容，时间段拉的长，而且在业务使用中会涉及，不同的云环境，leader 这类你要多注意。
br+cdc 也不用停机，时间段拉的短，就是硬件资源需要全部到位。