问题解决:CDH重启报错,启动不了的解决步骤

文章目录

  • 问题场景
  • 问题环境
  • 问题原因
    • 确定重启命令
    • 尝试连接页面
    • 确定环境
    • 查看日志
  • 解决方案
    • 数据库配置文件是否正常
    • 权限是否赋权正常
  • 总结
  • 随缘求赞转发关注三连

问题场景

因为园区突发断电,导致服务器断电。部署在服务器上面的CDH集群都挂了。现在需要重新启动起来,但是重启之后,服务一直启动不起来。本篇博文主要是针对这种情况,阐述解决问题的思路和问题解决的过程。

问题环境

软件 版本
Centos 7
CDH 5.15.1

问题原因

接下来,就是我排查问题的思路。我一直觉得思路很重要,会让人少走很多弯路。

确定重启命令

systemctl restart cloudera-scm-server

尝试连接页面

这个要和具体的服务器ip相对应。比如我的CM服务器的域名是namdnode01,那访问页面的地址就是:

http://namenode01:7180

但是,登录一直报错,连接不上。所以,这个时候,可以确定是服务启动失败。

确定环境

因为CDH集群是需要关联mysql数据库的,所以需要先确定当前mysql数据库是否启动正常。那我们可以去查看数据库是否正常,可以用命令:

ps -ef|grep mysqld|grep -v grep

如果没有显示,则mysql数据库是没有启动。需要先启动起来;否则,就说明数据库是已经启动的。

查看日志

首先遇到问题,先不要盲目地百度或者谷歌。因为类似CDH这种集成软件,造成问题的原因可能是多种多样的,每个人遇到的可能是不同的。而且,问题的提示可能是找不到具体原因的。这个时候就需要先查看日志,看看日志报错的原因是什么。
如果没有自定义设置CM服务日志存放位置的话,一般都会在以下目录:

[root@namenode01 cloudera-scm-server]# pwd
/var/log/cloudera-scm-serve

登录进去,我们可以查看一下当前目录有什么文件:
问题解决:CDH重启报错,启动不了的解决步骤_第1张图片
而我们需要查看的日志文件是cloudera-scm-server.log。如果比较难找,可以先重命名当前日志文件,然后重新执行启动命令,然后再查看日志。而对于博主来说,这里的问题的展示如下:

2020-05-21 10:21:15,110 INFO main:com.cloudera.enterprise.CommonMain: Reading database properties from /etc/cloudera-scm-server/db.properties
2020-05-21 10:21:15,114 INFO main:com.cloudera.enterprise.CommonMain: Statistics not enabled, c3p0 JMX disabled
2020-05-21 10:21:15,237 INFO main:org.hibernate.annotations.common.Version: HCANN000001: Hibernate Commons Annotations {4.0.2.Final}
2020-05-21 10:21:15,241 INFO main:org.hibernate.Version: HHH000412: Hibernate Core {4.2.2.Final}
2020-05-21 10:21:15,243 INFO main:org.hibernate.cfg.Environment: HHH000206: hibernate.properties not found
2020-05-21 10:21:15,244 INFO main:org.hibernate.cfg.Environment: HHH000021: Bytecode provider name : javassist
2020-05-21 10:21:15,564 INFO main:org.hibernate.cfg.Configuration: HHH000221: Reading mappings from resource: cmf.hbm.xml
2020-05-21 10:21:15,784 INFO main:org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator: HHH000130: Instantiating explicit connection provider: org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider
2020-05-21 10:21:15,785 INFO main:org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider: HHH010002: C3P0 using driver: com.mysql.jdbc.Driver at URL: jdbc:mysql://namenode01:3306/cmf?useUnicode=true&characterEncoding=UTF-8
2020-05-21 10:21:15,786 INFO main:org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider: HHH000046: Connection properties: {user=cmf, password=****, autocommit=true, release_mode=auto}
2020-05-21 10:21:15,786 INFO main:org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider: HHH000006: Autocommit mode: true
2020-05-21 10:21:15,808 INFO main:com.mchange.v2.log.MLog: MLog clients using log4j logging.
2020-05-21 10:21:15,923 INFO main:com.mchange.v2.c3p0.C3P0Registry: Initializing c3p0-0.9.1.1 [built 15-March-2007 01:32:31; debug? true; trace: 10]
2020-05-21 10:21:15,964 INFO main:org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider: HHH000149: JDBC isolation level: READ_COMMITTED
2020-05-21 10:21:15,994 INFO main:com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource: Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@99e947a [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@f49b45ff [ acquireIncrement -> 3, acquireRetryAttempts -> 5, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 20000, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> 1bwmhq3aaepqzsw1oh1pkj|497486b3, idleConnectionTestPeriod -> 300, initialPoolSize -> 3, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 0, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 50, maxStatements -> 2500, maxStatementsPerConnection -> 0, minPoolSize -> 5, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@9c79a53f [ description -> null, driverClass -> null, factoryClassLocation -> null, identityToken -> 1bwmhq3aaepqzsw1oh1pkj|460ebd80, jdbcUrl -> jdbc:mysql://namenode01:3306/cmf?useUnicode=true&characterEncoding=UTF-8, properties -> {user=******, password=******, autocommit=true, release_mode=auto} ], preferredTestQuery -> null, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, factoryClassLocation -> null, identityToken -> 1bwmhq3aaepqzsw1oh1pkj|39fcbef6, numHelperThreads -> 3 ]
2020-05-21 10:21:20,284 WARN com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2:com.mchange.v2.resourcepool.BasicResourcePool: com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@5353428 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (5). Last acquisition attempt exception: 
java.sql.SQLException: Access denied for user 'cmf'@'namenode01' (using password: YES)
...
2020-05-21 10:21:24,316 ERROR main:org.hibernate.engine.jdbc.spi.SqlExceptionHelper: Connections could not be acquired from the underlying database!
2020-05-21 10:21:24,323 INFO main:org.springframework.beans.factory.support.DefaultListableBeanFactory: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@13b6aecc: defining beans [commandLineConfigurationBean,entityManagerFactoryBean,com.cloudera.server.cmf.TrialState,com.cloudera.server.cmf.TrialManager,com.cloudera.cmf.crypto.LicenseLoader]; root of factory hierarchy
2020-05-21 10:21:24,323 ERROR main:com.cloudera.server.cmf.Main: Server failed.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.cloudera.server.cmf.TrialState': Cannot resolve reference to bean 'entityManagerFactoryBean' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactoryBean': FactoryBean threw exception on object creation; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not open connection

从以上的日志文件,我们可以得到以下几点信息:

  1. CDH集群读取数据库配置的路径在于:Reading database properties from /etc/cloudera-scm-server/db.properties;
  2. 当前数据库连接为jdbc:mysql://namenode01:3306/cmf?useUnicode=true&characterEncoding=UTF-8
  3. 具体报错原因为:java.sql.SQLException: Access denied for user 'cmf'@'namenode01' (using password: YES)

从获取的信息已经可以知道怎么解决这个问题了。
问题解决:CDH重启报错,启动不了的解决步骤_第2张图片

解决方案

问题解决:CDH重启报错,启动不了的解决步骤_第3张图片
从日志,我们获取了配置文件所在地和具体报错原因。那我们可以从两个方法确定一下:

数据库配置文件是否正常

我们查看/etc/cloudera-scm-server/db.properties文件内容,如下是博主这边的数据库配置信息:

# Auto-generated by scm_prepare_database.sh on 2019年 07月 01日 星期一 16:03:56 CST
#
# For information describing how to configure the Cloudera Manager Server
# to connect to databases, see the "Cloudera Manager Installation Guide."
#
com.cloudera.cmf.db.type=mysql
com.cloudera.cmf.db.host=namenode01:3306
com.cloudera.cmf.db.name=cmf
com.cloudera.cmf.db.user=cmf
com.cloudera.cmf.db.setupType=EXTERNAL
com.cloudera.cmf.db.password=test

数据库配置没什么。关注点主要在type/host/name/user/password这几方面。一般这个没有什么问题,就没问题。

权限是否赋权正常

如果配置文件是正确的,那应该是被数据库给限制了。这里就不详细展开说明了,如果需要查看,请点击我的另一篇博文《mysql学习系列:总结数据库连接不上的数种情况,问题编号:ERROR 1045 (28000)》进行查看。
按照这篇博文的操作,我顺利解决了问题。其主要问题是出现了mysql.user表记录存在匿名用户,导致所有访问地址和namenode01相关的操作,都匹配到了匿名用户。而密码不一致,导致了报错。而我这边的解决方案,则是将匿名用户的记录给删除了,然后重新刷新了权限。之后,重新启动CDH,正确启动了。截图如下:
问题解决:CDH重启报错,启动不了的解决步骤_第4张图片

总结

遇到问题,都思考问题出现的原因。盲目地百度或者谷歌,都只是在浪费时间。即使偶尔按照网上的步骤解决了问题,也可能是一知半解。我的文章,一直都追求可以把问题发生的原因和解决方案讲述清楚,这样既是对以往历史的存档,也是对自己能力的锻炼。 谢谢大家的阅读!
问题解决:CDH重启报错,启动不了的解决步骤_第5张图片

随缘求赞转发关注三连

如果我的文章对大家产生了帮忙,可以在文章底部点个赞!有需要可以点击收藏;
如果有好的讨论,可以留言;
如果想继续查看我以后的文章,可以点击关注!
也可以扫描以下二维码,关注我的公众号:枫夜之求索阁,查看我最新的分享!
在这里插入图片描述
拜拜

你可能感兴趣的:(问题修复记录,大数据,CDH)