Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Upgrading CM to 5.7 from 5.5 seems way too complicated

Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor

I started with Quickstart 5.5 & using CM 5.5 with it. 5.5 CM cannot use 5.7 parcels, so I tried to upgrade CM to 5.7.

 

 

Anybody get this going successfully. The document is a lot of work. After having 2 unsuccessfull tries, I am thinking if my time is better spend just creating a new CDH using 5.7 fresh & reinstall other components instead of worrying about the upgrade.

 

What are others doing?

 

11 REPLIES 11

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

Having more recently upgraded from 5.3 to 5.5, the upgrade from 5.5 to 5.7 went a lot smoother. The hardest part I found was managing the psql database. Can you tell me what part, specifically, you found issues with?

Highlighted

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor

DataSplainer, Thanks for your response. I started with quickstart 5.5 recently so the cost of entry was really low. this is also a local install, not a prod deployment on a real cluster.


I would imagine CM having an option to upgrade thru GUI to a new version, i.e. guide thru the process of downloading the parcel (or package), edit necessary configuration, then stop / start scm server & agent.


While there wasn't any specific issue I hit, except for even after following the step (to my best knowledge), I did *not* see it upgraded. The CDH 5.7 parcel repo still shows the message the CM 5.7 is required, which means somewhere the upgrade process failed.

So for right now, I am try the manual upgrade again & now since I have done all (or most) of the instructions I should go faster & hopefully I will be able to identify any missing steps or errors along the way.

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

Sounds like you're on the right track. I had the same issue the first time I performed an upgrade. Had to roll it back and try again. Good thing I backed it all up.

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor

tried the upgrade of quickstart 5.5 on CentOS 6.4 (on VM via VMWare workstation 12 Player) again today. 
here are the highlights of the undertaking

0. upgrading thru tarball method, CDH was migrated to parcel before to install kafka

1. Upgrade steps ran. haven't put the scm-server & scm-agent in init, but those are additional steps for later.

Issue with sudo tar xzf cloudera-manager*.tar.gz -C /opt/cloudera-manager

change owner/group of folder /opt/cloudera-manager & child dirs to a non existing ids. Need to run chown right after. Document has it later in a conditional, but this is actually needed right away. 

2. server & agent are both up (start command returned OK).

  2b. running as root, may change to other user later.

3. Below the error that shows in /var/log/cloudera-scm-agent/cloudera-scm-agent.log

  3b. google search points to IP/FQDN. I am localhost (i.e. quickstart.cloudera), that is how CDH5.5 ran on the VM.

4. Most imp Issue: cannot access cloudera manager WebUI (quickstart.cloudera:7180 or localhost:7180) to go further. Researching what other logs to look for cloudera web ui.

 

[28/Apr/2016 02:02:14 +0000] 21595 MainThread agent ERROR Heartbeating to localhost:7182 failed.
Traceback (most recent call last):
File "/opt/cloudera-manager/cm-5.7.0/lib64/cmf/agent/build/env/lib/python2.6/site-packages/cmf-5.7.0-py2.6.egg/cmf/agent.py", line 1191, in _send_heartbeat
self.master_port)
File "/opt/cloudera-manager/cm-5.7.0/lib64/cmf/agent/build/env/lib/python2.6/site-packages/avro-1.6.3-py2.6.egg/avro/ipc.py", line 469, in __init__
self.conn.connect()
File "/usr/lib64/python2.6/httplib.py", line 720, in connect
self.timeout)
File "/usr/lib64/python2.6/socket.py", line 567, in create_connection
raise error, msg
error: [Errno 111] Connection refused

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor

Update on prev thread...

 

0. Found out that scm-server is shutting down right after start.
  0a. the log is getting written at /opt/cloudera-manager/cm-5.7.0/log/cloudera-scm-server (not /var/log/cloudera-scm-server like before, unsure if I missed editting any config file for server).

 

cloudera-scm-server.log  

2016-04-28 05:05:24,440 INFO main:com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource: Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@88f14c60 [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@2dc83b3 [ 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 -> z8kflt9gpbjkra1h94807|4f2f2008, 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@12be8d31 [ description -> null, driverClass -> null, factoryClassLocation -> null, identityToken -> z8kflt9gpbjkra1h94807|e067956, jdbcUrl -> jdbc:mysql://null/null?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 -> z8kflt9gpbjkra1h94807|4ba588eb, numHelperThreads -> 3 ]
2016-04-28 05:05:33,773 WARN com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2:com.mchange.v2.resourcepool.BasicResourcePool: com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@3dc6893 -- 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:
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1036)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:338)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2232)
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2265)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2064)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:790)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:44)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:395)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:325)
at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:135)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137)
at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014)
at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:213)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:297)
... 20 more

 

cloudera-scm-server.out

JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
Exception in thread "main" 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
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
at org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:616)
at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1003)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:907)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
at com.cloudera.server.cmf.Main.bootstrapSpringContext(Main.java:387)
at com.cloudera.server.cmf.Main.<init>(Main.java:242)
at com.cloudera.server.cmf.Main.main(Main.java:216)
Caused by: 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
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:149)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:102)
at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1440)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:247)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
... 17 more

 

 

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

Master Guru
Could I ask why you are trying to upgrade CM using tarballs (which do have a lot of self-maintenance steps required) instead of the offered packages?

If you were following the docs at http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrade_cm5.html#concept_mn4_r1... note that the section "Install Cloudera Manager Server and Agent Software (Tarballs)" is only for tarball users. Were you using Tarballs prior to the upgrade?

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor
Document doesn't mention a suggested path for QuickStart upgrade.

So, I did try the packages route as well, no bite. I don't have that info handy so will give it one more try & record my experience.

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

Expert Contributor

Hello,

 

Are you referring to the QuickStart VM?

 

We do not provide an upgrade path for this because it is not designed for real deployments. The QuickStart VM is specifically designed to allow users to quickly test, demo, and assess possible use cases for a properly architected deployment. The QuickStart Image has a fairly large number of customizations that allow users to work with both packages and parcels which will make it fairly difficult to upgrade.

Customer Operations Engineer | Security SME | Cloudera, Inc.

Re: Upgrading CM to 5.7 from 5.5 seems way too complicated

New Contributor
Yes, I need is to upgrade a QuickStart VM (CDH 5.5). There is no QuickStart 5.7 available & I have a need for Spark1.6.

So are you saying upgrade is difficult or plain simple not possible, either via packages or tarball route?

Don't have an account?
Coming from Hortonworks? Activate your account here