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 QuerySentry 需要库存权限策略。这些库通常和 Hive 库放在同一个数据库实例里但库名和账号各不相同。迁移时如果只迁了 Hive 库而漏了 Oozie 库就会出现表能查但工作流跑不了的诡异现象。2.4 数据库类型与版本的一致性迁移不只是换主机还可能涉及数据库类型的变化比如从 MySQL 5.7 换到 MySQL 8.0或者从 MySQL 换到 PostgreSQL。不同数据库类型之间的迁移语法兼容性和驱动版本都是坑。即使同为 MySQL大版本升级也可能导致认证插件、字符集、SQL 模式的变化进而影响 CM 和 CDH 组件的连接。我建议在动手之前先做一张清单把所有依赖数据库的组件列出来标注每个组件用的库名、账号、连接方式JDBC URL 格式、以及是否有特殊配置。这张清单会成为你后续操作的路线图。组件默认库名连接方迁移影响Cloudera Manager Servercm/scmCM Server管理界面无法启动Hive MetastorehiveHMS所有 Hive 查询失败OozieoozieOozie Server工作流调度中断HuehueHue Server用户配置和历史丢失SentrysentrySentry Server权限校验异常提示库名和账号在不同环境中可能被自定义过不要假设默认值。用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 ServerAgent 会失去管理端集群里正在运行的任务可能处于无人监管的状态日志和状态也无法正常上报。具体操作上可以在 CM 界面里选择停止整个集群等待所有服务进入停止状态。然后通过命令行停 CM Serversystemctl 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.namecm com.cloudera.cmf.db.usercmuser com.cloudera.cmf.db.passwordyour_password com.cloudera.cmf.db.typemysql com.cloudera.cmf.db.port3306这里有一个容易被忽略的点com.cloudera.cmf.db.type的值必须和实际数据库类型匹配MySQL 写mysqlPostgreSQL 写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 表而失败。迁移顺序组件原因1Cloudera Manager管理入口必须先恢复2Hive Metastore数据查询基础3Oozie依赖 Hive 元数据4Hue依赖 Hive 和 Oozie5Sentry权限校验相对独立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-setutf8。问题四Oozie 工作流卡在 RUNNING 状态。可能是 Oozie 数据库里的调度状态和实际执行状态不一致。检查 Oozie 日志必要时清理僵尸工作流。问题五CM 界面显示的服务状态和实际不符。这通常是 Agent 和 Server 之间的心跳问题。重启 Agent 通常能解决如果不行检查 Agent 的配置文件里 Server 地址是否正确。提示迁移后建议保留原数据库至少一周并且每天对比一次关键表的行数和更新时间。如果发现新库的数据没有正常更新说明某个组件的写入路径还有问题。7. 一些值得记住的经验和教训聊完了操作层面的东西我想分享几个在实际迁移中总结出来的经验这些在官方文档里通常不会写但往往决定了迁移的顺利程度。第一数据库连接池的配置要同步调整。CM 和 CDH 组件大多使用连接池来管理数据库连接。迁移后如果新数据库的最大连接数比原库小或者网络延迟比原库高连接池可能会出现获取连接超时的情况。建议迁移后观察一段时间各组件的日志看是否有连接池相关的警告。第二时间同步很重要。数据库主机和集群主机之间的时间差如果超过一定阈值可能会导致认证失败或数据不一致。迁移前确认所有主机都配置了时间同步服务。第三不要忽视数据库的 max_allowed_packet 参数。CM 和 Hive 在某些操作中会写入较大的数据包如果新库的max_allowed_packet设置过小会导致写入失败。建议新库的这个参数不低于原库的设置。第四迁移脚本要可重复执行。如果你管理的不止一个集群建议把迁移过程脚本化包括备份、创建库、导入、改配置、启动验证等步骤。这样下次再遇到类似需求时可以直接复用减少人为失误。第五文档记录要详细。记录下原库的版本、字符集、关键参数、迁移时间、遇到的问题和解决办法。这些信息在后续排查问题或再次迁移时非常有价值。最后说一个我自己的习惯每次做这类迁移我都会在操作前画一张简单的依赖关系图标出各个组件和数据库之间的连接关系以及停机和启动的顺序。这张图不需要很正式手画就行但能帮我在操作时保持清晰的思路避免漏掉某个环节。迁移这件事技术难度其实不算特别高真正考验的是细致和耐心。把每一步想清楚把每个可能出问题的地方提前准备好应对方案基本上就能平稳落地。