来源：clickhouse · 原文
这段官方文档对我最有价值的地方，是它把“能不能转”这个问题从口头争论变成了有明确路径的工程事实。但它也同样明确地告诉我，这件事虽然受支持，却绝不是一次可以随手完成的轻量改动。
核心结论
这段官方文档说明，从 MergeTree 转成 ReplicatedMergeTree 是受支持的正式迁移路径，但它并不是“一条命令自动善后”的无状态切换。
官方给出的三类路径
ATTACH ... AS REPLICATED：适合已经 detach 的表；convert_to_replicated+ 重启：适合可以接受重启，并且default_replica_path/default_replica_name已配置妥当的场景；- 手工迁移：rename 旧表、新建 replicated 表、移动数据到
detached、再ATTACH PARTITION。
文档暴露出的运维前提
- 如果多份数据不一致，要先同步或只保留一个权威副本；
- 需要知道数据目录、replica path 这类底层细节；
- 这件事本质上仍然是一次受控迁移，而不是普通 DDL。
对我的启发
这让我更愿意把“从非复制表转成复制表”视为一类迁移工程，而不是一类 schema 改动。因为它牵涉的不只是引擎名字变化，而是底层元数据路径、数据一致性和恢复语义。我觉得这正是这类文档最该被记住的地方：官方说“支持”，不等于官方在说“轻松”。
相关页面：clickhouse-replicated-engines-and-conversion · clickhouse · clickhouse-attach-as-replicated · altinity-converting-mergetree-to-replicated