Bug #52877 "existing MySQL database" setup for MEM + "skip-innodb" for such database = fail
Submitted: 16 Apr 2010 1:15 Modified: 9 Sep 2010 15:00
Reporter: Roel Van de Paar Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Enterprise Monitor: Installing Severity:S1 (Critical)
Version:2.2.0.1696 OS:Any
Assigned to: BitRock Merlin CPU Architecture:Any

[16 Apr 2010 1:15] Roel Van de Paar
Description:
2010-04-16 10:56:25,861  WARN [Thread-1:org.hibernate.util.JDBCExceptionReporter] SQL Error: 1286, SQLState: 42000
2010-04-16 10:56:25,861 ERROR [Thread-1:org.hibernate.util.JDBCExceptionReporter] Unknown table engine 'InnoDB'
2010-04-16 10:56:25,862 ERROR [Thread-1:org.hibernate.tool.hbm2ddl.SchemaUpdate] could not complete schema update
org.hibernate.exception.SQLGrammarException: could not get table metadata: schema_version_v2
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:52)
	at [...]
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown table engine 'InnoDB'
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
	at com.mysql.jdbc.Util.getInstance(Util.java:381)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1051)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3563)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3495)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2687)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2616)
        at [...]
	... 56 more

------ Also

2010-04-16 11:07:12,444 ERROR [Thread-1:org.springframework.web.context.ContextLoader] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateExecutor' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.mysql.etools.monitor.pom.hib.SchemaMaintenanceExecutor]: Constructor threw exception; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:254)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
        at [...]

------ And

2010-04-16 11:07:12,445 ERROR [Thread-1:org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/]] Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateExecutor' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.mysql.etools.monitor.pom.hib.SchemaMaintenanceExecutor]: Constructor threw exception; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:254)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
	at [...]

------ And likely others.

How to repeat:
1. Set skip-innodb (| have_innodb   | DISABLED |)
2. Install MEM2.2 using "use existing MySQL database"
3. Observe log

Suggested fix:
#1 Don't allow install on servers that do not have have_innodb = YES
#2 Handle have_innodb = NO and have_innodb = DISABLED issues properly when removed and/or disabled later. At the moment, the only way to realize what is going on is by checking the mysql-monitor.log for the above. The webpage itself gives:

--------
HTTP Status 404 - /

type Status report

message /

description The requested resource (/) is not available.
Apache Tomcat/6.0.14
--------
[16 Apr 2010 1:16] Roel Van de Paar
Shows in stdout log as:

16/04/2010 11:07:10 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
log4j:ERROR LogMananger.repositorySelector was null likely due to error in class reloading, using NOPLoggerRepository.
Exception in thread "Thread-2" java.lang.NoClassDefFoundError: com/mysql/jdbc/ConnectionImpl$1
	at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1545)
	at org.apache.commons.dbcp.DelegatingConnection.close(DelegatingConnection.java:151)
	at org.apache.commons.dbcp.PoolableConnection.reallyClose(PoolableConnection.java:95)
	at org.apache.commons.dbcp.PoolableConnectionFactory.destroyObject(PoolableConnectionFactory.java:301)
	at org.apache.commons.pool.impl.GenericObjectPool.evict(GenericObjectPool.java:956)
	at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1085)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.ConnectionImpl$1
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	... 7 more
[16 Apr 2010 1:43] Roel Van de Paar
Verified by un-install > re-install on same machine with skip-innodb enabled.

Workaround: enable InnoDB, restart "MySQLEnterpriseTomcat" service, re-load web page.
[23 Apr 2010 22:08] Enterprise Tools JIRA Robot
Andy Bang writes: 
When you check an "existing" MySQL server when installing or upgrading MEM (as opposed to the MySQL server we deliver with MEM), in addition to checking the version number and that partitioning is enabled, please also check the InnoDB is installed and enabled.  If have_innodb != YES, display a message that says "A MySQL server with the InnoDB storage engine enabled is required".
[25 Apr 2010 21:09] Roel Van de Paar
IMO, this should be fixed for 2.2 GA. The issue is not obvious/easy to analyze ("the only way to realize what is going on is by checking the mysql-monitor.log for the above"), it is very easy to fix for the installation part (add one more check), and this may save support engineers work/time down the track.
[29 Apr 2010 10:27] BitRock Merlin
Patch sent to Keith. The exact error message that the installer throws is the following: "MySQL Server version 5.1.40 or later with partitioning and InnoDB storage engine enabled is required."
[4 May 2010 17:26] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch pushed to installer repository.
[4 May 2010 18:09] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch installed in versions => 2.2.0.1709.
[10 May 2010 20:11] Enterprise Tools JIRA Robot
Marcos Palacios writes: 
Tested in Monitor installers, build 2.2.0.1709:
 - the full installer does show the pop-up with the message indicated above, however
 - the upgrade installer does not show this message, as requested in the comment of 24/Apr/10 12:07 AM.
[11 May 2010 10:29] BitRock Merlin
We can not reproduce on our side. We checked that it runs on Windows and Linux properly. Could you let us know the platform where you are testing it? Could you post the installer log file?
[13 May 2010 14:24] BitRock Merlin
Patch sent to Keith. The log file is "/tmp/bitrock_installer_xxxx.log". In this case the error is related to how the upgrade installer was checking the previous installation.
[13 May 2010 22:09] Roel Van de Paar
Discussion with Marcos about this. Some pointers:

1. Version, partitioning and skip_innodb checking should be continuous.
   If a user decides to put "skip_innodb" later - we have the same problem.
   A user could also disable partitioning, or even decide to downgrade (let's hope not).
   End result will likely be that support has to fix it.
2. What happens when a user upgrades from 2.1 to 2.2 and chooses a separate DB?
   Is data migrated? Or is this considered a new install?
   What if such a DB has skip_innodb/partitioning disabled/is an earlier version? < This needs to be tested.
3. There is also the (somewhat tricky-to-test) situation that Marcos is highlighting.
   Using 2.1 for testing won't work as it does not have the feature for separate DB.
   So testing using the last beta seems like a good option.
[13 May 2010 23:55] Enterprise Tools JIRA Robot
Andy Bang writes: 
In build 2.2.1.1718.
[14 May 2010 0:39] Enterprise Tools JIRA Robot
Marcos Palacios writes: 
Verified fixed in Monitor build 2.2.1.1718.

The warning/error pop-up for the upgrade case has been seen now. I will attach it for inspection by the Support team since its text is much different than the text in the full install case.

Observe that Support has some questions in a previous comment as well.
[14 May 2010 0:40] Enterprise Tools JIRA Robot
Marcos Palacios writes: 
Attaching image of warning/error pop-up for the upgrade case.
[14 May 2010 0:40] Enterprise Tools JIRA Robot


Attachment: 10373_bug52877upgrade.png (image/png, text), 88.87 KiB.

[14 May 2010 14:43] Marcos Palacios
Note for Docs team:
Per Dev team, we would like the upgrade path (backup, recover database to target instance, then run the upgrade installer and point to the new remote instance) properly documented in the upgrade section of the docs, as well as the Innodb and partitioning requirements that the upgrades check for.
[14 May 2010 21:39] Roel Van de Paar
See bug #53158
[24 Aug 2010 14:36] Enterprise Tools JIRA Robot
Mark Leith writes: 
Reopening to re-set to documenting
[9 Sep 2010 15:00] MC Brown
I've updated the documentation to point out the best way to upgrade with a remote MySQL install, and what to check for.