TIDB 如何实时做实时回传到MySQL数据库方案

【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.10
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
请教大家两个问题:
一、在非高并发场景的业务,目前用4台虚拟机部署简单的tidb 集群,节点1 部署监控+中控,节点2-节点4 分别部署 tidb 、pd、tikv 这三个组件,请问这种部署方式在非高并发场景长期使用是否会有其他额外风险或者注意事项。毕竟按官网资源,是比较浪费的,没有那么多ssd 和高性能场景

二、最近想做一个tidb实施回传到备集群 MySQL,请问可以直接使用dm 方式还是其他呢?如果用dm 对主集群是否有额外负担和影响

以上两个问题,请各位高手有做的老哥,帮忙解答下。材料我看过,就像知道有实施过经验的老哥帮忙解答,谢谢~

有人帮忙看下吗?谢了

DM 不行,是用来 MySQL → TiDB 的
考虑下 TiCDC ? 或者看看论坛里头,这类的帖子挺多的

1 混合部署必须设置限制tidb和tikv内存限制,否则一定会oom
2 dm做不了,需要用ticdc做,需要你再加个机器部署ticdc组件

我们用过ticdc 回mysql,7.1的版本,回传mysql5.7,不是很稳定。
你回mysql的目的是什么。

TiDB 五大核心特性

  • 一键水平扩缩容得益于 TiDB 存储计算分离的架构的设计,可按需对计算、存储分别进行在线扩容或者缩容,扩容或者缩容过程中对应用运维人员透明。
  • 金融级高可用数据采用多副本存储,数据副本通过 Multi-Raft 协议同步事务日志,多数派写入成功事务才能提交,确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略,满足不同容灾级别的要求。
  • 实时 HTAP提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎,TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据,确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器,解决 HTAP 资源隔离的问题。
  • 云原生的分布式数据库专为云而设计的分布式数据库,通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。
  • 兼容 MySQL 协议和 MySQL 生态兼容 MySQL 协议、MySQL 常用的功能、MySQL 生态,应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

选 TiDB 的理由是什么呢,适合的场景才能发挥 TiDB 的优势。

我就是用的ticdc做的,回传到mysql5.7版本非常稳定。可以用dumpling做存量,ticdc做增量。同步ddl语言,目前只验证到不支持alter table name这一种名字。

做个异构备集群,用于应对突发事件

是的,谢谢

理由:选它的理由就这五条够用了

资源够的话,下游可以在放一个tidb。mysql做下游,后面会遇到棘手问题。

什么问题,老哥

遇到过
1、无主键的表ticdc推到 mysql 报错
2、执行ddl的时候由于表数据量大,下游mysql跟不上。造成同步失败