简介这份资源是面向大数据运维与Hadoop平台搭建学习者的Cloudera Manager 5.14.2离线安装包专为CentOS 7环境准备解决集群部署时组件获取困难、版本不匹配等问题适合具备一定Linux基础、希望系统掌握CDH平台管理的初中级运维人员。压缩包共18362个文件约793.9MB以py、pyo、pyc等Python运行文件与html、js、css等Web管理界面资源为主另含jar依赖包、ddl建表脚本、xml与properties配置、so动态库及sh启动脚本完整覆盖服务端与代理端运行所需。已有281人学习下载。资源内含Cloudera Manager服务器与Agent程序、内置数据库初始化脚本及Yum仓库配置读者可据此完成服务端安装、Web界面访问、集群创建与组件分发并借助监控告警、日志查看与参数调优功能管理Hadoop集群是搭建CDH实验与生产环境的实用基础包。1. 离线装 CM 5.14.2为什么我坚持先锁 CentOS 7.9 再解包上周又有人拿着一台 CentOS 7.6 的机器来问说cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz解压完启动不了日志里全是 JDK 版本和 Python 解释器的报错。这套 cloudera cm centos 组合在离线机房、内网实验环境里太常见了CM 5.14.2 是 5.x 系列最后一个稳定分支配套的 CDH 5.16 也还在不少存量集群里跑着。装不好会怎样轻则cloudera-scm-server起不来重则 agent 心跳全红、集群面板一片告警排查起来像开盲盒。这篇笔记写给两类人第一次在 CentOS 7 上离线部署 CM 的新手以及想确认版本边界和参数取舍的熟手。我按自己实际装过的那套流程走一遍从系统基线、解包、数据库、server 启动到 agent 纳管中间翻过的车也一并记下来。2. 装前把系统基线钉死CentOS 7.9 与 JDK 8 的版本取舍CM 5.14.2 这个包名里的centos7不是装饰它对应的是 RHEL 7 系的内核和 glibc 版本。我一般把系统锁在 CentOS 7.92009原因很实际7.9 是 7 系最后一个小版本systemd、firewalld、python的补丁状态最完整而 7.4 以下的内核在跑 Cloudera 的nscd、ntpd相关检查时容易报兼容性警告。别用 CentOS 8 或 StreamCM 5.14.2 的启动脚本里对systemctl的调用方式和 8 系有差异硬上就是给自己找事。2.1 系统层要提前确认的四项装之前先跑一遍基线检查这四项不过关后面全是白费# 1. 确认发行版和内核 cat /etc/redhat-release uname -r # 2. 关闭 SELinuxCM 5.x 对 enforcing 支持很差 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config # 3. 确认主机名是 FQDN且 hosts 里能解析 hostname -f cat /etc/hosts # 4. 时间同步集群节点偏差超过 5 分钟 agent 会拒绝心跳 timedatectl status第一项看的是发行版字符串必须是CentOS Linux release 7.x第二项 SELinux 我直接设成 permissiveenforcing 下 CM 的parcel分发目录权限会被拦报错信息还特别隐晦第三项hostname -f必须返回带域名的完整主机名纯短名会让 agent 注册时hostname字段对不上第四项时间同步是玄学重灾区chronyd没跑起来的话agent 日志里只会写heartbeat timeout根本看不出是时间问题。2.2 JDK 版本只认 Oracle JDK 8u 系列CM 5.14.2 官方支持的是 Oracle JDK 8我实测 8u202 到 8u311 都能跑但别用 OpenJDK 11也别用 8u 太新的版本8u341 之后有些 TLS 默认策略变化会影响 CM 的内部通信。装法# 解压 JDK 到统一目录 mkdir -p /usr/java tar -zxf jdk-8u311-linux-x64.tar.gz -C /usr/java/ # 配置全局环境变量 cat /etc/profile.d/java.sh EOF export JAVA_HOME/usr/java/jdk1.8.0_311 export PATH$JAVA_HOME/bin:$PATH EOF source /etc/profile.d/java.sh java -versionJAVA_HOME这个路径必须和实际解压出来的目录名一致jdk1.8.0_311是 Oracle 包的固定命名。我见过有人把JAVA_HOME指到/usr/java/latest软链结果 CM 的cloudera-scm-server启动脚本读不到因为脚本里用的是readlink -f解析软链在某些场景下解析结果不对。所以老老实实写绝对路径。2.3 Python 解释器2.7 是硬门槛CM 5.14.2 的 agent 和部分管理脚本是 Python 2 写的CentOS 7.9 自带python-2.7.5够用。但要注意别把系统默认python指向 Python 3否则cloudera-scm-agent启动时直接SyntaxError。确认一下python --version # 必须是 Python 2.7.x which python # 应该是 /usr/bin/python如果机器上装过 Python 3 并改了alternatives用alternatives --config python切回 2.7或者直接ln -sf /usr/bin/python2.7 /usr/bin/python。这一步看着简单但它是后面 agent 起不来的头号原因我把它放在基线里先解决。3. 解包与目录规划tar.gz 里到底该放哪cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz解出来是cm-5.14.2目录里面分cloudera和cm-5.14.2两块。很多人直接解到/opt就完事结果后面 parcel 分发路径对不上。我一般按 Cloudera 的默认约定放/opt/cm-5.14.2这样 server 和 agent 的默认配置路径都不用改。3.1 解包命令与目录结构确认# 解包到 /opt tar -zxf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt/ # 确认目录结构 ls -l /opt/cm-5.14.2/ # 应该看到 cloudera/ 和 cm-5.14.2/ 两个子目录 # 关键路径确认 ls /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/ ls /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-agent/解出来的cm-5.14.2/cm-5.14.2/etc/下是 server 和 agent 的配置模板cloudera/下是 parcel 仓库目录。这里有个容易忽略的点tar 包解压后文件属主是当前用户而 CM 服务要用cloudera-scm用户跑所以后面建用户后要统一chown。3.2 建服务用户和目录权限# 创建 cloudera-scm 用户无登录 shell useradd --system --home/opt/cm-5.14.2/run/cloudera-scm-server \ --shell/bin/false --comment Cloudera SCM User cloudera-scm # 统一属主 chown -R cloudera-scm:cloudera-scm /opt/cm-5.14.2/ # 建 parcel 仓库目录server 分发 parcel 用 mkdir -p /opt/cloudera/parcel-repo chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo--home指到run/cloudera-scm-server是因为 server 进程会在这个目录下写 pid 和临时文件如果指到/home/cloudera-scm而该目录不存在启动时会报No such file or directory。--shell/bin/false是安全习惯这个账号只用来跑服务不需要登录。parcel-repo目录是后面放 CDH parcel 包的地方权限必须给cloudera-scm否则 server 分发时写不进去。3.3 配置 server 和 agent 的关键参数server 的配置文件是/opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/db.propertiesagent 的是同级的cloudera-scm-agent/config.ini。先看 agent 这边# /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-agent/config.ini [General] # server 主机名必须和 server 的 hostname -f 一致 server_hostcm-server.example.internal # server 的 agent 通信端口默认 7182 server_port7182 # agent 监听端口 listening_port9000 # 日志目录 log_file/var/log/cloudera-scm-agent/cloudera-scm-agent.logserver_host这里填的是 server 节点的 FQDN不是 IP。用 IP 的话 agent 注册时hostname字段和 server 端记录对不上面板里会出现重复主机。server_port默认 7182 别改改了 server 端也要同步改cloudera-scm-server的config.ini两边不一致就是心跳全红。server 端的db.properties要等数据库建好再填下一章细说。这里先把 agent 的config.ini改好因为 agent 是每个节点都要配的server 节点自己也要装 agent。4. 数据库与 server 启动MySQL 5.7 建库和 db.properties 填法CM 5.14.2 的 server 需要外部数据库存元数据支持 MySQL、PostgreSQL、Oracle。我一般用 MySQL 5.7因为 CentOS 7.9 的mariadb默认版本是 5.5CM 5.14.2 对 MariaDB 5.5 的 JDBC 驱动兼容性有坑干脆装 MySQL 5.7 社区版省心。4.1 建库建用户与授权-- 建库字符集必须是 utf8 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE amon DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE rman DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE hue DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE metastore DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE nav DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE navms DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE oozie DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; -- 建用户并授权 CREATE USER scm% IDENTIFIED BY Scm_Pass_2024; GRANT ALL PRIVILEGES ON scm.* TO scm%; GRANT ALL PRIVILEGES ON amon.* TO scm%; GRANT ALL PRIVILEGES ON rman.* TO scm%; GRANT ALL PRIVILEGES ON hue.* TO scm%; GRANT ALL PRIVILEGES ON metastore.* TO scm%; GRANT ALL PRIVILEGES ON sentry.* TO scm%; GRANT ALL PRIVILEGES ON nav.* TO scm%; GRANT ALL PRIVILEGES ON navms.* TO scm%; GRANT ALL PRIVILEGES ON oozie.* TO scm%; FLUSH PRIVILEGES;scm库是 CM 自己的元数据amon是活动监控rman是报表管理hue、metastore、sentry、nav、navms、oozie是后面 CDH 服务要用的。字符集必须utf8用latin1的话中文主机名或注释会乱码CM 面板里显示成问号。用户授权用%是为了让集群其他节点也能连如果只单机可以收窄到localhost。4.2 db.properties 的填法与密码加密# /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/db.properties com.cloudera.cmf.db.typemysql com.cloudera.cmf.db.hostlocalhost com.cloudera.cmf.db.namescm com.cloudera.cmf.db.userscm com.cloudera.cmf.db.passwordScm_Pass_2024 com.cloudera.cmf.db.setupTypeEXTERNALdb.type固定mysqldb.host填数据库地址db.name是scm库setupTypeEXTERNAL表示用外部库而不是内嵌库。密码这里写明文CM 启动时会自己加密存到db.mgmt.properties不用手动处理。填完记得chown cloudera-scm:cloudera-scm这个文件权限不对 server 读不到会报Access denied。4.3 启动 server 与看日志# 启动 server /opt/cm-5.14.2/etc/init.d/cloudera-scm-server start # 实时看启动日志 tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log启动脚本在/opt/cm-5.14.2/etc/init.d/下server 和 agent 各一个。日志里看到Started Jetty server和Server started才算成功第一次启动会建表耗时一两分钟正常。如果卡在Waiting for database八成是db.properties的密码或主机名不对回去核对。启动成功后浏览器访问http://server-ip:7180默认账号密码都是admin。5. 避坑与排查agent 心跳、parcel 分发、端口冲突的翻车记录这一章是我踩过的坑里挑出来的五条每条都按现象、原因、解决写照着对号入座能省不少时间。5.1 agent 启动后 server 面板看不到主机现象agent 进程在ps -ef | grep cloudera-scm-agent有输出但 CM 面板「所有主机」里空空如也。原因agent 的config.ini里server_host填了 IP 或者短名和 server 端hostname -f的结果不一致agent 注册请求被拒。解决两边都改成 FQDN/etc/hosts里加一行192.168.x.x cm-server.example.internal cm-server然后重启 agent。我一般装完第一件事就是hostname -f对一遍省得后面来回折腾。5.2 parcel 分发卡在「正在分发」不动现象上传 CDH parcel 到/opt/cloudera/parcel-repo后面板里点分发进度条一直不动。原因parcel-repo目录属主不是cloudera-scmserver 进程没权限读 parcel 文件。解决chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo并确认.sha校验文件和 parcel 文件同名同目录。还有个隐藏原因parcel 文件名里的版本号和manifest.json对不上CM 会静默跳过看cloudera-scm-server.log里有没有parcel not found字样。5.3 7180 端口被占导致 server 起不来现象cloudera-scm-server start后日志报Address already in use。原因7180 被别的进程占了常见是之前装过旧版 CM 没清干净或者有别的 web 服务。解决ss -lntp | grep 7180找到占用进程kill掉或者改 CM 的端口。改端口要动cloudera-scm-server/config.ini里的http_port但改完 agent 那边不用动agent 走的是 7182。我一般直接清掉旧进程改端口容易漏配。5.4 MySQL 连接报「Public Key Retrieval is not allowed」现象server 启动日志里 JDBC 报这个错。原因MySQL 5.7 的caching_sha2_password认证插件和 CM 自带的 JDBC 驱动不兼容。解决建用户时用mysql_native_password或者改用户认证方式ALTER USER scm% IDENTIFIED WITH mysql_native_password BY Scm_Pass_2024;。这个坑在 MySQL 8 上更常见5.7 默认还是native_password但如果装的时候改过默认插件就会中招。5.5 agent 日志刷「heartbeat timeout」但网络是通的现象agent 日志每隔几十秒刷一次心跳超时ping和telnet 7182都通。原因节点时间偏差超过 5 分钟agent 的心跳包时间戳被 server 判定为过期。解决chronyc sources -v看时间源systemctl restart chronyd强制同步timedatectl set-ntp true确保开机自启。这条最玄学因为网络层完全正常只有看 agent 日志里的时间戳和 server 对比才能发现。6. 装完怎么验证从 7180 面板到 agent 心跳的完整检查链装完不是看到登录页就完事我一般走一遍完整检查链确认 server、数据库、agent、parcel 四层都通。先看 server 进程和端口# server 进程和端口 ps -ef | grep cloudera-scm-server | grep -v grep ss -lntp | grep -E 7180|7182 # 数据库连接数确认 server 真的连上了 MySQL mysql -uscm -p -e SHOW PROCESSLIST; | grep scm7180是 web 端口7182是 agent 通信端口两个都在监听才说明 server 完整启动。数据库PROCESSLIST里能看到scm用户的连接说明db.properties生效了。然后验证 agent 心跳这是最容易漏的一步# agent 进程 ps -ef | grep cloudera-scm-agent | grep -v grep # agent 日志里找心跳成功记录 grep -i heartbeat /var/log/cloudera-scm-agent/cloudera-scm-agent.log | tail -5日志里出现Heartbeat successful或者Received heartbeat response才算 agent 真正纳管成功。只有进程在但没心跳回去查第 5.1 和 5.5 两条。最后在面板里做三项确认我列成表方便对照检查项位置通过标准主机列表主页 → 所有主机所有节点状态为「良好」无红色告警Parcel 状态主机 → ParcelCDH parcel 显示「已分配」且「已激活」服务健康主页 → 集群已装服务无「不良」标记配置检查全绿三项全过这套 CM 5.14.2 就算装稳了。我还会额外跑一次cloudera-scm-server db的连通性检查确认元数据库没有隐性问题# 用 CM 自带脚本检查数据库连接 /opt/cm-5.14.2/cm-5.14.2/share/cmf/schema/scm_prepare_database.sh \ mysql -h localhost -u scm -p scm这个脚本本来是初始化数据库用的已经初始化过再跑会提示库已存在但只要不报连接错误就说明 JDBC 链路是通的。看到Verifying database connectivity后面跟successful就放心了。从那以后我每次装完 CM都强制走一遍「端口 → 进程 → 心跳 → 面板」这条链不看到 agent 日志里的心跳成功记录不算完。这套流程看着笨但比事后在面板里对着红点猜要快得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 18:14:08 · 阅读 1.2k CentOS 7.9 离线部署 CM 5.14.2 全流程与避坑指南
简介这份资源是面向大数据运维与Hadoop平台搭建学习者的Cloudera Manager 5.14.2离线安装包专为CentOS 7环境准备解决集群部署时组件获取困难、版本不匹配等问题适合具备一定Linux基础、希望系统掌握CDH平台管理的初中级运维人员。压缩包共18362个文件约793.9MB以py、pyo、pyc等Python运行文件与html、js、css等Web管理界面资源为主另含jar依赖包、ddl建表脚本、xml与properties配置、so动态库及sh启动脚本完整覆盖服务端与代理端运行所需。已有281人学习下载。资源内含Cloudera Manager服务器与Agent程序、内置数据库初始化脚本及Yum仓库配置读者可据此完成服务端安装、Web界面访问、集群创建与组件分发并借助监控告警、日志查看与参数调优功能管理Hadoop集群是搭建CDH实验与生产环境的实用基础包。1. 离线装 CM 5.14.2为什么我坚持先锁 CentOS 7.9 再解包上周又有人拿着一台 CentOS 7.6 的机器来问说cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz解压完启动不了日志里全是 JDK 版本和 Python 解释器的报错。这套 cloudera cm centos 组合在离线机房、内网实验环境里太常见了CM 5.14.2 是 5.x 系列最后一个稳定分支配套的 CDH 5.16 也还在不少存量集群里跑着。装不好会怎样轻则cloudera-scm-server起不来重则 agent 心跳全红、集群面板一片告警排查起来像开盲盒。这篇笔记写给两类人第一次在 CentOS 7 上离线部署 CM 的新手以及想确认版本边界和参数取舍的熟手。我按自己实际装过的那套流程走一遍从系统基线、解包、数据库、server 启动到 agent 纳管中间翻过的车也一并记下来。2. 装前把系统基线钉死CentOS 7.9 与 JDK 8 的版本取舍CM 5.14.2 这个包名里的centos7不是装饰它对应的是 RHEL 7 系的内核和 glibc 版本。我一般把系统锁在 CentOS 7.92009原因很实际7.9 是 7 系最后一个小版本systemd、firewalld、python的补丁状态最完整而 7.4 以下的内核在跑 Cloudera 的nscd、ntpd相关检查时容易报兼容性警告。别用 CentOS 8 或 StreamCM 5.14.2 的启动脚本里对systemctl的调用方式和 8 系有差异硬上就是给自己找事。2.1 系统层要提前确认的四项装之前先跑一遍基线检查这四项不过关后面全是白费# 1. 确认发行版和内核 cat /etc/redhat-release uname -r # 2. 关闭 SELinuxCM 5.x 对 enforcing 支持很差 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config # 3. 确认主机名是 FQDN且 hosts 里能解析 hostname -f cat /etc/hosts # 4. 时间同步集群节点偏差超过 5 分钟 agent 会拒绝心跳 timedatectl status第一项看的是发行版字符串必须是CentOS Linux release 7.x第二项 SELinux 我直接设成 permissiveenforcing 下 CM 的parcel分发目录权限会被拦报错信息还特别隐晦第三项hostname -f必须返回带域名的完整主机名纯短名会让 agent 注册时hostname字段对不上第四项时间同步是玄学重灾区chronyd没跑起来的话agent 日志里只会写heartbeat timeout根本看不出是时间问题。2.2 JDK 版本只认 Oracle JDK 8u 系列CM 5.14.2 官方支持的是 Oracle JDK 8我实测 8u202 到 8u311 都能跑但别用 OpenJDK 11也别用 8u 太新的版本8u341 之后有些 TLS 默认策略变化会影响 CM 的内部通信。装法# 解压 JDK 到统一目录 mkdir -p /usr/java tar -zxf jdk-8u311-linux-x64.tar.gz -C /usr/java/ # 配置全局环境变量 cat /etc/profile.d/java.sh EOF export JAVA_HOME/usr/java/jdk1.8.0_311 export PATH$JAVA_HOME/bin:$PATH EOF source /etc/profile.d/java.sh java -versionJAVA_HOME这个路径必须和实际解压出来的目录名一致jdk1.8.0_311是 Oracle 包的固定命名。我见过有人把JAVA_HOME指到/usr/java/latest软链结果 CM 的cloudera-scm-server启动脚本读不到因为脚本里用的是readlink -f解析软链在某些场景下解析结果不对。所以老老实实写绝对路径。2.3 Python 解释器2.7 是硬门槛CM 5.14.2 的 agent 和部分管理脚本是 Python 2 写的CentOS 7.9 自带python-2.7.5够用。但要注意别把系统默认python指向 Python 3否则cloudera-scm-agent启动时直接SyntaxError。确认一下python --version # 必须是 Python 2.7.x which python # 应该是 /usr/bin/python如果机器上装过 Python 3 并改了alternatives用alternatives --config python切回 2.7或者直接ln -sf /usr/bin/python2.7 /usr/bin/python。这一步看着简单但它是后面 agent 起不来的头号原因我把它放在基线里先解决。3. 解包与目录规划tar.gz 里到底该放哪cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz解出来是cm-5.14.2目录里面分cloudera和cm-5.14.2两块。很多人直接解到/opt就完事结果后面 parcel 分发路径对不上。我一般按 Cloudera 的默认约定放/opt/cm-5.14.2这样 server 和 agent 的默认配置路径都不用改。3.1 解包命令与目录结构确认# 解包到 /opt tar -zxf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt/ # 确认目录结构 ls -l /opt/cm-5.14.2/ # 应该看到 cloudera/ 和 cm-5.14.2/ 两个子目录 # 关键路径确认 ls /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/ ls /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-agent/解出来的cm-5.14.2/cm-5.14.2/etc/下是 server 和 agent 的配置模板cloudera/下是 parcel 仓库目录。这里有个容易忽略的点tar 包解压后文件属主是当前用户而 CM 服务要用cloudera-scm用户跑所以后面建用户后要统一chown。3.2 建服务用户和目录权限# 创建 cloudera-scm 用户无登录 shell useradd --system --home/opt/cm-5.14.2/run/cloudera-scm-server \ --shell/bin/false --comment Cloudera SCM User cloudera-scm # 统一属主 chown -R cloudera-scm:cloudera-scm /opt/cm-5.14.2/ # 建 parcel 仓库目录server 分发 parcel 用 mkdir -p /opt/cloudera/parcel-repo chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo--home指到run/cloudera-scm-server是因为 server 进程会在这个目录下写 pid 和临时文件如果指到/home/cloudera-scm而该目录不存在启动时会报No such file or directory。--shell/bin/false是安全习惯这个账号只用来跑服务不需要登录。parcel-repo目录是后面放 CDH parcel 包的地方权限必须给cloudera-scm否则 server 分发时写不进去。3.3 配置 server 和 agent 的关键参数server 的配置文件是/opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/db.propertiesagent 的是同级的cloudera-scm-agent/config.ini。先看 agent 这边# /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-agent/config.ini [General] # server 主机名必须和 server 的 hostname -f 一致 server_hostcm-server.example.internal # server 的 agent 通信端口默认 7182 server_port7182 # agent 监听端口 listening_port9000 # 日志目录 log_file/var/log/cloudera-scm-agent/cloudera-scm-agent.logserver_host这里填的是 server 节点的 FQDN不是 IP。用 IP 的话 agent 注册时hostname字段和 server 端记录对不上面板里会出现重复主机。server_port默认 7182 别改改了 server 端也要同步改cloudera-scm-server的config.ini两边不一致就是心跳全红。server 端的db.properties要等数据库建好再填下一章细说。这里先把 agent 的config.ini改好因为 agent 是每个节点都要配的server 节点自己也要装 agent。4. 数据库与 server 启动MySQL 5.7 建库和 db.properties 填法CM 5.14.2 的 server 需要外部数据库存元数据支持 MySQL、PostgreSQL、Oracle。我一般用 MySQL 5.7因为 CentOS 7.9 的mariadb默认版本是 5.5CM 5.14.2 对 MariaDB 5.5 的 JDBC 驱动兼容性有坑干脆装 MySQL 5.7 社区版省心。4.1 建库建用户与授权-- 建库字符集必须是 utf8 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE amon DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE rman DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE hue DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE metastore DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE nav DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE navms DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE oozie DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; -- 建用户并授权 CREATE USER scm% IDENTIFIED BY Scm_Pass_2024; GRANT ALL PRIVILEGES ON scm.* TO scm%; GRANT ALL PRIVILEGES ON amon.* TO scm%; GRANT ALL PRIVILEGES ON rman.* TO scm%; GRANT ALL PRIVILEGES ON hue.* TO scm%; GRANT ALL PRIVILEGES ON metastore.* TO scm%; GRANT ALL PRIVILEGES ON sentry.* TO scm%; GRANT ALL PRIVILEGES ON nav.* TO scm%; GRANT ALL PRIVILEGES ON navms.* TO scm%; GRANT ALL PRIVILEGES ON oozie.* TO scm%; FLUSH PRIVILEGES;scm库是 CM 自己的元数据amon是活动监控rman是报表管理hue、metastore、sentry、nav、navms、oozie是后面 CDH 服务要用的。字符集必须utf8用latin1的话中文主机名或注释会乱码CM 面板里显示成问号。用户授权用%是为了让集群其他节点也能连如果只单机可以收窄到localhost。4.2 db.properties 的填法与密码加密# /opt/cm-5.14.2/cm-5.14.2/etc/cloudera-scm-server/db.properties com.cloudera.cmf.db.typemysql com.cloudera.cmf.db.hostlocalhost com.cloudera.cmf.db.namescm com.cloudera.cmf.db.userscm com.cloudera.cmf.db.passwordScm_Pass_2024 com.cloudera.cmf.db.setupTypeEXTERNALdb.type固定mysqldb.host填数据库地址db.name是scm库setupTypeEXTERNAL表示用外部库而不是内嵌库。密码这里写明文CM 启动时会自己加密存到db.mgmt.properties不用手动处理。填完记得chown cloudera-scm:cloudera-scm这个文件权限不对 server 读不到会报Access denied。4.3 启动 server 与看日志# 启动 server /opt/cm-5.14.2/etc/init.d/cloudera-scm-server start # 实时看启动日志 tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log启动脚本在/opt/cm-5.14.2/etc/init.d/下server 和 agent 各一个。日志里看到Started Jetty server和Server started才算成功第一次启动会建表耗时一两分钟正常。如果卡在Waiting for database八成是db.properties的密码或主机名不对回去核对。启动成功后浏览器访问http://server-ip:7180默认账号密码都是admin。5. 避坑与排查agent 心跳、parcel 分发、端口冲突的翻车记录这一章是我踩过的坑里挑出来的五条每条都按现象、原因、解决写照着对号入座能省不少时间。5.1 agent 启动后 server 面板看不到主机现象agent 进程在ps -ef | grep cloudera-scm-agent有输出但 CM 面板「所有主机」里空空如也。原因agent 的config.ini里server_host填了 IP 或者短名和 server 端hostname -f的结果不一致agent 注册请求被拒。解决两边都改成 FQDN/etc/hosts里加一行192.168.x.x cm-server.example.internal cm-server然后重启 agent。我一般装完第一件事就是hostname -f对一遍省得后面来回折腾。5.2 parcel 分发卡在「正在分发」不动现象上传 CDH parcel 到/opt/cloudera/parcel-repo后面板里点分发进度条一直不动。原因parcel-repo目录属主不是cloudera-scmserver 进程没权限读 parcel 文件。解决chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo并确认.sha校验文件和 parcel 文件同名同目录。还有个隐藏原因parcel 文件名里的版本号和manifest.json对不上CM 会静默跳过看cloudera-scm-server.log里有没有parcel not found字样。5.3 7180 端口被占导致 server 起不来现象cloudera-scm-server start后日志报Address already in use。原因7180 被别的进程占了常见是之前装过旧版 CM 没清干净或者有别的 web 服务。解决ss -lntp | grep 7180找到占用进程kill掉或者改 CM 的端口。改端口要动cloudera-scm-server/config.ini里的http_port但改完 agent 那边不用动agent 走的是 7182。我一般直接清掉旧进程改端口容易漏配。5.4 MySQL 连接报「Public Key Retrieval is not allowed」现象server 启动日志里 JDBC 报这个错。原因MySQL 5.7 的caching_sha2_password认证插件和 CM 自带的 JDBC 驱动不兼容。解决建用户时用mysql_native_password或者改用户认证方式ALTER USER scm% IDENTIFIED WITH mysql_native_password BY Scm_Pass_2024;。这个坑在 MySQL 8 上更常见5.7 默认还是native_password但如果装的时候改过默认插件就会中招。5.5 agent 日志刷「heartbeat timeout」但网络是通的现象agent 日志每隔几十秒刷一次心跳超时ping和telnet 7182都通。原因节点时间偏差超过 5 分钟agent 的心跳包时间戳被 server 判定为过期。解决chronyc sources -v看时间源systemctl restart chronyd强制同步timedatectl set-ntp true确保开机自启。这条最玄学因为网络层完全正常只有看 agent 日志里的时间戳和 server 对比才能发现。6. 装完怎么验证从 7180 面板到 agent 心跳的完整检查链装完不是看到登录页就完事我一般走一遍完整检查链确认 server、数据库、agent、parcel 四层都通。先看 server 进程和端口# server 进程和端口 ps -ef | grep cloudera-scm-server | grep -v grep ss -lntp | grep -E 7180|7182 # 数据库连接数确认 server 真的连上了 MySQL mysql -uscm -p -e SHOW PROCESSLIST; | grep scm7180是 web 端口7182是 agent 通信端口两个都在监听才说明 server 完整启动。数据库PROCESSLIST里能看到scm用户的连接说明db.properties生效了。然后验证 agent 心跳这是最容易漏的一步# agent 进程 ps -ef | grep cloudera-scm-agent | grep -v grep # agent 日志里找心跳成功记录 grep -i heartbeat /var/log/cloudera-scm-agent/cloudera-scm-agent.log | tail -5日志里出现Heartbeat successful或者Received heartbeat response才算 agent 真正纳管成功。只有进程在但没心跳回去查第 5.1 和 5.5 两条。最后在面板里做三项确认我列成表方便对照检查项位置通过标准主机列表主页 → 所有主机所有节点状态为「良好」无红色告警Parcel 状态主机 → ParcelCDH parcel 显示「已分配」且「已激活」服务健康主页 → 集群已装服务无「不良」标记配置检查全绿三项全过这套 CM 5.14.2 就算装稳了。我还会额外跑一次cloudera-scm-server db的连通性检查确认元数据库没有隐性问题# 用 CM 自带脚本检查数据库连接 /opt/cm-5.14.2/cm-5.14.2/share/cmf/schema/scm_prepare_database.sh \ mysql -h localhost -u scm -p scm这个脚本本来是初始化数据库用的已经初始化过再跑会提示库已存在但只要不报连接错误就说明 JDBC 链路是通的。看到Verifying database connectivity后面跟successful就放心了。从那以后我每次装完 CM都强制走一遍「端口 → 进程 → 心跳 → 面板」这条链不看到 agent 日志里的心跳成功记录不算完。这套流程看着笨但比事后在面板里对着红点猜要快得多。希望帮到你。本文还有配套的精品资源点击获取