GCDW物理机版安装过程遇到问题汇总
说明：三节点VM虚机，最小化安装操作系统
整理：需要安装的必要的依赖和组件
dnf mcli minio Java postgresql-libs libcgroup gcc gcc-c++ glibc-devel glibc-static libmpc-devel mpfr-devel gmp-devel
总结：1.最小化安装的操作系统，请务必先梳理环境依赖
2.配置文件修改完后一定要按照实际情况去检查
3.遇到报错，先查看日志，找具体原因
问题一：FDB集群安装部署时，报错dnf未找到
./auto.sh \ -h "192.168.80.120 root 1 192.168.80.121 root 1 192.168.80.122 root 1" \ -e “ansible_ssh_port=22 ansible_python_interpreter=/usr/bin/python \ fdb_source_dir=/fdb/FDBDeploy/package/ \ fdb_rpm_client=foundationdb-clients-6.3.25-20260408143753.el7.x86_64.rpm \ fdb_rpm_server=foundationdb-server-6.3.25-20260408143753.el7.x86_64.rpm \ fdbcli_log_dir=/opt/fdbcli_log/ file_owner=root file_group=root \ task_time_out=120 redundancy_mode=double storage_engine=memory \ stateless_process=4 transaction_process=2 storage_process=2 \ coordinator_servers='192.168.80.120:4500 192.168.80.121:4500 192.168.80.122:4500' \ proxies_number=1 resolver_number=1 logs_number=8 fdbcli_passwd=Gcdw@2025”
使用上述命令安装GCDW的FDB集群，报错如下：
TASK [uninstall fdb-server via dnf] *********************************************************** fatal: [other_host2]: FAILED! => {"ansible_job_id": "860790340006.8146", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} fatal: [pri_host]: FAILED! => {"ansible_job_id": "24000327893.3870", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} fatal: [other_host1]: FAILED! => {"ansible_job_id": "638669924867.3868", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} TASK [check if all hosts succeed] ************************************************************* failed: [pri_host] (item=pri_host) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "pri_host", "msg": "Assertion failed" } failed: [other_host1] (item=pri_host) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "pri_host", "msg": "Assertion failed" } failed: [other_host1] (item=other_host1) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host1", "msg": "Assertion failed" } failed: [other_host1] (item=other_host2) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host2", "msg": "Assertion failed" } failed: [pri_host] (item=other_host1) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host1", "msg": "Assertion failed" } failed: [pri_host] (item=other_host2) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host2", "msg": "Assertion failed" } failed: [other_host2] (item=pri_host) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "pri_host", "msg": "Assertion failed" } failed: [other_host2] (item=other_host1) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host1", "msg": "Assertion failed" } failed: [other_host2] (item=other_host2) => { "ansible_loop_var": "item", "assertion": "hostvars[item]['result_flag'] == true", "changed": false, "evaluated_to": false, "item": "other_host2", "msg": "Assertion failed" } TASK [uninstall fdb-server via dnf] *********************************************************** fatal: [pri_host]: FAILED! => {"ansible_job_id": "578273800960.3950", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} fatal: [other_host2]: FAILED! => {"ansible_job_id": "783304103408.8352", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} fatal: [other_host1]: FAILED! => {"ansible_job_id": "210381059025.4121", "changed": false, "cmd": "dnf install -y python2-dnf", "finished": 1, "msg": "[Errno 2] 没有那个文件或目录", "rc": 2} PLAY RECAP ************************************************************************************ 127.0.0.1 : ok=11 changed=1 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0 other_host1 : ok=6 changed=0 unreachable=0 failed=1 skipped=4 rescued=2 ignored=0 other_host2 : ok=6 changed=0 unreachable=0 failed=1 skipped=4 rescued=2 ignored=0 pri_host : ok=6 changed=0 unreachable=0 failed=1 skipped=4 rescued=2 ignored=0 failed to install fdb.
报错原因分析
在错误日志中：
"cmd": "dnf install -y python2-dnf", "msg": "[Errno 2] 没有那个文件或目录"
这里的 [Errno 2] 没有那个文件或目录 (No such file or directory) 是 Linux 系统的标准错误码。当 Ansible 通过 shell 或 command 模块执行任务时，如果指定的命令（这里是 dnf）在当前节点的 $PATH 环境变量中找不到，系统就会抛出这个错误。
具体排查方向
- 目标节点未安装 dnf：
虽然您的 RPM 包名带有 .el7（通常对应 CentOS/RHEL 7），但 CentOS 7 默认的包管理器是 yum，而 dnf 是 CentOS 8 / RHEL 8 及以后版本的默认包管理器。如果目标节点是 CentOS 7 且没有额外安装 dnf，就会报此错误。 - dnf 不在默认 PATH 中：
如果节点上确实安装了 dnf，但它被安装在了非标准路径下（例如 /opt/freeware/bin/dnf），而 Ansible 执行时的默认 PATH 不包含该路径，同样会报找不到文件。
解决建议
您可以登录到报错的节点（如 pri_host），手动执行以下命令进行排查：
- 检查 dnf 是否存在：which dnf 或 whereis dnf
- 如果不存在，尝试使用 yum 安装：yum install -y dnf
- 如果存在但路径特殊，请在 Ansible 的 playbook 中使用绝对路径（例如 /usr/bin/dnf install -y python2-dnf），或者在执行前配置好环境变量。
结果
yum install -y dnf安装完dnf后，重新执行上述安装命令后没有再报错，问题解决！
注意
安装过程可能会有连接不到其他节点的报错，关闭防火墙即可。
报错如下：
TASK [set coordinator] ************************************************************************ fatal: [pri_host]: FAILED! => {"ansible_job_id": "490167682773.10034", "changed": true, "cmd": "fdbcli --log --log-dir /opt/fdbcli_log/ -p Gcdw@2025 --exec \"coordinators 192.168.80.120:4500 192.168.80.121:4500 192.168.80.122:4500\"", "delta": "0:00:05.715780", "end": "2026-07-07 18:41:42.144734", "finished": 1, "msg": "non-zero return code", "rc": 1, "start": "2026-07-07 18:41:36.428954", "stderr": "\nWARNING: Long delay (Ctrl-C to interrupt)\nERROR: One of the specified coordinators is unreachable", "stderr_lines": ["", "WARNING: Long delay (Ctrl-C to interrupt)", "ERROR: One of the specified coordinators is unreachable"], "stdout": "Password matched!", "stdout_lines": ["Password matched!"]} PLAY RECAP ************************************************************************************ pri_host : ok=3 changed=2 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 failed to set fdb cluster.
问题2：minio和mcli安装后启动失败问题
[root@localhost data]# rpm -ivh mcli-20250721052808.0.0-1.x86_64.rpm
准备中... ################################# [100%]
正在升级/安装... 1:mcli-20250721052808.0.0-1 ################################# [100%]
[root@localhost data]# ll
总用量 48724 -rwxrwxrwx. 1 root root 11572893
7月 8 11:06 mcli-20250721052808.0.0-1.x86_64.rpm -rwxrwxrwx. 1 root root 38317694
7月 8 11:00 minio-20240704142545.0.0-1.x86_64.rpm
[root@localhost data]# rpm -ivh minio-20240704142545.0.0-1.x86_64.rpm
准备中... ################################# [100%]
正在升级/安装... 1:minio-20240704142545.0.0-1 ################################# [100%]
[root@localhost data]#
[root@localhost data]# minio server /data/ Formatting 1st pool, 1 set(s), 1 drives per set. WARNING: Host local has more than 0 drives of set. A host failure will result in data becoming unavailable. MinIO Object Storage Server Copyright: 2015-2026 MinIO, Inc. License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html Version: RELEASE.2024-07-04T14-25-45Z (go1.22.5 linux/amd64) API: http://192.168.80.120:9000 http://127.0.0.1:9000 RootUser: minioadmin RootPass: minioadmin WebUI: http://192.168.80.120:35984 http://127.0.0.1:35984 RootUser: minioadmin RootPass: minioadmin CLI: https://min.io/docs/minio/linux/reference/minio-mc.html#quickstart $ mc alias set 'myminio' 'http://192.168.80.120:9000' 'minioadmin' 'minioadmin' Docs: https://min.io/docs/minio/linux/index.html Status: 1 Online, 0 Offline. STARTUP WARNINGS: - Detected Linux kernel version older than 4.0.0 release, there are some known potential performance problems with this kernel version. MinIO recommends a minimum of 4.x.x linux kernel version for best performance - Detected default credentials 'minioadmin:minioadmin', we recommend that you change these values with 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' environment variables - The standard parity is set to 0. This can lead to data loss. ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ You are running an older version of MinIO released 1 year before the latest release ┃ ┃ Update: Run `mc admin update ALIAS` ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ^CExiting on signal: INTERRUPT
[root@localhost data]# systemctl status minio ● minio.service - MinIO Loaded: loaded (/usr/lib/systemd/system/minio.service; disabled; vendor preset: disabled) Active: inactive (dead) Docs: https://docs.min.io 7月 08 11:10:28 localhost.localdomain systemd[1]: [/usr/lib/systemd/system/minio.service:...e' Hint: Some lines were ellipsized, use -l to show in full. [root@localhost data]# systemctl start minio Job for minio.service failed because a timeout was exceeded. See "systemctl status minio.service" and "journalctl -xe" for details.
[root@localhost data]# systemctl status minio ● minio.service - MinIO Loaded: loaded (/usr/lib/systemd/system/minio.service; disabled; vendor preset: disabled) Active: failed (Result: timeout) since 三 2026-07-08 11:10:35 CST; 11s ago Docs: https://docs.min.io Main PID: 24944 CGroup: /system.slice/minio.service 7月 08 11:10:35 localhost.localdomain systemd[1]: Starting MinIO... 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service start operation timed out...g. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service stop-sigterm timed out. S...L. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service stop-final-sigterm timed ...e. 7月 08 11:10:35 localhost.localdomain systemd[1]: Failed to start MinIO. 7月 08 11:10:35 localhost.localdomain systemd[1]: Unit minio.service entered failed state. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service failed. Hint: Some lines were ellipsized, use -l to show in full.
[root@localhost data]# journalctl -xe
-- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit minio.service has begun starting up. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service start operation timed out. Term 7月 08 11:10:35 localhost.localdomain systemd[1]: Failed to start MinIO. -- Subject: Unit minio.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit minio.service has failed. -- -- The result is failed. 7月 08 11:10:35 localhost.localdomain systemd[1]: Unit minio.service entered failed state. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service failed. 7月 08 11:10:35 localhost.localdomain polkitd[677]: Unregistered Authentication Agent for unix- 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service holdoff time over, scheduling r 7月 08 11:10:35 localhost.localdomain systemd[1]: Stopped MinIO. -- Subject: Unit minio.service has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit minio.service has finished shutting down. 7月 08 11:10:35 localhost.localdomain systemd[1]: Starting MinIO... -- Subject: Unit minio.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit minio.service has begun starting up. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service start operation timed out. Term 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service stop-sigterm timed out. Skippin 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service stop-final-sigterm timed out. S 7月 08 11:10:35 localhost.localdomain systemd[1]: Failed to start MinIO. -- Subject: Unit minio.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit minio.service has failed. -- -- The result is failed. 7月 08 11:10:35 localhost.localdomain systemd[1]: Unit minio.service entered failed state. 7月 08 11:10:35 localhost.localdomain systemd[1]: minio.service failed.
核心原因分析
在您的 minio.service 配置文件中，有这样一行：
Type=notify
当设置为 Type=notify 时，Systemd 会等待 MinIO 进程主动发送一个“我已经启动完毕”的通知信号（READY=1）。如果 MinIO 进程因为某些原因（例如内核版本过低、glibc 版本过低等）无法正确发送这个信号，Systemd 就会一直傻等，直到超时（start operation timed out）。
线索就在您之前手动启动 MinIO 时的警告中：
Detected Linux kernel version older than 4.0.0 release...
这说明您的系统内核版本非常老（很可能是 CentOS 7 甚至更早）。在老版本系统上，Systemd 的 notify 机制经常会出现兼容性问题。
解决方案
我们需要将 Type=notify 改为普通的 Type=simple，让 Systemd 只要启动了进程就认为服务已启动。
编辑下面的配置文件
vi /usr/lib/systemd/system/minio.service
按上述改完重启后，继续报错如下：
[root@localhost bin]# systemctl status minio ● minio.service - MinIO Loaded: loaded (/usr/lib/systemd/system/minio.service; disabled; vendor preset: disabled) Active: failed (Result: start-limit) since 三 2026-07-08 11:31:57 CST; 14s ago
Docs: https://docs.min.io
Process: 25105
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES (code=exited, status=217/USER)
Main PID: 25105 (code=exited, status=217/USER)
错误原因分析
在您的 minio.service 文件的 [Service] 部分，有这样两行配置：
User=minio-user
Group=minio-user
您的 Linux 系统在启动服务时，尝试切换到 minio-user 这个用户身份去运行 MinIO 进程。但是，您的系统中并没有创建这个用户，因此 systemd 报错 status=217/USER（用户不存在）。
修改服务文件，使用 root 用户运行（不推荐，仅用于测试）
如果您只是想快速测试 MinIO 是否能起来，可以修改服务文件，让其使用 root 用户运行。注意：在生产环境中，以 root 身份运行服务存在安全风险。
User=root
Group=root
问题3：安装GCDW时报错
*********************************************************************************
Welcome to install GBase products ********************************************************************************* Error: gcinstall.py(line 2824) -- Can not find valid env(JAVA_HOME), "GCDW_JAVA_HOME" must be assigned in demo.options.
错误原因分析
没有Java环境（系统是最小化安装的）
解决方案
安装Java环境
sudo yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel
安装完Java后，继续安装，报错如下：
Welcome to install GBase products
*********************************************************************************
Error: gcinstall.py(line 2824) -- Can not find valid env(JAVA_HOME), "GCDW_JAVA_HOME" must be assigned in demo.options.
错误分析
没有设置JAVA_HOME变量环境
解决方案
在/etc/profile中加入Java的变量环境
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.412.b08-1.el7_9.x86_64
export PATH=$JAVA_HOME/bin:$PATH
生效
source /etc/profile
修改后，再次安装，报错
Welcome to install GBase products
*********************************************************************************
Environmental Checking on cluster nodes.
checking rpms ...
Error: gcinstall.py(line 2830) -- cluster needs some rpms to running.
192.168.80.122: postgresql-libs
192.168.80.120: postgresql-libs
192.168.80.121: postgresql-libs
报错原因：需要postgresql-libs，各节点安装postgresql-libs
[gbase@localhost gcinstall]$ yum install postgresql
postgresql-contrib.x86_64 postgresql-plperl.x86_64
postgresql-devel.i686 postgresql-plpython.x86_64
postgresql-devel.x86_64 postgresql-pltcl.x86_64
postgresql-docs.x86_64 postgresql-server.x86_64
postgresql.i686 postgresql-static.i686
postgresql-jdbc-javadoc.noarch postgresql-static.x86_64
postgresql-jdbc.noarch postgresql-test.x86_64
postgresql-libs.i686 postgresql-upgrade.x86_64
postgresql-libs.x86_64 postgresql.x86_64
postgresql-odbc.x86_64
[gbase@localhost gcinstall]$ yum install postgresql-libs.x86_64
继续，报错
题外：最小化安装系统就要做好没啥装啥的准备，唉
Welcome to install GBase products
*********************************************************************************
Environmental Checking on cluster nodes.
checking rpms ...
checking gconfig service
command "lssubsys" not found on host [192.168.80.122]
command "lssubsys" not found on host [192.168.80.121]
command "lssubsys" not found on host [192.168.80.120]
Cgconfig service is not exist on host ['192.168.80.120', '192.168.80.121', '192.168.80.122'], resource manangement can not be used, continue ([Y,y]/[N,n])? N
系统中缺少 libcgroup 相关的工具包
安装libgroup
yum install -y libcgroup-tools
问题4：安装GCDW后节点起不来
192.168.80.122 install gcware and cluster on host 192.168.80.122 successfully. 192.168.80.120 install gcware and cluster on host 192.168.80.120 successfully. 192.168.80.121 install gcware and cluster on host 192.168.80.121 successfully. init account to foundationdb successfully adding user and nodes message to foundationdb adding user and nodes message to foundationdb successfully Starting all gcluster nodes ... start cluster service failed on host 192.168.80.120. start cluster service failed on host 192.168.80.122. adding new datanodes to gcware ...
错误原因分析
大概率还是其他两个节点缺少依赖包之类的，排查一下
GBase 的底层服务（如 gcware 和 gclusterd）依赖一些特定的动态链接库。
请在报错的节点（120 和 122）上执行以下命令，检查是否缺少依赖：
# 检查 gcware 依赖
ldd /opt/gcdw/192.168.80.120/gcware/sbin/gcware | grep "not found"
# 检查 gclusterd 依赖
ldd /opt/gcdw/192.168.80.120/gcluster/server/bin/gclusterd | grep "not found"
检查结果
[root@localhost sbin]# ldd /opt/gcdw/192.168.80.122/gcware/sbin/gcware | grep "not found"
/opt/gcdw/192.168.80.122/gcware/sbin/gcware: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /opt/gcdw/192.168.80.122/gcware/sbin/gcware)
/opt/gcdw/192.168.80.122/gcware/sbin/gcware: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /opt/gcdw/192.168.80.122/gcware/sbin/gcware)
/opt/gcdw/192.168.80.122/gcware/sbin/gcware: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /opt/gcdw/192.168.80.122/gcware/sbin/gcware)
解决方案
果然是缺少依赖，没办法，两节点都安装依赖
[root@localhost sbin]# yum install -y vim wget gcc gcc-c++ glibc-devel glibc-static libmpc-devel mpfr-devel gmp-devel
安装完上述依赖，验证一下
[root@localhost gcdw]# strings /lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH
然后，继续删除三节点的目录后重装
（有这个目录，重装时会报错Error: gcinstall.py(line 2824) -- 192.168.80.122 192.168.80.122 is a new coordinate/data node, but dir /opt/gcdw/192.168.80.122/gnode exists.），说实话，这个有点不太智能了，应该改成扫描一遍已安装的文件啥的
[root@localhost sbin]# rm -rf /opt/gcdw/192.168.80.122/
注意：这里，主节点删除/192.168.80.121/目录时，会提示有程序在运行，需后台搜出进程杀死后再删除这个文件夹，否则即使使用root用户删除了这个文件夹，再刷新，他还会自动生成这个文件夹的。
三节点删除完文件夹后，主节点继续重新执行
[gbase@localhost gcinstall]$ ./gcinstall.py --silent=demo.options
问题5：安装GCDW报错退出安装程序(FDB存在gcdw元数据)
account password already exists
adding user and nodes message to foundationdb
account: gcdw
begin to check whether the account name gcdw exists
gcdw is exists
FAILED!!!
adding user and nodes message to foundationdb failed
fail to install cluster,begin to restoring ...
restore successfully.
错误原因分析
报错 account password already exists 和 gcdw is exists FAILED!!!，说明在 GBase GCDW 安装过程中，系统检测到名为 gcdw 的账户或元数据记录已存在于 FoundationDB 中，导致无法重复创建，从而中断了集群部署流程。
这通常是由于上一次安装失败后未彻底清理残留数据所致
解决方案
一、问题根因分析
安装脚本在执行 adding user and nodes message to foundationdb 步骤时，会尝试在分布式键值数据库 FoundationDB 中注册集群节点信息。
如果前次安装中途失败（如服务启动失败、网络中断等），这些元数据可能未被清除，导致本次安装时检测到“账户已存在”，从而抛出 FAILED!!! 错误。
此错误不会自动回滚，必须手动清理后才能重试。
二、解决方案：彻底清理 FoundationDB 中的残留数据
请在任意一个已部署 GBase 的节点上，以 gbase 用户执行以下操作：
#进入 FoundationDB 命令行工具
su - gbase
fdbcli -p Gcdw@2025
#查看当前存在的账户/节点信息
在 fdbcli> 提示符下执行：
fdb> getrange \x00 \xff
这会列出所有键值对，查找包含 gcdw 或 account 相关的条目。
#删除残留的 gcdw 账户记录
假设你看到的键是类似 \x00account/gcdw 或 \x00nodes/gcdw，请执行：
fdb> clear \x00account/gcdw
fdb> clear \x00nodes/gcdw
⚠️ 注意：具体键名可能因版本不同而异，请以实际输出为准。若不确定，可先截图或复制输出内容，再针对性删除。
#clear时报错
fdb> clear re:gcdw
ERROR: writemode must be enabled to set or clear keys in the database.
这是没有写的权限，需执行如下命令
fdb> writemode on
再执行clear命令，执行成功显示
#退出并验证
quit
然后重新运行安装命令：
./gcinstall.py --silent=demo.options
热门帖子
- 12025-12-01浏览数：182759
- 22023-05-09浏览数：25054
- 42023-09-25浏览数：18521
- 52020-05-11浏览数：17526