更新时间：2025-10-10 16:08:52

Proton 组件数据目录迁移指导手册

重要提示

注意：本操作需要停机执行。停机时间主要取决于以下因素：

待迁移组件的数据量大小

磁盘性能

如涉及节点变更，还会受到网络性能影响

1. 适用范围

本文档适用于以下两种场景的数据目录迁移：

1.1 标准组件数据目录迁移

适用于 Proton 集群中使用 data_path 配置的组件进行数据目录切换，支持：

单节点/多节点部署
组件归属节点变更
不包含组件副本数量变更，如果需要扩缩容，请参考对应手册进行
单个组件的不同节点必须使用相同的数据目录路径

已验证组件列表：

grafana
kafka
zookeeper
opensearch
prometheus
proton_etcd
proton_mariadb
proton_mongodb
proton_monitor
proton_mq_nsq
proton_policy_engine
proton_redis

1.2 核心服务组件数据目录迁移

适用于 Proton 集群中以下核心服务的数据目录切换：

proton-cs 组件（包含 Kubernetes etcd 和容器运行时）
proton-cr 组件（包含 Docker Registry 和 Chart Museum）

限制说明：

支持单节点/多节点部署
不支持组件归属节点变更
不支持组件副本数量变更
单个组件的不同节点必须使用相同的数据目录路径

2. 迁移方案概述

根据组件类型的不同，采用以下两种迁移流程：

2.1 主机服务及支持配置直接变更的容器服务

停止服务 -> 变更配置 -> 数据目录迁移 -> 启动服务

2.2 不支持直接变更配置的容器服务

停止服务 -> 变更配置 -> 删除组件 -> 数据目录迁移 -> 重新安装组件

3. 技术原理

3.1 基础架构说明

Proton 基础组件采用 StatefulSet 类型部署
使用 PVC 挂载主机上的数据目录
每个组件在单个节点上可启动 0 或 1 个副本
每个组件最多支持 3 个副本

3.2 数据目录切换机制

在服务停止时将数据目录迁移至新位置
服务启动时自动读取新的数据目录
通过更新 data_path 配置完成切换

3.3 StatefulSet 特性说明

有序性：
- 组件按固定顺序启动和停止
- 组件集群的组成依赖于启动顺序
- 数据目录变更时必须确保节点映射关系明确
配置限制：
- StatefulSet 不支持直接修改某些字段
- 数据目录变更需通过删除后重新安装实现

3.4 数据迁移工具

主要工具：rsync
- 保留文件权限和属主信息
- 支持全量及增量传输
- 支持跨节点拷贝
- 支持传输速度限制
- 支持数据校验
备用方案：tar + scp
- 当 rsync 不可用时使用
- 流程：打包 -> 传输 -> 解包

3.5 组件管理方式

Operator 管理组件：
- nebula
- proton_mongodb
- proton_mariadb
这些组件以 CR (Custom Resource) 形式存在，停止服务时需删除对应的 CR。
Helm 管理组件：
- 默认位于 resource 命名空间
- 通过删除 Helm release 停止服务
应用服务：
- 部署在特定命名空间中
- 默认命名空间为空间为 anyshare。

基于此，在停止组件服务之前，需先停止 anyshare namespace 下的 deployment、daemonset 和 statefulset，以避免数据一致性问题。

proton 组件的配置信息记录在 proton-cli-config 和 persist-component-manage-components 这两个 secret 中。同时，使用 proton-cli apply -f <proton-cli-config-file> 时，不支持部分配置项变更，如 data_path 对应的字段。

基于此，变更数据目录时，需手动更新这两个 secret，而无法通过 proton-cli get conf > 1.yaml && vi 1.yaml && proton-cli apply -f 1.yaml 的方式进行变更。
proton-cli get conf 命令用于获取组件配置信息，实际由 proton-cli-config 中的 ClusterConfiguration 字段提供。
proton-cli apply -f <proton-cli-config-file> 命令用于根据传入的配置文件安装或更新组件。
对于包含了组件管理服务的较新版本集群，proton-cli apply -f <proton-cli-config-file> 时，组件管理功能会自动根据配置文件中的组件配置信息进行安装。

基于此，数据目录变更时，将继续使用 proton-cli apply -f <proton-cli-config-file> 方式对组件进行复原安装。
对于 proton-cs，支持容器运行时可以为 docker/containerd，对应的数据目录在 proton-cli-config secret 中存放的 key 存在差异，使用 docker 时，在 proton-cli-config secret 中的位置为 .cs.docker_data_dir，在主机配置文件/etc/docker/daemon.json中的位置为 ."data-root"，使用 containerd 时，在 proton-cli-config secret 中的位置为 .cs.container_runtime.containerd.root，在主机配置文件/etc/containerd/config.toml中的位置为 .root。
proton-cs etcd 的 pod 定义在 /etc/kubernetes/manifests/etcd.yaml 中，其内包含了 etcd 的数据目录配置项，在 proton-cli-config secret 中的位置为 .cs.etcd_data_dir。
proton-cr 的数据目录在 proton-cli-config secret 中的位置为 .cr.data_dir，在主机配置文件/etc/proton-cr/proton-cr.yaml中的位置为 .storage。
proton-cs docker registry 的数据目录在主机配置文件/etc/docker/registry/config.yml中的位置为 .storage.filesystem.rootdirectory。
proton-cs chart museum 的数据目录在主机配置文件/etc/proton-cr/proton-cr.yaml中的位置为 .["storage.local_rootdir"]。

基于此，proton-cr 的数据目录进行切换时，要维持 proton-cr 目录对于 docker registry 和 chart museum 的目录层级关系。

1. 上传包

停机时间外操作，不计入总停机时间。

将当前集群使用的对应版本的依赖包上传至任意一个 Master 节点，并解压备用。
上传所有使用到的命令和脚本(包括如下app_manager.sh和其他使用到的命令)。

#!/bin/bash
# filename: app_manager.sh
# description: app_manager.sh is used to stop and start all applications in the cluster.
# author: proton
# date: 2025-09-25
set -e

# record file
record_file="/opt/app.replicas"
# timeout seconds
timeout_seconds=600
# check interval
check_interval=5

# 根据 deploy-service 获取应用服务所在的namespace
#ns=$(kubectl get deploy -A -o json | yq e '.items[] | select(.metadata.name == "deploy-service") | .metadata.namespace' -)
ns=$(kubectl get deploy -A -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\n"}{end}'|awk -F "\t" '$1=="deploy-service"{print $2; exit}');
[ -z "${ns}" ] && ns='anyshare'

# 检查应用服务是否处于期望的状态
check_workloads_ready() {
    local component_ns="$1";
    local desired="$2";
    if [ "${desired}" == "stop" ]; then
        running_pod_count=$(kubectl get pods -n ${component_ns} -ojsonpath='{range .items[*]}{.status.phase}{"\n"}{end}'|awk 'BEGIN{count=0}{if ($1!="Succeeded") count++}END{print count}');
        if [[ "${running_pod_count}" -eq 0 ]]; then
            echo "all pods in namespace ${component_ns} are stopped!"
            return 0
        fi
        return 1
    fi
    if [ "${desired}" == "start" ]; then
        # get unready deploy&sts&ds
        unready_deploys=$(kubectl get deployments -n "${component_ns}" -o custom-columns=REPLICAS:.spec.replicas,READY_REPLICAS:.status.readyReplicas \
            | awk 'BEGIN{count=0}NR>1 {if ($1 != $2) count++} END{print count}');
            
        unready_sts=$(kubectl get statefulsets -n "${component_ns}" -o custom-columns=REPLICAS:.spec.replicas,READY_REPLICAS:.status.readyReplicas \
            | awk 'BEGIN{count=0}NR>1 {if ($1 != $2) count++} END{print count}');

        unready_ds=$(kubectl get daemonsets -n "${component_ns}" -o custom-columns=DESIRED:.status.desiredNumberScheduled,READY:.status.numberReady \
            | awk 'BEGIN{count=0}NR>1 {if ($1 != $2) count++} END{print count}');

        # check if all workloads are ready
        if [[ "${unready_deploys}" -eq 0 && "${unready_sts}" -eq 0 && "${unready_ds}" -eq 0 ]]; then
            echo "all deploy&ds&sts in namespace ${component_ns} are ready!"
            return 0
        fi
        return 1
    fi
    return 233
}

# 等待应用服务达到期望状态
wait_for_workloads() {
    local component_ns="$1";
    local desired="$2";
    local elapsed=0

    echo -n "Waiting for all deploy/sts/ds in namespace ${component_ns} to be ${desired}..."
    while [ $elapsed -lt $timeout_seconds ]; do
        if check_workloads_ready "$component_ns" "$desired"; then
            echo " done"
            return 0
        fi
        sleep $check_interval
        elapsed=$((elapsed + check_interval))
        echo -n "."
    done
    echo " timeout reached!"
    return 1
}

# 停止应用服务
stop_apps() {
    # 仅当记录文件不存在时，才记录当前应用服务的副本信息
    if [ ! -f "${record_file}" ]; then
        touch "${record_file}"
        kubectl get deploy -n${ns} -o jsonpath='{range .items[*]}{"deployment"}{"\t"}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}' > "${record_file}"
        kubectl get sts -n${ns} -o jsonpath='{range .items[*]}{"statefulset"}{"\t"}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}' >> "${record_file}"
    fi

    # 通过打一个不存在的label实现停止指定namespace下所有的daemonset
    for ds in $(kubectl get ds -n${ns} -ojsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
        echo "Stopping daemonset ${ds}..."
        kubectl -n${ns} patch ds ${ds} -p '{"spec":{"template":{"spec":{"nodeSelector":{"stop-by-admin":"true"}}}}}'
    done

    # 通过scale=0停止所有deploy和sts
    while read -r app_type app_name app_replicas _; do
        if [ "$app_replicas" -gt 0 ]; then
            echo "Stopping ${app_type} ${app_name}..."
            kubectl -n${ns} scale ${app_type} ${app_name} --replicas=0
        fi
    done < "${record_file}"

    # 等待所有应用服务的pod停止
    wait_for_workloads "${ns}" "stop" || true
}

# 启动应用服务
start_apps() {
    # 删除label来启动daemonset
    for ds in $(kubectl get ds -n${ns} -ojsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
        echo "Starting daemonset ${ds}..."
        kubectl -n${ns} patch ds ${ds} --type=merge -p '{"spec":{"template":{"spec":{"nodeSelector":{"stop-by-admin":null}}}}}'
    done

    # 按照记录文件内容启动所有deploy和sts
    while read -r app_type app_name app_replicas _; do
        if [ "$app_replicas" -gt 0 ]; then
            echo "Starting ${app_type} ${app_name} with ${app_replicas} replicas..."
            kubectl -n${ns} scale ${app_type} ${app_name} --replicas=${app_replicas}
        fi
    done < "${record_file}"

    # 等待所有应用服务的pod启动
    if wait_for_workloads "${ns}" "start"; then
        echo "All applications started successfully"
        rm -f "${record_file}"
    else
        echo "Warning: Some applications failed to start properly in time, manual check is needed"
        exit 1
    fi
}

[ -z "$1" ] && { echo "Usage: $0 {stop|start}" >&2; exit 233; }

case $1 in
    stop)
        stop_apps
        ;;
    start)
        start_apps
        ;;
    *)
        echo "Usage: $0 {stop|start}" >&2
        exit 233
        ;;
esac

2. 镜像预热

停机时间外操作，不计入总停机时间。

在每个节点上，提前拉取所需运行组件的镜像，以确保在后续启动时不再需要拉取镜像，从而加速组件服务的启动过程。

3. 获取 Secret

停机时间外操作，不计入总停机时间。

此步骤用于备份 persist-component-manage-components 和 proton-cli-config 两个 Secret，并将其内容导出至同名目录的子项文件中（已解码）。

执行以下命令导出当前的 Secret：

# 创建更新 Secret 的子目录
rm -rf persist-component-manage-components proton-cli-config
mkdir -p persist-component-manage-components proton-cli-config

# 获取命名空间
ns_1=$(kubectl get secret -A -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\n"}{end}'|awk -F "\t" '$1=="persist-component-manage-components"{print $2; exit}')
ns_2=$(kubectl get secret -A -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\n"}{end}'|awk -F "\t" '$1=="proton-cli-config"{print $2; exit}')

# 备份原有 Secret
kubectl -n${ns_1} get secret persist-component-manage-components -o yaml > persist-component-manage-components.yaml
kubectl -n${ns_2} get secret proton-cli-config -o yaml > proton-cli-config.yaml

# 获取当前配置并解码为明文
for item in $(yq '.data | keys | .[]' persist-component-manage-components.yaml); do
    yq ".data[\"$item\"]" persist-component-manage-components.yaml | base64 -d > "persist-component-manage-components/${item}"
done

for item in $(yq '.data | keys | .[]' proton-cli-config.yaml); do
    yq ".data[\"$item\"]" proton-cli-config.yaml | base64 -d > "proton-cli-config/${item}"
done

4. 修改配置文件内的数据目录

停机时间外操作，不计入总停机时间。

在上一步骤中，系统会创建两个目录：persist-component-manage-components 和 proton-cli-config。使用 vi 或其他编辑工具修改这两个目录下的文件，更新组件的 data_path 为新的目录。需要特别注意的是：

应先备份源文件再进行操作。
对于每个组件副本变更前后的节点和数据目录信息，都应进行详细记录，确保组件副本编号和节点一致。

对于 proton-cs 组件，需要修改 proton-cli-config secret 中的 .cs.etcd_data_dir、.cs.docker_data_dir(容器运行时使用docker)、.cs.container_runtime.containerd.root(容器运行时使用containerd)字段，还需要同步修改主机配置文件中的对应字段；对于 proton-cr 组件，需要修改 proton-cli-config secret 中的 .cr.storage字段，还需要同步修改主机配置文件中的对应字段。主机配置文件明细如下：

etcd 主机配置文件----/etc/kubernetes/manifests/etcd.yaml----在'.spec.volumes[] | select(.name =="etcd-data") | .hostPath.path'位置

备份

/bin/cp -arvf /etc/kubernetes/manifests/etcd.yaml /opt/etcd.yaml.bak

查看

yq '.spec.volumes[] | select(.name =="etcd-data") | .hostPath.path' /etc/kubernetes/manifests/etcd.yaml;

修改

yq -i '(.spec.volumes[] | select(.name =="etcd-data") | .hostPath.path) = "<new_data_path>"' /etc/kubernetes/manifests/etcd.yaml;

docker 主机配置文件----/etc/docker/daemon.json----在."data-root"位置

备份

/bin/cp -arvf /etc/docker/daemon.json /opt/daemon.json.bak;

查看

yq ."data-root" /etc/docker/daemon.json;

修改

yq -i '(."data-root") = "<new_data_path>"' /etc/docker/daemon.json;

containerd 主机配置文件----/etc/containerd/config.toml----root
备份

/bin/cp -arvf /etc/containerd/config.toml /opt/config.toml.bak;

查看

awk -F '"' '/^root/{print $(NF-1)}}' /etc/containerd/config.toml;

修改

sed -i 's~^root.*~root = "<new_data_path>"~g' /etc/containerd/config.toml;

docker registry 主机配置文件----/etc/docker/registry/config.yml----.storage.filesystem.rootdirectory
备份

/bin/cp -arvf /etc/docker/registry/config.yml /opt/registry_config.yml.bak;

查看

yq .storage.filesystem.rootdirectory /etc/docker/registry/config.yml;

修改

yq -i '.storage.filesystem.rootdirectory = "<new_data_path>"' /etc/docker/registry/config.yml;

chart museum 主机配置文件----/etc/chartmuseum/config.yml----.["storage.local.rootdir"]
备份

/bin/cp -arvf /etc/chartmuseum/config.yaml /opt/chartmuseum_config.yaml.bak;

查看

yq '.["storage.local.rootdir"]' /etc/chartmuseum/config.yaml;

修改

yq -i '.["storage.local.rootdir"] = "<new_data_path>"' /etc/chartmuseum/config.yaml;

proton-cr 主机配置文件----/etc/proton-cr/proton-cr.yaml----.storage
备份

/bin/cp -arvf /etc/proton-cr/proton-cr.yaml /opt/proton_cr_config.yaml.bak;

查看

yq '.storage' /etc/proton-cr/proton-cr.yaml;

修改

yq -i '.storage = "<new_data_path>"' /etc/proton-cr/proton-cr.yaml;

5. 在线全量拷贝数据目录

停机时间外操作，不计入总停机时间。

容器组件数据目录拷贝
如果数据量较大，数据目录可以提前进行拷贝，使用如下 rsync 命令在待迁移组件的数据源节点进行数据目录内容拷贝。注意：

复制时需确保包含最后一级目录本体，保留文件权限和属主属组信息；
要依据步骤4里面记录的组件副本和节点、数据目录的映射关系，一一进行数据目录的复制，不要错乱；
为减少对于业务的影响，建议在业务低峰期进行数据目录的拷贝，同时应该限制拷贝速度，减少对业务造成影响；
拷贝的目标目录不应为非空状态，否则会覆盖原有数据！
注意空间是否充足，避免拷贝失败。

--bwlimit单位固定为KB/s，应按照实际情况指定合适的数值，减少或者避免对业务的影响

rsync -avz --bwlimit=5000 --progress <old_data_path> root@1.2.3.4:<new_data_path>

主机服务数据目录拷贝
数据目录应当提前进行拷贝，使用如下 rsync 命令进行数据目录内容拷贝。注意：

复制时需确保包含最后一级目录本体，保留文件权限和属主属组信息；
拷贝的目标目录不应为非空状态，否则会覆盖原有数据！
注意空间是否充足，避免拷贝失败。
不可变化主机服务前后节点，仅支持在同节点上进行数据目录的切换。

--bwlimit单位固定为KB/s，应按照实际情况指定合适的数值，减少或者避免对业务的影响

rsync -avz --bwlimit=5000 --progress <old_data_path> <new_data_path>

6. 停机

预计停机时间：<3分钟

大部分应用未配置 graceful shutdown，单个 Pod 会等待默认的 terminationGracePeriodSeconds=30s，并最终被 SIGKILL。

执行以下命令，将所有应用服务停止：

bash app_manage.sh stop

然后，使用以下命令检查所有 Pod 状态，确保没有非 Completed 状态的 Pod，规避数据一致性风险：

如果进行了应用服务namespace的自定义，应使用自定义的namespace

kubectl -n anyshare get po

7. 更新 Secret

预计停机时间：<1分钟

内容：

使用修改后的 Secret 信息替换集群中原有的 Secret。

执行以下命令更新 Secret：

# 获取命名空间
ns_1=$(kubectl get secret -A -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\n"}{end}'|awk -F "\t" '$1=="persist-component-manage-components"{print $2; exit}')
ns_2=$(kubectl get secret -A -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\n"}{end}'|awk -F "\t" '$1=="proton-cli-config"{print $2; exit}')

# 更新 Secret
kubectl -n${ns_1} create secret generic persist-component-manage-components --from-file=persist-component-manage-components/ -o yaml --dry-run=client | kubectl -n${ns_1} apply -f -
kubectl -n${ns_2} create secret generic proton-cli-config --from-file=proton-cli-config/ -o yaml --dry-run=client | kubectl -n${ns_2} apply -f -

使用以下命令检查更新是否成功：

kubectl get secret persist-component-manage-components -n<namespace> -oyaml | yq .data.[] | base64 -d | awk '/data_path/ {print $1 "=" $2}'
kubectl get secret proton-cli-config -n<namespace> -oyaml | yq .data.[] | base64 -d | awk '/data_path/ {print $1 "=" $2}'

8. 卸载组件

预计停机时间：<3分钟

内容：

卸载变更了数据目录的组件，注意，是按实际发生了data_path变更的组件名称进行卸载，而非卸载所有的组件。可以一次指定多个 Helm Release 名称进行卸载：

如果进行了资源组件的namespace的自定义，应使用自定义的namespace

helm3 -n resource delete <release_name_1> <release_name_2>

如果变更了 nebula、mariadb 或 mongodb 的 data_path，则需要通过删除相应的 CR 实现组件卸载：

如果进行了资源组件的namespace的自定义，应使用自定义的namespace

Nebula：

kubectl delete nebulaclusters.app.nebula-graph.io nebula -n resource

MariaDB：

kubectl delete rdsmariadbclusters.rds.proton.aishu.cn mariadb -n resource

MongoDB：

kubectl delete mongodboperators.mongodb.proton.aishu.cn mongodb -n resource

9. 停止主机服务

预计停机时间：<3分钟

使用如下命令停止相关的主机服务

systemctl stop docker containerd kubelet proton-cr proton-cr-registry proton-cr-chartmuseum docker.socket;

特殊的，由于 mongodb 本体问题，如果此次变更未涉及 mongodb 数据目录变更，但却进行了 proton-cs 的数据目录变更，那么需要手动通过如下命令停止mongodb组件，规避异常关闭导致所有mongodb的副本集成员都处于other状态问题。

kubectl -nresource get sts mongodb-mongodb -ojsonpath='{.status.replicas}' > /opt/mongodb.replicas;
kubectl -nresource scale sts mongodb-mongo --replicas=0;

10. 复制数据目录

预计停机时间：根据数据量、磁盘性能和网络性能而有所不同。

容器组件数据目录的复制
使用如下 rsync 命令在待迁移组件的数据源节点进行数据目录内容拷贝。注意：
复制时需确保包含最后一级目录本体，保留文件权限和属主属组信息；
要依据步骤4里面记录的组件副本和节点、数据目录的映射关系，一一进行数据目录的复制，不要错乱；
为减少对于业务的影响，建议在业务低峰期进行数据目录的拷贝，同时应该限制拷贝速度，减少对业务造成影响；
拷贝的目标目录不应为非空状态，否则会覆盖原有数据！

rsync -avz --progress <old_data_path> root@1.2.3.4:<new_data_path>

使用如下 rsync 命令进行数据目录内容拷贝。注意：

复制时需确保包含最后一级目录本体，保留文件权限和属主属组信息；
拷贝的目标目录不应为非空状态，否则会覆盖原有数据！
注意空间是否充足，避免拷贝失败。
不可变化主机服务前后节点，仅支持在同节点上进行数据目录的切换。

rsync -avz --progress <old_data_path> <new_data_path>

11. 启动主机服务

预计停机时间：<20分钟
如果不重启物理机的话，预计停机时间：<10分钟

启动主机服务
如果是docker作为容器运行使用如下命令启动相关的主机服务

systemctl start docker containerd kubelet proton-cr proton-cr-registry proton-cr-chartmuseum docker.socket;

如果是containerd作为容器运行时，为确保显示效果，应直接重启节点的方式启动服务

reboot

等待 proton-cs 集群恢复正常
执行如下命令检查 proton-cs 集群状态，确认所有pod都处于completed状态或者running+ready状态

如果进行了资源组件的namespace的自定义，应使用自定义的namespace

kubectl get no;
kubectl get po -n kube-system;
kubectl get po -n resource

特殊的，如果之前手动通过缩容为0副本的方式停止了 mongodb 组件，那么需要手动通过如下命令启动 mongodb 组件：

kubectl -nresource scale sts mongodb-mongo --replicas=$(cat /opt/mongodb.replicas);

12. 安装组件

预计停机时间：<5分钟

部分组件的启动时间和数据量相关，极端情况下，可能超过5min，达到10min左右

进入依赖包解压目录，使用以下命令复用数据目录的情况下安装组件：

proton-cli get conf > current.yaml && proton apply -f current.yaml

检查组件的 Pod 是否有异常(如果进行了资源组件的namespace的自定义，应使用自定义的namespace)：

如果进行了资源组件的namespace的自定义，应使用自定义的namespace

kubectl -n resource get po

13. 启动应用服务

预计时间：<10分钟

根据记录的副本数信息，恢复应用服务的 Deployment、StatefulSet 和 DaemonSet 的副本数。执行以下命令启动服务：

bash app_manage.sh start

然后使用以下命令检查 Pod 是否已成功启动，确保没有异常 Pod：

如果进行了应用服务namespace的自定义，应使用自定义的namespace

kubectl -n anyshare get po

功能和修改效果确认

容器内的基础组件，可通过查看其pv确认是否修改成功

例如查看mongodb-0的pv

kubectl get pv mongodb-mongodb-resource-0 -oyaml | yq .spec.local.path

主机侧的组件，可通过查看其配置文件确认是否修改成功

例如查看 docker 的配置文件

yq ."data-root" /etc/docker/daemon.json

< 上一篇：

下一篇： >

proton组件切换数据目录

Proton 组件数据目录迁移指导手册

重要提示

1. 适用范围

1.1 标准组件数据目录迁移

1.2 核心服务组件数据目录迁移

2. 迁移方案概述

2.1 主机服务及支持配置直接变更的容器服务

2.2 不支持直接变更配置的容器服务

3. 技术原理

3.1 基础架构说明

3.2 数据目录切换机制

3.3 StatefulSet 特性说明

3.4 数据迁移工具

3.5 组件管理方式

1. 上传包

2. 镜像预热

3. 获取 Secret

4. 修改配置文件内的数据目录

5. 在线全量拷贝数据目录

6. 停机

7. 更新 Secret

内容：

8. 卸载组件

内容：

9. 停止主机服务

10. 复制数据目录

11. 启动主机服务

12. 安装组件

13. 启动应用服务

功能和修改效果确认