为什么安装cdh需要安装mysql

你需要先使用mysql链接mysqld（第一步开启的服务端），之后手动创建blog_db数据库，rails是不会自动创建mysql的数据库的（里面的各个表你不需要创建，这是active_record的工作）。

看你error

log应该是mysqld没运行！

这是一个很容易出现的问题，网上很多内容将mysql驱动包上传到不对的路径导致出现问题。

cloudera manager添加hive时报错找不到jdbc driver

报错

JDBC driver cannot be found. Unable to find the JDBC database jar on host

把包放入这个目录，注意文件名要保持一致 网上又很多需要把这个驱动包放到

cp /root/mysql-connector-java-5.1.33-bin.jar /opt/cloudera/parcels/CDH-5.4.0-1.cdh5.4.0.p0.27/lib/hive/lib/

/opt/cloudera/parcels/CDH/lib/hive/lib或者

/opt/cloudera/parcels/CDH-5.4.0-1.cdh5.4.0.p0.27/lib/hive/lib

以上其实是同一个位置

*** 作后问题依旧出现。

解决方法：

后来在网上找到需要将这个包放到这个路径下就通过了（名字需要修改下）

/usr/share/java/mysql-connector-java.jar

这个问题早在去年9月就被发现了，但是现场保存得不好，只在上留了几张截图。并且笔者那时跑到11区浪去了，当时也被有司请去喝了一段时间的茶，因此细节没有保留太多，权当留个备忘吧。

故障现象：

凭直觉确定是OOM了。去/var/log/cloudera-scm-firehose目录下查看Service Monitor的角色日志，果然有频繁的因JVM GC导致的stop-the-world。

于是我们将Service Monitor的堆内内存和堆外内存都加大到16GB，重启之，发现完全没有好转。

接下来自然是采用top+ps+jstack大法，试图定位到出问题的线程，但令人窒息的是，吃CPU最狠的那个线程竟然没有线程ID。忘了截图，就这样吧。

翻看CDH官方文档，找到了其监控服务中的数据存储相关细节，传送门 https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_storage.html 。简单概括如下。

下图示出Cloudera Manager提供的监控图表展开后的数据粒度选项。

由于时序数据肯定会占绝大部分（最小都要有10GB大），联想到rollup可能容易出现问题。从日志看，rollup的延迟已经达到了一天之多，说明进入到LevelDB的监控数据过多，处理不过来了。这是造成内存爆掉的真正原因。

在CDH 6.x版本中，可以通过将 firehose.timeseries.rollup.disabled 配置项设为false来禁用指标rollup，但是同时会造成汇总粒度只剩下raw，查看起来不是很方便。更合适的方法是禁用掉一些产生大量指标但平时又不太关心的服务的监控，即在对应服务的配置中取消勾选“Enable Metric Allocation”一项。

通过观察每个服务的Charts Library，发现Kudu的监控指标和实体都很多（每张表都会产生监控数据）。我们关闭对Kudu的监控，并手动清理了 firehose.storage.base.directory 目录内的监控数据后，再重启Service Monitor，一切正常。

民那晚安，祝身体健康，百毒不侵。

---