确实很优秀，点赞 [image]

换个格式吧，比如 TiCDC Canal-JSON Protocol TiCDC Debezium Protocol TiCDC Open Protocol TiCDC Avro Protocol JSON格式，推荐使用 TiCDC Canal-JSON Protocol TiCDC Debezium Protocol

这个和规划/设计有更大的关系了，可以参考：

RustFS 没有完全兼容吧，可以试试 ceph

没啥问题，采用海量写，读的时候用版本就行了，batch on 的方式删除

生产环境用官方推荐的版本吧，不然会踩坑的 [image]

rocky linx，版本忘记了

但凡有办法，别把服务都部署在一个节点，资源争抢，优化很闹心的

我用的 8.5.4，最新的

多少天了？

欢迎～ 多为自己的想法在社区学习、交流，很容易实现了

肯定是键盘和鼠标拉～ 很香的

看下官方的文档了，很详细了

您当前使用的云资源部署在哪个地域（城市），会考虑单一城市部署还是多城市容灾？在哪朵云上？ 全球…太多了… 目前运行着多少套 TiDB 集群，合计节点数 / 核心数（core）为多少？您当前 TiDB 相关资源的年度总费用是多少？ 云提供的具体折扣力度（如折扣率 / 优惠方式）是什么？ 2 套集群，社区版，标准的硬件打折方案 若迁移至 TiDB 全托管服务，您期望获得的服务等级协议（SLA）标准是什么（如可用性、故障恢复时间等）？ 暂时应该不会考虑全托

参考这个图 [image] https://docs.pingcap.com/zh/tidb/stable/dev-guide-sample-application-java-jdbc/#mysql-兼容性

前进了一小步， 日拱一卒

【有哪些好的运维习惯/创新实践，帮你兜住了哪些风险？】 监控 + 告警 ， 提前就预警了一些问题，能够及时处理 【用了 TiDB 是否让你更省心？】 备份和恢复方面有点小麻烦，但是比较省心了

恭喜三位大佬

切换成：同步到 Kafka 呢？ 是否还会有这个问题？