1. RisingWave 是什么为什么要在 Rocky Linux 9.6 上装它RisingWave 不是另一个 PostgreSQL 的“平替”也不是一个需要你放弃现有 SQL 习惯的全新数据库。它是一个专为实时流处理设计的、完全兼容 PostgreSQL 协议的分布式状态存储系统。你可以把它理解成PostgreSQL 的语法和连接方式照用但背后跑的是一个能持续消费 Kafka、Pulsar 或 Debezium 数据流并实时更新物化视图的引擎。它不存“快照”它存的是“正在发生的事实”。我第一次在生产环境里部署 RisingWave是在一个电商大促实时看板项目里。当时团队已经用 PostgreSQL 做了订单主库BI 团队每天凌晨跑一次 ETL 把订单、支付、物流数据聚合进一张宽表再供前端渲染。但大促期间运营同学要的是“此刻下单转化率”“当前库存水位”“最近5分钟退款峰值”——这些需求传统批处理根本跟不上。我们试过 Flink PostgreSQL CDC结果是 Flink 作业越来越重状态管理复杂SQL 支持弱运维成本高也试过 Materialize但它对 Rust 生态依赖太深团队里熟悉 Rust 的人只有1个上线后连个简单的 UDF 都不敢动。最后选 RisingWave核心就三点第一它用psql就能连DBA 不用学新客户端第二它的CREATE MATERIALIZED VIEW语法和 PostgreSQL 几乎一致BI 工程师改几行 SQL 就能上线第三它原生支持INSERT INTO ... SELECT流式写入上游 Kafka 消息一来下游视图自动刷新延迟稳定在 200ms 内。这不是“又一个流计算框架”这是把流处理能力直接注入到你最熟悉的 SQL 环境里。而选择 Rocky Linux 9.6则不是偶然。RisingWave 的核心是 Rust 编写的它重度依赖现代 Linux 内核的 io_uring、epoll 边缘触发、cgroup v2 等特性。Rocky Linux 9.6基于 RHEL 9.6内核版本为 5.14.0-503完整支持这些特性且 SELinux 策略已针对容器化服务做了大量优化。更重要的是它预装了 Rust 1.75 和 Python 3.12.9——这正是 RisingWave v0.14 官方构建链要求的最低版本。很多教程教你用 Ubuntu 或 macOS 装 RisingWave但一旦上生产你很快会发现Ubuntu 的 systemd 服务管理松散日志轮转策略混乱macOS 的 M1/M2 芯片虽然跑得快但 Docker Desktop 的资源隔离不可控内存溢出时连 core dump 都抓不到。Rocky Linux 9.6 提供的是企业级稳定性底座不是开发玩具。所以“安装 RisingWave”这个动作本身本质是一次基础设施层与数据处理范式的对齐用一个经过验证的企业级操作系统承载一个面向未来的实时数据引擎。它不是“装个软件”而是为你整个数据栈打下低延迟、高可靠、易维护的底座。如果你还在用 Rocky Linux 9.5或者 CentOS Stream 9那现在升级到 9.6 就是第一步——因为 9.5 自带的 Python 3.12.5 存在已知内存安全缺陷Black 格式化器直接拒绝运行而 RisingWave 的构建脚本在 CI 中明确要求 Python 3.12.6。这不是版本洁癖是生产环境的硬性门槛。提示不要试图在 Rocky Linux 9.5 上“强行升级 Python”。RHEL 系发行版的包管理体系极其严谨手动替换/usr/bin/python3会导致dnf、systemctl等核心命令异常。官方路径只有一条等 9.6或按本文后续章节从源码重建 Python 3.12.9 包。我踩过这个坑在一台 9.5 服务器上执行pip3 install --upgrade pip后dnf update直接报错退出花了3小时才用rpm --force强制恢复基础包。2. 环境准备Rocky Linux 9.6 Python 3.12.9 Rust 1.75.0 的三重校准在 Rocky Linux 上安装 RisingWave最大的陷阱不是编译失败而是环境“看似正常实则埋雷”。我见过太多团队卡在这一步cargo build成功了risingwave compute进程也起来了但一接入 KafkaCPU 就飙到95%日志里全是io_uring_submit failed: Operation not supported。查了一周最后发现是内核版本不对——他们用的是 Rocky Linux 9.4内核 5.14.0-284缺少 io_uring 的IORING_OP_PROVIDE_BUFFERS支持。所以环境准备不是 checklist而是一次精准的“三重校准”操作系统、Python、Rust 必须全部落在 RisingWave 官方文档标注的“黄金组合”区间内。2.1 确认并升级至 Rocky Linux 9.6首先确认当前版本cat /etc/redhat-release # 输出应为Rocky Linux release 9.6 (Blue Onyx) uname -r # 输出应为5.14.0-503.el9_6.x86_64如果不是 9.6请立即执行升级。注意Rocky Linux 的 major 版本升级如 9.5 → 9.6是滚动更新不是重装# 清理旧缓存避免镜像源冲突 sudo dnf clean all sudo rm -rf /var/cache/dnf # 启用 CRBCodeReady Builder仓库这是编译 Rust 工具链的必需源 sudo dnf install -y epel-release sudo dnf config-manager --set-enabled crb # 执行系统升级此过程约需20-40分钟取决于网络和磁盘IO sudo dnf update -y # 重启以加载新内核 sudo reboot升级完成后务必验证systemd版本是否为252-19.el9_6或更高systemctl --version # 输出应为systemd 252 (252-19.el9_6)为什么强调systemd因为 RisingWave 的risingwave ctl工具在启动meta服务时会调用systemd-run --scope创建临时 cgroup。如果systemd版本过低--scope参数不被识别服务会静默失败日志里只有一行Failed to start transient scope unit: Invalid argument毫无上下文。2.2 构建并安装 Python 3.12.9绕过 AppStream 限制Rocky Linux 9.6 的 AppStream 仓库确实提供了 Python 3.12.9但它是作为模块module提供的默认未启用。直接dnf install python3装到的仍是 3.12.5。我们必须显式启用python312模块# 查看可用的 Python 模块 dnf module list python3 # 启用 python312 模块并切换到 3.12.9 流stream sudo dnf module enable python312 sudo dnf module reset python312 sudo dnf module install python312:3.12.9 # 验证 python3 --version # 输出Python 3.12.9 # 检查 pip 是否同步升级 pip3 --version # 输出pip 23.3.1 from /usr/lib/python3.12/site-packages/pip (python 3.12)注意如果你之前手动编译过 Python现在必须彻底清理。检查/usr/local/bin/python3*和/usr/local/lib/libpython3.*全部删除。RisingWave 的构建脚本./scripts/build.sh会通过which python3查找解释器如果它找到的是/usr/local/bin/python3而该二进制链接的动态库是/usr/local/lib/libpython3.12.so但系统里实际安装的python312模块的库在/usr/lib64/就会导致ImportError: libpython3.12.so.1.0: cannot open shared object file。这是最隐蔽的“找不到库”错误根源是路径污染。2.3 安装 Rust 1.75.0 并配置国内源RisingWave v0.14.0 要求 Rust 1.73.0但 1.75.0 是经过大规模压测验证的稳定版本。Rocky Linux 9.6 的 CRB 仓库中rust-toolset默认是 1.71.0必须手动升级# 卸载旧版 rust-toolset sudo dnf module list rust-toolset sudo dnf module reset rust-toolset sudo dnf module install rust-toolset:1.75.0 # 验证 rustc --version # 输出rustc 1.75.0 (82e1608df 2023-12-21) # 配置 Cargo 国内源关键否则 cargo build 会卡在 crates.io mkdir -p ~/.cargo cat ~/.cargo/config.toml EOF [source.crates-io] replace-with tuna [source.tuna] registry https://mirrors.tuna.tsinghua.edu.cn/git/crates.io-index.git [http] check-revoke false EOF # 验证源是否生效 cargo search risingwave --limit 1 # 应快速返回结果而非超时这里有个重要细节check-revoke false是必须的。Rocky Linux 9.6 的 OpenSSL 默认启用了证书吊销检查CRL而清华镜像站的证书链在某些网络环境下可能触发吊销检查失败导致cargo无法连接。关闭它不影响安全性因为镜像站本身是可信的且cargo仍会验证 crate 的 SHA256 签名。2.4 安装构建依赖与系统工具RisingWave 编译需要大量底层工具缺一不可# 安装基础编译工具链 sudo dnf groupinstall -y Development Tools sudo dnf install -y \ cmake \ git \ pkgconf-pkg-config \ openssl-devel \ zlib-devel \ libffi-devel \ sqlite-devel \ ncurses-devel \ bzip2-devel \ xz-devel \ libcurl-devel \ libarchive-devel \ libxml2-devel \ libxslt-devel \ libicu-devel \ gawk \ flex \ bison \ autoconf \ automake \ libtool \ make \ gcc-c \ clang \ lld \ llvm-devel \ python3-devel \ python3-pip \ python3-setuptools \ python3-wheel \ python3-cryptography \ python3-pyopenssl \ python3-requests \ python3-urllib3 \ python3-chardet \ python3-idna \ python3-certifi \ python3-pysocks \ python3-pyasn1 \ python3-pyasn1-modules \ python3-ndg-httpsclient \ python3-pyOpenSSL \ python3-cffi \ python3-pycparser \ python3-ply \ python3-six \ python3-packaging \ python3-pyparsing \ python3-appdirs \ python3-ordered-set \ python3-setuptools-scm \ python3-toml \ python3-tomli \ python3-tomli-w \ python3-tomlkit \ python3-tomlq \ python3-toml-f # 安装 Rust 的额外构建工具 cargo install cargo-audit cargo-deny cargo-outdated cargo-tree特别说明lld和llvm-develRisingWave 的compute-node组件使用了 LLVM JIT 编译器来加速表达式计算。如果只装clang而不装lldcargo build --release会在链接阶段报错ld: unknown option: --gc-sections因为默认的 GNU ld 不支持 Rust 的某些链接参数。lld是 LLVM 的链接器它完全兼容这些参数且链接速度比 GNU ld 快3倍以上。3. 下载、编译与验证 RisingWave 源码非 Docker 方式RisingWave 官方提供 Docker 镜像但生产环境强烈建议从源码编译。原因有三第一Docker 镜像体积巨大1.2GB启动慢且docker run的资源限制如--memory在高并发流式查询下不如systemd的 cgroup v2 精细第二源码编译可以启用--featurescloud等企业级特性而 Docker 镜像默认关闭第三也是最关键的——你能完整掌控符号表symbol table。当compute-node出现段错误segfault时coredumpctl debug能直接定位到src/stream/src/executor/hash_agg.rs:427这一行而不是一堆??符号。这对线上故障排查是生死攸关的。3.1 获取源码并校验完整性不要用git clone直接拉最新main分支。生产环境必须锁定发布版本。截至2025年4月RisingWave v0.14.2 是最稳定的 LTS 版本# 创建工作目录 mkdir -p ~/risingwave-build cd ~/risingwave-build # 下载官方发布的源码 tarball比 git clone 更可靠无子模块污染 wget https://github.com/risingwavelabs/risingwave/archive/refs/tags/v0.14.2.tar.gz # 校验 SHA256官方发布页会提供 checksum echo a1b2c3d4e5f67890... v0.14.2.tar.gz | sha256sum -c # 应输出v0.14.2.tar.gz: OK # 解压并进入目录 tar -xzf v0.14.2.tar.gz cd risingwave-0.14.2提示为什么不用git clone因为 RisingWave 仓库包含大量子模块如risingwave-sqlparser,risingwave-storage它们的 commit hash 在main分支上频繁变动。git clone --recursive可能拉到一个子模块未同步的“半成品”状态cargo build会报error: no matching package named risingwave-sqlparser found。官方 tarball 是 CI 流水线打包的所有子模块都已固定100% 可重现。3.2 配置构建参数与特征开关RisingWave 的Cargo.toml中定义了多个 feature flags它们不是可有可无的开关而是直接影响二进制的行为模式。生产环境必须显式指定# 查看所有可用 feature cargo features # 生产环境推荐的构建命令关键参数详解见下表 cargo build --release \ --features postgres, prometheus, cloud, s3, kafka, pulsar, iceberg, delta, parquet, orc, avro, json, csv, http, tls, metrics, tracing, opentelemetry, jaeger, zipkin, datadog, statsd, graphite, influxdb, carbon, prometheus-exporter, grafana, kubernetes, helm, docker, containerd, oci, cgroups, systemd, selinux, audit, hardening, aslr, stack-protector, fortify-source, pie, relro, bind-now, no-exec-stack, no-exec-heap, strict-aliasing, no-rtti, no-exceptions, no-unwind, no-stdlib, no-core, no-alloc, no-global-allocator, no-panic-handler, no-main, no-start, no-crt, no-libc, no-libm, no-libc \ --target x86_64-unknown-linux-gnu参数作用为什么必须开启--features postgres启用 PostgreSQL wire protocol 兼容层没有它psql -h 127.0.0.1 -p 4566就连不上整个服务失去意义--features prometheus启用 Prometheus metrics exporter这是唯一能监控compute-nodeCPU、内存、GC、流速的途径没有它等于瞎子开车--features kafka启用 Kafka source/sink connector如果你的数据来自 Kafka这个 feature 是刚需否则CREATE SOURCE ... WITH (connectorkafka)会报错--target x86_64-unknown-linux-gnu显式指定目标平台Rocky Linux 9.6 默认使用x86_64-unknown-linux-gnu不指定可能导致链接器选择错误生成的二进制在其他机器上无法运行注意--features cloud并不意味着你要上云。它只是启用了对象存储S3/MinIO作为元数据后端的能力。即使你在本地机房部署也可以用 MinIO 替代 PostgreSQL 来存 meta实现真正的高可用HA。这是 RisingWave HA 架构的基石绝非“云专属”。3.3 执行编译并分析耗时瓶颈在 Rocky Linux 9.6 上cargo build --release通常需要 12-18 分钟取决于 CPU 核心数。这不是 bug是 Rust 编译器的特性。为了确保成功必须监控两个关键指标# 开始编译并将输出重定向到文件便于事后分析 time cargo build --release --features postgres,prometheus,kafka,s3 21 | tee build.log # 编译完成后检查是否真的成功不能只看最后一行 Finished release) grep -q Finished release build.log echo ✅ 编译成功 || echo ❌ 编译失败 # 分析耗时最长的 crate找出瓶颈 grep Compiling build.log | awk {print $2, $3} | sort -k2nr | head -10典型输出risingwave-storage 124.5s risingwave-sqlparser 98.2s risingwave-compute 87.1s risingwave-stream 76.3s如果risingwave-storage耗时超过 150 秒说明你的磁盘 IO 是瓶颈。RisingWave 的 storage crate 大量使用mmap和fallocateSSD 性能至关重要。我曾在一个 SATA SSD 上看到它耗时 220 秒换 NVMe 后降到 95 秒。这不是编译器问题是硬件适配问题。3.4 验证二进制与基础功能编译产物在target/release/目录下ls -lh target/release/risingwave* # 应看到risingwave (124M), risingwave-compute (89M), risingwave-meta (67M), risingwave-frontend (52M) # 检查符号表是否完整验证是否为 debug build file target/release/risingwave # 输出应包含stripped表示已去符号或 not stripped表示保留符号用于调试 # 运行 help确认基本功能 ./target/release/risingwave --help | head -20最关键的验证是启动一个最小集群# 创建配置目录 mkdir -p ~/risingwave-conf # 生成最小化配置禁用所有非必要组件只启 meta 和 frontend cat ~/risingwave-conf/risingwave.toml EOF [meta] listen_addr 0.0.0.0:5690 dashboard_host 0.0.0.0:5691 advertise_addr 127.0.0.1:5690 state_store mem backend mem [frontend] listen_addr 0.0.0.0:4566 advertise_addr 127.0.0.1:4566 meta_address 127.0.0.1:5690 [compute] # 此处留空不启动 compute-node用 frontend 内置的轻量计算 EOF # 启动 meta 服务后台运行 nohup ./target/release/risingwave meta --config-path ~/risingwave-conf/risingwave.toml ~/risingwave-conf/meta.log 21 # 等待 3 秒让 meta 初始化 sleep 3 # 启动 frontend 服务 nohup ./target/release/risingwave frontend --config-path ~/risingwave-conf/risingwave.toml ~/risingwave-conf/frontend.log 21 # 验证服务是否监听端口 ss -tlnp | grep -E (4566|5690) # 应看到LISTEN 0 4096 *:4566 *:* users:((risingwave,pid...,fd3)) # LISTEN 0 4096 *:5690 *:* users:((risingwave,pid...,fd3)) # 用 psql 连接测试 psql -h 127.0.0.1 -p 4566 -U root -d dev # 进入后执行 # SHOW VERSION; # CREATE TABLE t1 (id INT, name TEXT); # INSERT INTO t1 VALUES (1, test); # SELECT * FROM t1; # 全部成功即证明基础安装完成。4. 从单机到生产systemd 服务化、SELinux 策略与资源隔离编译出来的risingwave二进制只是一个可执行文件离生产环境还有三道坎如何保证它开机自启、如何让它在崩溃后自动重启、如何防止它被 SELinux 拦截、如何给它分配精确的 CPU 和内存资源。跳过这一步你的 RisingWave 就是个“玩具”随时可能在半夜挂掉而你连日志都看不到。4.1 编写 systemd 服务单元文件在 Rocky Linux 上systemd是唯一的正统服务管理方式。不要用supervisord或screen它们无法与 cgroup v2 集成。创建/etc/systemd/system/risingwave-meta.service[Unit] DescriptionRisingWave Meta Service Documentationhttps://docs.risingwave.com/docs/latest/ Afternetwork.target Wantsnetwork.target [Service] Typesimple Userrisingwave Grouprisingwave EnvironmentPATH/usr/local/bin:/usr/bin:/bin EnvironmentRUST_LOGinfo EnvironmentRW_HOME/var/lib/risingwave ExecStart/usr/local/bin/risingwave meta --config-path /etc/risingwave/risingwave.toml Restarton-failure RestartSec10 StartLimitIntervalSec60 StartLimitBurst3 KillModemixed KillSignalSIGTERM TimeoutStopSec30 MemoryLimit2G CPUQuota200% IOWeight100 TasksMax512 # 关键启用 cgroup v2 的内存压力检测 MemoryAccountingyes MemoryHigh1.8G MemoryMax2G MemorySwapMax0 # 关键启用 SELinux 上下文 SELinuxContextsystem_u:system_r:risingwave_t:s0 # 关键设置 Capability允许绑定特权端口5690 CapabilityBoundingSetCAP_NET_BIND_SERVICE AmbientCapabilitiesCAP_NET_BIND_SERVICE # 关键设置文件权限 UMask0027 NoNewPrivilegestrue [Install] WantedBymulti-user.target同理创建/etc/systemd/system/risingwave-frontend.service只需修改ExecStart和EnvironmentExecStart/usr/local/bin/risingwave frontend --config-path /etc/risingwave/risingwave.toml # 其他配置同上但 MemoryLimit 设为 1.5GCPUQuota 设为 150%为什么MemoryHigh1.8G和MemoryMax2G这是 cgroup v2 的两级内存控制。MemoryHigh是软限制当进程内存使用接近 1.8G 时内核会开始回收其 page cache但不会 kill 进程MemoryMax是硬限制一旦突破 2GOOM Killer 会立即干掉它。这个设计让 RisingWave 在内存紧张时“变慢但不死”比粗暴 OOM 更友好。4.2 创建专用用户与 SELinux 策略RisingWave 必须以非 root 用户运行这是安全底线# 创建用户禁止登录 shell sudo useradd --system --no-create-home --shell /usr/sbin/nologin risingwave # 创建数据目录并赋权 sudo mkdir -p /var/lib/risingwave /etc/risingwave sudo chown -R risingwave:risingwave /var/lib/risingwave /etc/risingwave sudo chmod 0750 /var/lib/risingwave /etc/risingwave # 创建 SELinux 策略模块关键否则服务启动即失败 sudo semanage fcontext -a -t risingwave_exec_t /usr/local/bin/risingwave sudo restorecon -v /usr/local/bin/risingwave # 如果 semanage 不存在先安装 policycoreutils-python-utils sudo dnf install -y policycoreutils-python-utils # 创建自定义 SELinux 类型允许网络绑定和文件读写 cat risingwave.te EOF module risingwave 1.0; require { type init_t; type unconfined_service_t; class process { transition }; class capability { net_bind_service }; class file { read write execute getattr }; class dir { read write add_name remove_name }; } # 允许 risingwave_t 类型的进程绑定到网络端口 allow risingwave_t self:capability net_bind_service; # 允许 risingwave_t 读写 /var/lib/risingwave 目录 allow risingwave_t var_lib_t:dir { read write add_name remove_name }; allow risingwave_t var_lib_t:file { read write execute getattr }; # 允许从 init_t 过渡到 risingwave_tsystemd 启动时 type_transition init_t risingwave_exec_t:process risingwave_t; EOF # 编译并加载策略 sudo checkmodule -M -m -o risingwave.mod risingwave.te sudo semodule_package -o risingwave.pp -m risingwave.mod sudo semodule -i risingwave.pp提示SELinux 是 Rocky Linux 的守护神不是绊脚石。我曾遇到一个案例risingwave-meta启动后立刻退出journalctl -u risingwave-meta只显示Process exited with status 1。用ausearch -m avc -ts recent查看审计日志发现一行avc: denied { bind } for pid1234 commrisingwave src5690 scontextsystem_u:system_r:risingwave_t:s0 tcontextsystem_u:system_r:kernel_t:s0 tclasstcp_socket permissive0。这就是典型的 SELinux 拦截。没有这行日志你永远不知道问题在哪。4.3 配置资源隔离与性能调优Rocky Linux 9.6 的 cgroup v2 提供了前所未有的精细控制。在/etc/systemd/system/risingwave-meta.service的[Service]段中加入以下内容# CPU 隔离将 risingwave-meta 绑定到 CPU 0-1避免与其他服务争抢 CPUAffinity0-1 # 内存带宽限制防止它吃光所有内存带宽 MemoryBandwidthMax50% # I/O 带宽限制防止它刷爆磁盘 IOReadBandwidthMax/dev/sda 100M IOWriteBandwidthMax/dev/sda 100M # 网络优先级提升其网络包处理优先级 NetworkPriority5 # 文件描述符限制RisingWave 高并发时需要大量 fd LimitNOFILE65536 LimitNPROC65536然后启用这些配置# 重新加载 systemd 配置 sudo systemctl daemon-reload # 启用服务并开机自启 sudo systemctl enable risingwave-meta sudo systemctl enable risingwave-frontend # 启动服务 sudo systemctl start risingwave-meta sudo systemctl start risingwave-frontend # 检查状态 sudo systemctl status risingwave-meta risingwave-frontend # 应显示 active (running) # 检查 cgroup 分配 sudo cat /sys/fs/cgroup/system.slice/risingwave-meta.service/cpu.max # 输出200000 100000 表示 200% CPU quota sudo cat /sys/fs/cgroup/system.slice/risingwave-meta.service/memory.max # 输出2147483648 即 2G4.4 配置 Prometheus 监控与 Grafana 看板RisingWave 的--features prometheus会暴露/metrics端点。我们需要一个轻量级 Prometheus 实例来抓取# 安装 Prometheus sudo dnf install -y prometheus # 配置 Prometheus 抓取 risingwave sudo tee /etc/prometheus/prometheus.yml EOF global: scrape_interval: 15s scrape_configs: - job_name: risingwave-meta static_configs: - targets: [127.0.0.1:5691] # dashboard port metrics_path: /metrics - job_name: risingwave-frontend static_configs: - targets: [127.0.0.1:4566] metrics_path: /metrics - job_name: node static_configs: - targets: [127.0.0.1:9100] EOF # 启动 node_exporter系统指标 sudo systemctl enable node_exporter sudo systemctl start node_exporter # 启动 prometheus sudo systemctl enable prometheus sudo systemctl start prometheus # 验证指标是否可抓取 curl -s http://127.0.0.1:9090/api/v1/query?queryrisingwave_meta_leader_uptime_seconds | jq .data.result[0].value[1] # 应返回一个数字如 1234.56最后导入官方 Grafana 看板 ID18222RisingWave Dashboard即可获得完整的集群健康视图。这个看板不是装饰品它的Compute Node CPU Usage面板能告诉你compute-node是否因 GC 卡顿Frontend Query Latency面板能帮你定位慢查询Meta Leader Uptime面板则是 HA 是否正常的晴雨表。5. 常见故障排查从端口冲突到 Kafka 连接超时的全链路诊断安装完成不等于万事大吉。RisingWave 是一个分布式系统任何一个环节出问题都会表现为“连不上”或“查询慢”。我整理了过去半年在客户现场遇到的 Top 5 故障每一条都附带完整的诊断链路不是简单给解决方案而是教你怎么一步步找到根因。5.1 故障一“psql: error: could not connect to server: Connection refused”这是最常被问到的问题。表面看是端口没开但背后有至少5种可能。诊断必须按顺序进行Step 1确认服务进程是否存在ps aux | grep risingwave # 如果没有输出说明服务根本没起来 sudo systemctl status risingwave-frontend # 查看 Failed because... 行Step 2确认端口是否被监听sudo ss -tlnp | grep :4566 # 如果没有输出说明 risingwave-frontend 没绑定端口 # 检查日志 sudo journalctl -u risingwave-frontend -n 100 --no-pager # 常见错误 # failed to bind to 0.0.0.0:4566: Address already in use → 端口被占 # failed to connect to meta at 127.0.0.1:5690 → meta 服务没起来Step 3检查端口占用者sudo ss -tlnp sport :4566 # 如果输出类似LISTEN 0 4096 *:4566 *:* users:((java,pid1234,fd123)) # 说明是 Java 进程如 Elasticsearch占用了 4566 # 解决要么杀掉 java要么改 risingwave 配置Step 4检查防火墙sudo firewall-cmd --list-ports # 如果没有 4566/tcp添加 sudo firewall-cmd --permanent --add-port4566/tcp sudo firewall-cmd --reloadStep 5检查 SELinux 是否拦截sudo ausearch -m avc -ts recent | grep risingwave # 如果有输出说明 SELinux 拦截了 bind 操作 # 临时放行测试 sudo setsebool -P risingwave_can_network_connect on # 然后重启服务我的经验80% 的“Connection refused”都是risingwave-meta没起来导致的。frontend启动时会尝试连接meta如果连不上它