遷移方案概述
遷移方案是通過源集群的zookeeper 做副本數據同步，架構如下：
前提條件：
要求源、目標集群在同一個網絡，源、目標集群的分片數是相同的，另外建議源、目標集群的ck內核版本也一致，避免不同版本使用到的zstd 版本不一致導致merge出錯
遷移條件 & 情況：
目標集群必須跟源集群具備相同的分片數，目標集群跟源集群網絡相通；
只支持依賴zk的副本表；
partitiong同步過程，源集群可正常讀寫，遷移過程源集群能正常讀，但是不能寫；
數據同步和遷移過程，不會刪除源集群的數據；
數據同步過程源集群下的數據（本地數據 + cos數據）都會同步到目標集群下，因此目標集群下的容量要足夠。
遷移步驟：
整體的遷移環節可概括為：創建臨時表（開始同步數據）和正式表 - 》 修改臨時表引擎為 MergeTree — 》從臨時表把數據轉移到正式表 - 》刪除臨時表
具體步驟如下：
1、在目標集群的各個分片選擇一個節點，加入到tmp_cluster里頭去（metrika.xml文件中新增tmp_cluster），修改目標集群的config.xml文件，把源集群的zk信息配置進來，如果有多個，那分別加入
<auxiliary_zookeepers> <zookeeper2> <node> <host>ip1</host> <port>2181</port> </node> <node> <host>ip2</host> <port>2181</port> </node> <node> <host>ip3</host> <port>2181</port> </node> </zookeeper2> <session_timeout_ms>60000</session_timeout_ms> <operation_timeout_ms>30000</operation_timeout_ms> </auxiliary_zookeepers> |
2、在目標集群上創建臨時的副本表，綁定源集群的zk，以ReplicatedMergeTree為例子：
CREATE TABLE table_name_tmp on cluster tmp_cluster ( ... ) ENGINE = ReplicatedMergeTree('zookeeper2:path', '{replica}') ... |
備注說明：
創建的臨時副本表使用臨時表名，在正式表后面加_tmp。
創建的臨時副本表使用的ZooKeeper路徑和源端搬遷表的ZooKeeper路徑需保持一致。
創建的臨時副本表的表結構需和源端搬遷表保持一致。
3、創建完臨時副本表之后，集群會自動通過源zk做part同步到目標集群的副本。期間不用做任何處理，可以準備下一步驟工作 （這個過程不要對臨時表做任何數據分區操作，因為操作臨時表分區就等于操作源集群對應正式表）
4、在目標集群創建正式名字的 副本表，采用默認zookeeper（可直接通過on cluster default_cluster去創建）
5、同步完成之后，檢查源集群和目標集群，各個表數據分布情況，數據準確性校驗（查詢part數，以及count總數是否匹配，校驗數據準確性時最好做到源集群停寫）
6、檢查無誤之后，在目標集群metadata 目錄下，修改所有臨時表的sql，把Engine均改成MergeTree （這步是為了遷移過程影響到源集群，保證源集群的數據可讀），修改完后重啟集群 —— 有現成腳本
7、執行DETACH 命令對臨時表中的每個partition DETACH，然后登入目標集群，把臨時表下detached目錄的所有part mv 到對應的目標表的detached 目錄下 —— 如果分區多，可用腳本完成，有現成腳本
例如：default 下lineorder表，可以執行 mv /data/clickhouse/clickhouse-server/data/default/lineorder_tmp/ detached/* /data/clickhouse/clickhouse-server/data/default/lineorder/detached/
例如：default 下lineorder_tmp臨時表，分區有'1992','1993','1994','1995','1996' 第一步：在studio上執行（也可以通過腳本去完成）: ALTER TABLE default.lineorder_tmp on cluster tmp_cluster DETACH PARTITION '1992'; ALTER TABLE default.lineorder_tmp on cluster tmp_cluster DETACH PARTITION '1993'; ALTER TABLE default.lineorder_tmp on cluster tmp_cluster DETACH PARTITION '1994'; ALTER TABLE default.lineorder_tmp on cluster tmp_cluster DETACH PARTITION '1995'; ALTER TABLE default.lineorder_tmp on cluster tmp_cluster DETACH PARTITION '1996'; 第二步：登入到目標集群在各個節點上，執行: mv /data/clickhouse/clickhouse-server/data/default/lineorder_tmp/detached/* /data/clickhouse/clickhouse-server/data/default/lineorder/detached/ |
8、執行attach 命令，把目標表下detached的part加載到表內 —— 如果分區多，可用腳本完成，有現成腳本（可找作者提供）
例如：default 下lineorder表，可以執行 alter table default.lineorder attach partition 'partition_name'; 依次把所有的partition 加載到正式表
9、所有的表遷移完成之后，刪除臨時表，再刪除config.xml文件中的 auxiliary_zookeepers配置；
說明：
數據副本同步過程因為某種原因導致副本服務中斷（可能是網絡、bug、人為手工停止），再次重啟后支持斷點續傳，不會影響源數據同步傳輸。 操作過程會涉及到多個partition的 DETACH和 attach命令，同時還需要登入到目標節點執行mv 操作，為了簡化工作提高效率，減少過多人為操作而導致的失誤，建議 通過批量工具（天翼云ClickHouse提供） + 腳本方式執行（找作者提供） 批量工具：批量分發文件到目標集群各個節點，批量在目標集群各個節點執行命令腳本等 參考腳本：查詢一個表下的所有partition 列表，然后執行 DETACH命令， mv 命令 和最后的 attach命令 |
注意：
在添加臨時表之后，源集群表的part就會自動通過zk做part復制，因為數據量很大，建議分批創建臨時副本表，以免對源zk造成負載過高，從而影響業務 在臨時表數據同步的過程中，一定不要對臨時表做任何數據或是分區操作，操作臨時表就等于操作源集群對應的正式表 在臨時表數據同步過程，不能有ddl變化 |
方案優點：可支持對巨量副本表（幾百個以上）的數據遷移，數據同步過程通過zk 做到后臺自動同步，無需干預；同時支持對cos 數據的遷移；
不足：只能遷移ReplicatedMergeTree 引擎表，其它表不支持這種方案。
