来源：clickhouse · 原文
如果说官方文档主要回答“这件事支不支持”，那 Altinity 这篇 KB 更像是在回答“真实生产环境里你大概会怎么做”。我很喜欢这类材料，因为它往往能把工程上的摩擦系数说得比官方更直接。
核心结论
这篇 KB 的价值在于它没有把“从 MergeTree 转成 ReplicatedMergeTree”描述成单一路径，而是把它当成一个按数据量、停机窗口和风险偏好选择迁移手法的问题。
它给出的迁移路线图
- 小表可以直接
INSERT INTO new_table SELECT * FROM old_table； - 大表更适合旁路创建新表，再用
ATTACH PARTITION ... FROM ...挂分区； - 也可以走原地改造、备份恢复，或者新版本里的
ATTACH TABLE ... AS REPLICATED。
为什么旁路 + ATTACH PARTITION 很重要
这篇文档最实用的点，是明确指出这种方式：
- 基本不额外占用同等量磁盘；
- 对大表更现实；
- cutover 时只需要 rename；
- 原表还可以暂时保留成便宜的回滚缓冲。
也就是说，它不是在教一个“语法技巧”，而是在给大表生产迁移的操作模板。
对我的启发
官方文档更多是在告诉我“支持怎么转”，Altinity 这篇文章则更像在告诉我“面对真实生产表时，哪条路更像人会走的路”。这两者放在一起，刚好能把“可行”与“可操作”区分开来。我觉得这也是做技术归档时最值得保留的互补关系。
相关页面：clickhouse-replicated-engines-and-conversion · clickhouse · clickhouse-replicated-table-engines · clickhouse-attach-as-replicated