企业官网建设流程全解析

1. 元数据库迁移这件事，为什么值得单独拎出来讲

做过大数据平台运维的人都有一个共识：集群里最不敢乱动的东西，不是计算引擎的配置，也不是存储层的目录结构，而是那个藏在后台、默默支撑着所有元数据读写的关系型数据库。Cloudera Manager（后面统一简称 CM）和 CDH 这套体系里，元数据库的角色尤其特殊——它既是平台自身管理的"账本"，又是 Hive、Hue、Oozie、Sentry 等一众组件的"公共档案室"。一旦这个库要换地方，牵动的不是一两个服务，而是整条数据链路。

我之所以想把这个话题单独拿出来写一篇，是因为在实际工作中，"修改迁移元数据库"这个需求出现的频率远比想象中高。常见场景包括：原数据库所在主机磁盘告警需要整体搬迁、数据库版本升级要求换实例、机房调整导致网络拓扑变化、安全合规要求数据库独立部署、甚至只是当初测试环境凑合用的库现在要换成正式环境。这些场景背后都有一个共同点——你不能简单地改个连接串就完事，因为元数据库里存的不只是配置，还有大量带状态的数据和组件间的引用关系。

这篇文章面向的是有一定 Linux 和数据库基础、正在维护或准备维护 CM/CDH 集群的运维和开发人员。我会把整个迁移过程拆成"想清楚为什么"和"具体怎么做"两条线，既讲操作步骤，也讲每一步背后的逻辑。因为我自己踩过的坑告诉我，照着文档点下一步的人，往往会在某个不起眼的环节卡住，而卡住的原因通常不是操作错了，而是没理解这一步在干什么。

需要提前说明的是，CM 和 CDH 的版本差异会直接影响操作细节。本文讨论的思路适用于大多数 6.x 及相近版本，具体命令和界面位置请以你实际环境的版本文档为准。另外，迁移前请务必确认你有完整的备份和回滚方案，这一点后面会专门展开。

2. 先搞清楚要迁移的到底是哪些库

很多人一上来就问"怎么改数据库地址"，但更关键的问题是：你到底要迁移几个库？CM 和 CDH 体系里，元数据库并不是一个单一的概念，而是至少涉及以下几类：

2.1 CM 自身的元数据库（cm 库）

这是 Cloudera Manager Server 用来存储集群配置、服务状态、主机信息、审计日志、用户与角色等数据的库。默认情况下，它可能叫cm、scm或者你自定义的名字。这个库的特点是：CM Server 启动时就必须能连上它，连不上整个管理界面都起不来。所以它的迁移必须和 CM Server 的停机、配置修改、重启严格配合。

2.2 Hive Metastore 的元数据库（hive 库）

这是 Hive 用来存储表结构、分区信息、列类型、存储位置等元数据的库。它和 CM 的库是独立的，但通常部署在同一台数据库主机上。Hive Metastore 服务（HMS）通过 JDBC 连接这个库，HiveServer2、Spark、Impala 等组件又通过 HMS 间接依赖它。这个库一旦不可用，所有基于 Hive 元数据的查询都会失败，但已经缓存的查询可能还能撑一会儿。

2.3 Oozie、Hue、Sentry 等组件的元数据库

Oozie 需要自己的库来存工作流定义和调度状态；Hue 需要库存用户配置、查询历史、Saved Query；Sentry 需要库存权限策略。这些库通常和 Hive 库放在同一个数据库实例里，但库名和账号各不相同。迁移时如果只迁了 Hive 库而漏了 Oozie 库，就会出现"表能查但工作流跑不了"的诡异现象。

2.4 数据库类型与版本的一致性

迁移不只是换主机，还可能涉及数据库类型的变化，比如从 MySQL 5.7 换到 MySQL 8.0，或者从 MySQL 换到 PostgreSQL。不同数据库类型之间的迁移，语法兼容性和驱动版本都是坑。即使同为 MySQL，大版本升级也可能导致认证插件、字符集、SQL 模式的变化，进而影响 CM 和 CDH 组件的连接。

我建议在动手之前，先做一张清单，把所有依赖数据库的组件列出来，标注每个组件用的库名、账号、连接方式（JDBC URL 格式）、以及是否有特殊配置。这张清单会成为你后续操作的路线图。

提示：库名和账号在不同环境中可能被自定义过，不要假设默认值。用SHOW DATABASES;和 CM 界面里的数据库连接配置交叉验证。

3. 迁移前的准备工作：备份不是可选项

我见过太多人因为"就改个地址，应该很快"而跳过备份，结果在字符集不兼容或者权限没配好时陷入被动。元数据库迁移的备份，至少要覆盖三个层面：数据备份、配置备份、回滚方案。

3.1 数据层面的备份

对每个要迁移的库，用数据库自带的工具做逻辑备份。以 MySQL 为例，mysqldump是最直接的选择：

mysqldump -u root -p --single-transaction --routines --triggers \ --databases cm hive oozie hue sentry > /backup/meta_all_$(date +%Y%m%d).sql

这里有几个参数值得解释：--single-transaction保证 InnoDB 表在备份时的一致性快照，避免锁表；--routines和--triggers确保存储过程和触发器也被导出，有些环境里 CM 或 Hive 会用到；--databases后面跟多个库名，一次性导出。

如果你用的是 PostgreSQL，对应的是pg_dump，注意要分别对每个库执行，因为pg_dump不支持一次导出多个库。

3.2 配置层面的备份

CM 的数据库连接配置存在两个地方：一是 CM Server 的配置文件（通常是/etc/cloudera-scm-server/db.properties），二是 CM 数据库里的配置项。迁移前把这两个地方都备份下来，尤其是db.properties，因为 CM Server 启动时优先读这个文件。

cp /etc/cloudera-scm-server/db.properties /backup/db.properties.bak

同时，把 CM 界面里各个服务的数据库连接配置截图或导出。Hive、Oozie、Hue、Sentry 的数据库配置通常在 CM 的对应服务页面里，迁移后需要逐一修改。

3.3 回滚方案的确认

回滚方案不是"如果失败了就恢复备份"这么简单。你需要明确：回滚的时间窗口是多久？回滚时原数据库是否还能访问？如果原数据库已经下线，回滚意味着什么？我的建议是，在迁移完成并稳定运行至少一个完整业务周期之前，原数据库不要删除，只做只读保留。这样一旦新库出现问题，可以快速切回。

另外，CM 的 Agent 和 Server 之间有心跳机制，如果迁移过程中 CM Server 长时间不可用，Agent 可能会进入异常状态。所以迁移操作最好安排在业务低峰期，并且尽量缩短 CM Server 的停机时间。

4. CM 元数据库迁移的完整操作链路

这一部分我们聚焦 CM 自身的元数据库迁移。之所以把它单独拎出来，是因为 CM 的迁移和其他组件有一个本质区别：CM Server 是管理其他所有组件的入口，它的数据库连不上，你连改其他组件配置的界面都进不去。所以 CM 的迁移必须最先做，而且要做稳。

4.1 停服务的顺序不能乱

正确的停机顺序是：先停 CDH 集群里的各个服务（通过 CM 界面操作），再停 Cloudera Management Service，最后停 CM Server 本身。为什么要这个顺序？因为如果先停 CM Server，Agent 会失去管理端，集群里正在运行的任务可能处于无人监管的状态，日志和状态也无法正常上报。

具体操作上，可以在 CM 界面里选择"停止"整个集群，等待所有服务进入停止状态。然后通过命令行停 CM Server：

systemctl stop cloudera-scm-server systemctl stop cloudera-scm-agent

注意 Agent 也要停，因为 Agent 会缓存一些与 Server 的连接信息，迁移后需要重新建立连接。

4.2 在新数据库上创建库和账号

在新数据库主机上，按照原库的字符集和排序规则创建同名库。字符集这一点特别重要，如果原库是utf8而新库默认是latin1，导入数据后会出现中文乱码，而且这种问题往往在迁移完成后才暴露。

CREATE DATABASE cm DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE USER 'cmuser'@'%' IDENTIFIED BY 'your_password'; GRANT ALL PRIVILEGES ON cm.* TO 'cmuser'@'%'; FLUSH PRIVILEGES;

账号的权限范围也要注意。有些环境里 CM 的数据库账号需要CREATE、ALTER、DROP、INDEX等权限，因为 CM Server 启动时可能会执行 schema 升级脚本。如果权限不足，CM Server 会启动失败并报出具体的 SQL 错误。

4.3 导入数据并校验

把之前备份的 SQL 文件导入新库：

mysql -u root -p cm < /backup/cm_backup.sql

导入完成后，不要急着改配置，先做一次数据校验。最简单的办法是对比关键表的行数：

SELECT COUNT(*) FROM cm.CM_VERSION; SELECT COUNT(*) FROM cm.HOSTS; SELECT COUNT(*) FROM cm.SERVICES;

如果行数和原库一致，说明数据导入基本完整。但行数一致不代表数据没问题，还要检查字符集相关的字段是否有乱码，比如服务名称、主机名称、用户名称这些包含中文或特殊字符的字段。

4.4 修改 CM Server 的数据库配置

CM Server 的数据库连接信息在/etc/cloudera-scm-server/db.properties文件里。需要修改的关键项包括：

com.cloudera.cmf.db.host=新数据库主机IP com.cloudera.cmf.db.name=cm com.cloudera.cmf.db.user=cmuser com.cloudera.cmf.db.password=your_password com.cloudera.cmf.db.type=mysql com.cloudera.cmf.db.port=3306

这里有一个容易被忽略的点：com.cloudera.cmf.db.type的值必须和实际数据库类型匹配，MySQL 写mysql，PostgreSQL 写postgresql。如果写错了，CM Server 启动时会报驱动加载失败。

另外，如果新数据库的端口不是默认的 3306，一定要显式指定端口。有些环境为了安全会把数据库端口改成非标准端口，迁移时如果忘了改这个配置，CM Server 会一直尝试连接默认端口然后超时。

4.5 启动 CM Server 并验证

配置改完后，按相反顺序启动：先启动 CM Server，再启动 Agent，最后通过 CM 界面启动各个服务。

systemctl start cloudera-scm-server tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log

启动过程中要盯着日志看，重点观察是否有数据库连接失败、schema 版本不匹配、权限不足等错误。CM Server 启动通常需要一到两分钟，如果超过五分钟还没起来，基本可以判断有问题。

启动成功后，登录 CM 界面，检查集群状态是否正常，各个服务的健康检查是否通过。如果一切正常，再启动 CDH 集群的服务。

注意：CM Server 启动时可能会自动执行数据库 schema 升级。如果新库的版本比 CM Server 期望的版本低，升级过程可能会修改表结构。所以迁移前确认新库的 schema 版本和原库一致，避免升级过程中出现意外。

5. Hive Metastore 及其他组件库的迁移要点

CM 的库迁移完成后，接下来是 Hive Metastore 和其他组件的库。这部分的操作逻辑和 CM 类似，但有几个特殊之处需要单独说明。

5.1 Hive Metastore 的配置位置

Hive Metastore 的数据库配置在 CM 界面里，路径是"Hive 服务 -> 配置 -> 数据库"部分。需要修改的项包括数据库主机、数据库名称、用户名、密码。修改后需要重启 Hive 服务。

但这里有一个坑：Hive Metastore 的配置在 CM 数据库里也有一份副本。如果你是通过 CM 界面修改的，CM 会自动同步到数据库；但如果你是直接改配置文件，CM 界面可能显示的还是旧值，导致下次重启时配置被覆盖。所以统一通过 CM 界面修改是最稳妥的方式。

5.2 Oozie 和 Hue 的库迁移

Oozie 的数据库配置在 Oozie 服务的配置页面里，修改后需要重启 Oozie。Hue 的数据库配置在 Hue 服务的配置页面里，修改后需要重启 Hue。

这两个组件的库迁移相对简单，但要注意：Oozie 的工作流定义和调度状态存在数据库里，如果迁移过程中数据丢失，正在运行的工作流会中断。所以迁移前最好确认没有正在运行的关键工作流，或者等它们执行完再操作。

5.3 Sentry 的库迁移

Sentry 的数据库配置在 Sentry 服务的配置页面里。Sentry 的库相对较小，但权限策略数据很重要。迁移后需要验证权限是否生效，可以通过 Hive 或 Impala 执行一个需要权限校验的查询来测试。

5.4 组件间的依赖顺序

迁移多个组件的库时，建议的顺序是：先 CM，再 Hive Metastore，然后 Oozie、Hue、Sentry。这个顺序的原因是：CM 是管理入口，Hive Metastore 是数据查询的基础，其他组件依赖这两者。如果先迁 Oozie 而 Hive 还没迁好，Oozie 的工作流可能因为找不到 Hive 表而失败。

6. 迁移后必做的验证与常见问题排查

迁移完成不等于万事大吉。我自己的经验是，迁移后的问题往往在几天后才暴露，而且症状和原因之间的关联不明显。所以有一套系统的验证方法很重要。

6.1 基础连通性验证

先确认各个组件能正常连接新数据库。可以通过 CM 界面查看服务状态，也可以直接登录数据库主机，用组件对应的账号测试连接：

mysql -h 新数据库主机 -u hiveuser -p -e "SELECT 1;"

如果连接失败，检查网络连通性、防火墙规则、数据库账号的 host 限制（比如'hiveuser'@'%'和'hiveuser'@'具体IP'的区别）。

6.2 功能层面的验证

基础连通性没问题后，做功能验证：

• Hive：执行SHOW DATABASES;和SHOW TABLES;，确认元数据完整。
• Impala：执行INVALIDATE METADATA;后查询一张表，确认能正常读取。
• Oozie：提交一个简单的工作流，确认能正常调度。
• Hue：登录后检查查询历史、Saved Query 是否还在。
• Sentry：用一个受限账号执行查询，确认权限策略生效。

6.3 常见问题与排查思路

问题一：CM Server 启动失败，日志报 "Access denied for user"。这通常是账号权限或密码错误。检查db.properties里的用户名密码，以及数据库里该账号的授权范围。注意密码中如果有特殊字符，在 properties 文件里可能需要转义。

问题二：Hive 查询报 "MetaException" 或 "Unable to connect to metastore"。先检查 HMS 服务是否正常启动，再检查 HMS 的数据库连接配置。如果 HMS 能启动但查询失败，可能是元数据里的存储位置路径在新环境下不可访问。

问题三：中文乱码。这是字符集不一致的典型症状。检查新库的字符集设置，以及导入时是否指定了正确的字符集。如果已经导入且出现乱码，可能需要重新导入并指定--default-character-set=utf8。

问题四：Oozie 工作流卡在 RUNNING 状态。可能是 Oozie 数据库里的调度状态和实际执行状态不一致。检查 Oozie 日志，必要时清理僵尸工作流。

问题五：CM 界面显示的服务状态和实际不符。这通常是 Agent 和 Server 之间的心跳问题。重启 Agent 通常能解决，如果不行，检查 Agent 的配置文件里 Server 地址是否正确。

提示：迁移后建议保留原数据库至少一周，并且每天对比一次关键表的行数和更新时间。如果发现新库的数据没有正常更新，说明某个组件的写入路径还有问题。

7. 一些值得记住的经验和教训

聊完了操作层面的东西，我想分享几个在实际迁移中总结出来的经验，这些在官方文档里通常不会写，但往往决定了迁移的顺利程度。

第一，数据库连接池的配置要同步调整。CM 和 CDH 组件大多使用连接池来管理数据库连接。迁移后如果新数据库的最大连接数比原库小，或者网络延迟比原库高，连接池可能会出现获取连接超时的情况。建议迁移后观察一段时间各组件的日志，看是否有连接池相关的警告。

第二，时间同步很重要。数据库主机和集群主机之间的时间差如果超过一定阈值，可能会导致认证失败或数据不一致。迁移前确认所有主机都配置了时间同步服务。

第三，不要忽视数据库的 max_allowed_packet 参数。CM 和 Hive 在某些操作中会写入较大的数据包，如果新库的max_allowed_packet设置过小，会导致写入失败。建议新库的这个参数不低于原库的设置。

第四，迁移脚本要可重复执行。如果你管理的不止一个集群，建议把迁移过程脚本化，包括备份、创建库、导入、改配置、启动验证等步骤。这样下次再遇到类似需求时，可以直接复用，减少人为失误。

第五，文档记录要详细。记录下原库的版本、字符集、关键参数、迁移时间、遇到的问题和解决办法。这些信息在后续排查问题或再次迁移时非常有价值。

最后说一个我自己的习惯：每次做这类迁移，我都会在操作前画一张简单的依赖关系图，标出各个组件和数据库之间的连接关系，以及停机和启动的顺序。这张图不需要很正式，手画就行，但能帮我在操作时保持清晰的思路，避免漏掉某个环节。迁移这件事，技术难度其实不算特别高，真正考验的是细致和耐心。把每一步想清楚，把每个可能出问题的地方提前准备好应对方案，基本上就能平稳落地。