MySQL Connector/ODBC provides both driver-manager based and native interfaces to the MySQL database with full support for MySQL functionality, including stored procedures, transactions, and with Connector/ODBC 5.1 and higher, full Unicode compliance. CONTENTS * License * Description * Documentation * Known Bugs * Getting Started LICENSE MySQL Connector/MXJ is licensed under the GPL or a commercial license from MySQL AB.
Lo, i'm using Mysql connector/MXJ 1.1 with java 1.5 on windows xp and linux (suse 10) After some test i could use it to install mysql, as demo database or portable database, on windows. However when i tried to use it on linux and asking it to start it does, 'cause, but it creates no pid, and when asking the connector, it says THERE IS NO MYSQL available. I'm using it on the port 5565 (the port is free). The connector fully install it, i'm NOT USING the same installation of the windows Xp tests. After some test, it SEEMS it is loading, BUT can't full 'start'(?). However no way to understand WTF it doez. (i think the stupid library separation on linux gives it some problem?) any idea?
Any forum about? On Fri, 2006-04-21 at 19:14 +0200, Diego Zanga wrote: Lo, i'm using Mysql connector/MXJ 1.1 with java 1.5 on windows xp and linux (suse 10) After some test i could use it to install mysql, as demo database or portable database, on windows. However when i tried to use it on linux and asking it to start it does, 'cause, but it creates no pid, and when asking the connector, it says THERE IS NO MYSQL available.
I'm using it on the port 5565 (the port is free). The connector fully install it, i'm NOT USING the same installation of the windows Xp tests.Hello, Could you please include the console output? If Connector/MXJ is having trouble starting mysqld, then perhaps we will see some information sent to stdout or stderr? Cheers, - Eric. Eric Herman Diego Zanga- Thank you for your in-depth feedback and taking the time to dig into the source code. That's a rare pleasure.
The '5.0' branch is under development at this time and some of the issues that you mention have been, or are planned to be, addressed in that branch. You've encountered several things, so let me try to take them by category. Code dependencies:. For Connector/MXJ 5.0, Connector/J 5.0 is required. This is the beta version. JUnit is required to build the tests and can be./npaMysql: is my base directoryIt looks as though the first thing that was giving you trouble is the base directory. This has been addressed in the source tree of Connector/MXJ.
However, in the mean time, when creating directories, rather than using the '.' To specify working directory, using System.getProperty('user.dir') will avoid the errors that you are seeing.
String userDirStr = System.getProperty('user.dir'); File userDir = new File(userDirStr); File baseDir = new File(userDir, 'npaMysql'); This should avoid the 'datadir' and socket file creation, and PID file creation problems. Alternatively use of java.io.File's canonical path would also work, I suspect. In the next release of Connector/MXJ, this will not be an issue, and wherever wherever we converting between strings and files we will be using the file.getCanonicalPath. Also, on the source tree of the Connector/MXJ 5.0 branch, if a socket file is not specified, the socket file in no longer placed in the 'basedir', but in the 'datadir'. 3) MXJ jar needed to be fixed: it adds the parameter -no-default It DOESNT WORK on linux mysqld. So i've removed it in package com.mysql.management; MysqldResource.javaThe '-no-defaults' option is added to avoid reading an existing 'my.cnf' file from some other installation of MySQL on our system. I personal develop using linux and test under a couple of different linux configurations.
This is the first report of an issue with '-no-defaults'. If you could help me reproduce this problem I would like to get to the bottom of it. Next week I'll make sure I do some testing on SUSE 10. Cheers, - Eric. On Sat, 2006-04-22 at 12:48 -0500, Eric Herman wrote: 3) MXJ jar needed to be fixed: it adds the parameter -no-default It DOESNT WORK on linux mysqld. So i've removed it in package com.mysql.management; MysqldResource.javaThe '-no-defaults' option is added to avoid reading an existing 'my.cnf' file from some other installation of MySQL on our system.
I personal develop using linux and test under a couple of different linux configurations. This is the first report of an issue with '-no-defaults'. If you could help me reproduce this problem I would like to get to the bottom of it. Next week I'll make sure I do some testing on SUSE 10.I've confirmed that Connector/MXJ (with the -no-defaults) works as expected on SUSE 10 commercial. Which was the version a co-worker has handy on his machine. Cheers, - Eric.
U checked mxj 1.1 or mxj 5?Here is the output from my co-worker's run of the 1.1.6 version: philip@gus: java ConnectorMXJObjectTestExample MysqldResource launching mysqld (getOptions) /tmp/test-mxj/bin/mysqld-no-defaults-pid-file=/tmp/test-mxj/MysqldResource.pid-socket=/tmp/test-mxj/mysql.sock-datadir=/tmp/test-mxj/data-basedir=/tmp/test-mxj-port=3336 MysqldResource launching mysqld (test-mysqld-thread) 060425 15:27:38 InnoDB: Started; log sequence number 0 43634 /tmp/test-mxj/bin/mysqld: ready for connections. Version: '4.1.13-standard' socket: '/tmp/test-mxj/mysql.sock' port: 3336 MySQL Community Edition - Standard (GPL) MysqldResource mysqld running as process: 8051 MySQL is running. 4.1.13-standard - MysqldResource stopping mysqld (process: 8051) 060425 15:27:39 Note /tmp/test-mxj/bin/mysqld: Normal shutdown 060425 15:27:39 InnoDB: Starting shutdown.
060425 15:27:42 InnoDB: Shutdown completed; log sequence number 0 25 15:27:42 Note /tmp/test-mxj/bin/mysqld: Shutdown complete MysqldResource MysqldResource attempting to destroy thread test-mysqld-thread MysqldResource MysqldResource test-mysqld-thread destroyed. MysqldResource clearing options MysqldResource shutdown complete philip@gus: As we can see, the '-no-defaults' option worked just fine for this user. As mentioned before, his machine is running SUSE 10 commercial. For future reference, the 1.1.6 version includes the 'ConnectorMXJObjectTestExample' which requires only Connector/J and Connector/MXJ jars to be in the classpath.
It might be useful to see if just that much works for you. And it might also be useful to check the source code of the example to see that you are using Connector/MXJ in a similar fashion.
Eric Herman Yes. That is correct. As I said before, this has been addressed in the source tree of 5.0 branch of Connector/MXJ. However, in the mean time, when creating directories, rather than using the '.' To specify working directory, using System.getProperty('user.dir') will avoid the errors that you are seeing.
String userDirStr = System.getProperty('user.dir'); File userDir = new File(userDirStr); File baseDir = new File(userDir, 'npaMysql'); This should avoid the 'datadir' and socket file creation. On Thu, 2006-04-27 at 11:56 +0200, Diego Zanga wrote: The first 'thing' i see is that the path used is an absolute path /tmp/test-mxj so it works as works on my system: however when moving from absolute path to relative path './tmp/test-mxj' this takes to an error.Yes. That is correct. As I said before, this has been addressed in the source tree of 5.0 branch of Connector/MXJ.
However, in the mean time, when creating directories, rather than using the '.' To specify working directory, using System.getProperty('user.dir') will avoid the errors that you are seeing. String userDirStr = System.getProperty('user.dir'); File userDir = new File(userDirStr); File baseDir = new File(userDir, 'npaMysql'); This should avoid the 'datadir' and socket file creation, and PID file creation problems. Alternatively use of java.io.File's canonical path would also work, I suspect. Eric Herman Great! I wish you the best of luck! Please keep us posted.
If you have issues, we're here to help. And we love to hear success stories, too! The OS X binary is for PowerPC. By default Connector/MXJ ships with the following platforms:. Linux, x86 (statically linked glibc).
Mac OS X, PPC (version 10.3 & up). Windows, x86 (NT/XP/2003. Not: 95/98/ME/CE). Solaris, Sparc (versions 9 & up; future version will run on Solaris 8 and up) However, if additional platforms are required, it isn't. However, just to make it harder:O), the first tester has no linux available with week, it has only mac, and asked me on witch processor it works on mac:O?The OS X binary is for PowerPC. By default Connector/MXJ ships with the following platforms:.
Linux, x86 (statically linked glibc). Mac OS X, PPC (version 10.3 & up). Windows, x86 (NT/XP/2003. Not: 95/98/ME/CE). Solaris, Sparc (versions 9 & up; future version will run on Solaris 8 and up) However, if additional platforms are required, it isn't very hard to add binaries for other platforms to the connector-mxj jar file. In short there is a version directory in the jar file (Connector/MXJ ships with 4.1.13, the 5.0 branch ships with MySQL 5.0 by default). Under that directory are sub-directories for each platform.
The directory names are determined by using Java system properties 'os.name' and 'os.arch' separated by a hyphen. The 5.0 branch replaces spaces with underscores. In this directory the mysqld binary is places, along with a text file with the version information.
If you wish to alter the supported platforms for your uses, we'll be happy to help with that. We distribute the most common case, but we know not everyone's needs are the same. For instance, one client added SunOS-x86, one of our support guys runs BSD on his personal machine and added a binary for that, one user stripped out the non-windows binaries. We can help you configure it for your individual needs. Eric Herman This should be addressed in the most recent releases of MySQL, and consequently, should also be addressed in the next release of Connector/MXJ. snip At a guess, this is because mysqld, on the first run, takes longer to write out the pid file than Connector/MXJ is waiting for it.
I believe this, also, will be addressed in the next development release of Connector/MXJ. Regardless, it sounds like you have found a work-around. Please let us know if you run into additional issues.
Cheers, - Eric. I've tried MXJ on Ubuntu 5.10 and Suse 10, i dont know where the problem with -no-default comes from: after using the fix about absolute path all works. That's good news, then. The only problem i got is about the pid file: if i open mxj after the first time, it seems it lost the pid file and mysqld is no more under mxj control.
However re-running mysqld from mxj dont cause problems, else then a small 'lag' of 5 seconds.At a guess, this is because mysqld, on the first run, takes longer to write out the pid file than Connector/MXJ is waiting for it. I believe this, also, will be addressed in the next development release of Connector/MXJ. Regardless, it sounds like you have found a work-around. Andreas Schlicker Hi all, I'm using connector mxj 1.1.6 with Java 1.5.006 on Debian Linux. I have an small program that fills the database and a second one uses this db. First, I filled the db and the program exited with the following output: MysqldResource stopping mysqld (process: 28975) 060427 14:43:32 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Normal shutdown 060427 14:43:33 InnoDB: Starting shutdown.
060427 14:43:34 InnoDB: Shutdown completed; log sequence number 0 43634 at Apr 27, 2006 at 1:14 pm. Hi all, I'm using connector mxj 1.1.6 with Java 1.5.006 on Debian Linux.
I have an small program that fills the database and a second one uses this db. First, I filled the db and the program exited with the following output: MysqldResource stopping mysqld (process: 28975) 060427 14:43:32 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Normal shutdown 060427 14:43:33 InnoDB: Starting shutdown.
060427 14:43:34 InnoDB: Shutdown completed; log sequence number 0 27 14:43:34 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Shutdown complete MysqldResource clearing options MysqldResource shutdown complete Then I started the second application but it always gives me the following error: MysqldResource launching mysqld (driverlaunchedmysqld1) InnoDB: Unable to lock./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 060427 15:01:51 InnoDB: Retrying to lock the first data file. InnoDB: Unable to lock./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 060427 15:03:31 InnoDB: Unable to open the first data file InnoDB: Error in opening./ibdata1 060427 15:03:31 InnoDB: Operating system error number 11 in a file operation. InnoDB: Error number 11 means 'Resource temporarily unavailable'. InnoDB: Some operating system error numbers are described at InnoDB: InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here, InnoDB: you should now edit innodbdatafilepath in my.cnf back InnoDB: to what it was, and remove the new ibdata files InnoDB created InnoDB: in this failed attempt. InnoDB only wrote those files full of InnoDB: zeros, but did not yet use them in any way. But be careful: do not InnoDB: remove old data files which contain your precious data!
060427 15:03:31 ERROR Can't init databases 060427 15:03:31 ERROR Aborting I checked that there is no other mysqld instance running (pstree, netstat) and tried to run the second program on a different machine. The code used to connect to the database is identical in both cases.
Does anybody have an idea what the problem could be? Thanks, Andreas. Eric Herman On Thu, 2006-04-27 at 15:15 +0200, Andreas Schlicker wrote: Hello Andreas, This part looks very unusual.
Clearly there is something wrong here, relating to ibdata1, but I don't have a good guess what immediately. I have not seen this before with Connector/MXJ. I understand that it is not practical for you to post your code, but perhaps I could persuade you to create some sample code (similar to your real code) which also has this problem.
Then I could run the code and see if I can reproduce the. Hi all, I'm using connector mxj 1.1.6 with Java 1.5.006 on Debian Linux. I have an small program that fills the database and a second one uses this db. First, I filled the db and the program exited with the following output: MysqldResource stopping mysqld (process: 28975) 060427 14:43:32 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Normal shutdown 060427 14:43:33 InnoDB: Starting shutdown. 060427 14:43:34 InnoDB: Shutdown completed; log sequence number 0 27 14:43:34 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Shutdown complete MysqldResource clearing options MysqldResource shutdown complete The output above looks normal and good. Then I started the second application but it always gives me the following error: MysqldResource launching mysqld (driverlaunchedmysqld1) InnoDB: Unable to lock./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 060427 15:01:51 InnoDB: Retrying to lock the first data file.
InnoDB: Unable to lock./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 060427 15:03:31 InnoDB: Unable to open the first data file InnoDB: Error in opening./ibdata1 060427 15:03:31 InnoDB: Operating system error number 11 in a file operation. InnoDB: Error number 11 means 'Resource temporarily unavailable'. InnoDB: Some operating system error numbers are described at InnoDB: InnoDB: Could not open or create data files. InnoDB: If you tried to add new data files, and it failed here, InnoDB: you should now edit innodbdatafilepath in my.cnf back InnoDB: to what it was, and remove the new ibdata files InnoDB created InnoDB: in this failed attempt.
InnoDB only wrote those files full of InnoDB: zeros, but did not yet use them in any way. But be careful: do not InnoDB: remove old data files which contain your precious data! 060427 15:03:31 ERROR Can't init databases 060427 15:03:31 ERROR AbortingThis part looks very unusual. Clearly there is something wrong here, relating to ibdata1, but I don't have a good guess what immediately. I have not seen this before with Connector/MXJ. I'm using connector mxj 1.1.6 with Java 1.5.006 on Debian Linux.
I have an small program that fills the database and a second one uses this db. First, I filled the db and the program exited with the following output: MysqldResource stopping mysqld (process: 28975) 060427 14:43:32 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Normal shutdown 060427 14:43:33 InnoDB: Starting shutdown.
060427 14:43:34 InnoDB: Shutdown completed; log sequence number 0 27 14:43:34 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Shutdown complete MysqldResource clearing options MysqldResource shutdown completeThe output above looks normal and good. I understand that it is not practical for you to post your code, but perhaps I could persuade you to create some sample code (similar to your real code) which also has this problem. Then I could run the code and see if I can reproduce the error, and hopefully gain some insight into how to fix it.I attached two files that contain some sample code that reproduces the problem on my system. Regards, Andreas.
I'm using connector mxj 1.1.6 with Java 1.5.006 on Debian Linux. I have an small program that fills the database and a second one uses this db.
First, I filled the db and the program exited with the following output: MysqldResource stopping mysqld (process: 28975) 060427 14:43:32 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Normal shutdown 060427 14:43:33 InnoDB: Starting shutdown. 060427 14:43:34 InnoDB: Shutdown completed; log sequence number 0 27 14:43:34 Note /TL/usr1/schlandi/work/masterthesis/GOTaxExplorer/fsst/bin/mysqld: Shutdown complete MysqldResource clearing options MysqldResource shutdown completeThe output above looks normal and good. I understand that it is not practical for you to post your code, but perhaps I could persuade you to create some sample code (similar to your real code) which also has this problem. Then I could run the code and see if I can reproduce the error, and hopefully gain some insight into how to fix it.I attached two files that contain some sample code that reproduces the problem on my system.I tested the sample code on my laptop with Debian and Windows XP and it runs perfectly on this machine. However, I still have the same problem on several workstations running Debian. It looks like a problem of the configuration of the machine. Do you have an idea what could cause the problem?
Regards, Andreas. Eric Herman Hi Andreas, Great examples! I do have a tiny a guess.
But I will ask around about it. Let me lead with the question: are we seeing failures on multiple CPU machines? Here is why I ask: InnoDB locks datafile (ibdata1) when it starts (using fcntl), and does not explicitely unlock it, which means it is unlocked when the mysqld process terminates, i.e. After the PID file is removed. So if you send mysqld a shutdown request (kill. I tested the sample code on my laptop with Debian and Windows XP and it runs perfectly on this machine. However, I still have the same problem on several workstations running Debian.
It looks like a problem of the configuration of the machine. Unfortunately, they run.perfectly. out-of-the-box for me, too. Do you have an idea what could cause the problem?I do have a tiny a guess. But I will ask around about it.
Let me lead with the question: are we seeing failures on multiple CPU machines? Here is why I ask. From InnoDB locks datafile (ibdata1) when it starts (using fcntl), and does not explicitely unlock it, which means it is unlocked when the mysqld process terminates, i.e. After the PID file is removed. So if you send mysqld a shutdown request (kill -TERM or mysqladmin shutdown), wait for PID file to be gone, and restart mysqld immediately, there is a chance that the old mysqld is somewhere between removal of PID and disappearance, so this old mysqld would still have the lock, and the new mysqld would fail to lock. The machine which exhibits the problem has 2 CPUs and is Linux. So perhaps what we are seeing is a timing issue?
Perhaps if we waited a moment between execution of the first program and the second program we would not see the issue. If this is /not/ the issue, then obviously there is.something. configuration dependent here. Let's get as much information as we can about the failing systems and compare it to the working systems.
Let's start with a couple of:. Which versions of Debian? ). What is the result of 'uname -a'. Which JVM?.
For the record, which version of Connector/J? (This won't make any difference for this issue, of course.).
We aren't running as 'root' are we?. We're using Connector/MXJ 1.1.6, in all cases, correct? And anything else you can think of which might help re-create the environment or might differentiate the failing environments from the working ones, would certainly be worth looking at, even if they don't seem like they could possibly make a difference. This may be a hard one to find, but hopefully it will be simple to solve once we identify the root cause.
Cheers, - Eric. Andreas Schlicker Hi Eric, The failures occur on single and multi CPU machines. The workstations are single Pentium 4 machines but I also tried cluster nodes with 2 Opterons. The problem occurs even if I wait several days before launching the second program. Sarge; we have an internal 'distribution' from our computer support group which includes, as far as I know, also some testing packages. Java version '1.5.006' Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.006-b05) Java HotSpot(TM) Client VM at May 2, 2006 at 10:55 am.
Eric Herman Sounds like it isn't that simple. No surprise there.
Thus, not the timing issue referenced in that bug. However, I do think that we might be looking at an issue that has to do with the server ('mysqld') and possibly totally independent of the Connector/MXJ wrapper. Okay, well that sounds like it may be pretty hard for me to duplicate. But, I can certainly find a 'stock' sarge/testing x86 machine to try to duplicate this problem on. And this suggests it may be even more tricky to duplicate. If this is /not/ the issue, then obviously there is.something.
Mysql Connector/mxj 5.0.11 For Mac
configuration dependent here. Let's get as much information as we can about the failing systems and compare it to the working systems. Let's start with a couple of:. Which versions of Debian? )sarge; we have an internal 'distribution' from our computer support group which includes, as far as I know, also some testing packages.Okay, well that sounds like it may be pretty hard for me to duplicate.
But, I can certainly find a 'stock' sarge/testing x86 machine to try to duplicate this problem on. For the record, which version of Connector/J? (This won't make any difference for this issue, of course.) 3.1.11. We aren't running as 'root' are we? No, as normal user. We're using Connector/MXJ 1.1.6, in all cases, correct?Exactly.
My laptop uses exactly the same kernel and the same distribution but everything runs smoothly.And this suggests it may be even more tricky to duplicate. Let's see if we can confirm whether or not Connector/MXJ is directly related to the issue. Let's start be removing Connector/MXJ from the picture.
My proposal is to alter the test programs to just use Connector/J and JDBC. And to move the starting and stopping of the database to the command line between applications. Now to start the server you'll need to run the same command that Connector/MXJ constructs from the arguments which you provide. It will look something like this: /path/to/basedir/mysqld -no-defaults -pid-file=/path/to/basedir/MysqldResource.pid -socket=/path/to/basedir/mysql.sock -port=3336 -datadir=/path/to/basedir/data -basedir=/path/to/basedir You can find out exactly what command line arguments are being used by running your test program and viewing the Connector/MXJ output. You should see a reconstruction of the command line with each command line element encapsulated in square brackets. Then, to terminate the database, use 'kill '. You can find the PID by looking at the screen output of the mysqld command, or by reading the MysqldResource.pid file.
First, I'd like you to give this a go on your laptop where we expect everything to succeed. Once it works there, second, I'd like to have you give it a try with one of the machines on which we're experiencing the 'InnoDB: Unable to lock./ibdata1, error: 11' problem. With a little luck, this will tell us that we have a server platform issue. If this is the case, then updating the linux mysqld in the connector-mxj.jar file may be the solution. Best of luck on the bug hunt, and please let me know what you learn. And if you get stuck, please don't be shy about asking questions.
Cheers, - Eric. Andreas Schlicker Hi Eric, I tried this but I get another problem. If I have an empty data dir and start mysqld on the command line on my workstation, I get this output: InnoDB: The first specified data file./ibdata1 did not exist: InnoDB: a new database to be created! 060503 11:18:13 InnoDB: Setting file./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait. 060503 11:18:14 InnoDB: Log file./iblogfile0 did not exist: new to be created InnoDB: Setting log file./iblogfile0 size to at May 3, 2006 at 9:31 am. My proposal is to alter the test programs to just use Connector/J and JDBC.
And to move the starting and stopping of the database to the command line between applications. Now to start the server you'll need to run the same command that Connector/MXJ constructs from the arguments which you provide. It will look something like this: /path/to/basedir/mysqld -no-defaults -pid-file=/path/to/basedir/MysqldResource.pid -socket=/path/to/basedir/mysql.sock -port=3336 -datadir=/path/to/basedir/data -basedir=/path/to/basedir You can find out exactly what command line arguments are being used by running your test program and viewing the Connector/MXJ output. You should see a reconstruction of the command line with each command line element encapsulated in square brackets.
Then, to terminate the database, use 'kill '. You can find the PID by looking at the screen output of the mysqld command, or by reading the MysqldResource.pid file. First, I'd like you to give this a go on your laptop where we expect everything to succeed. Once it works there, second, I'd like to have you give it a try with one of the machines on which we're experiencing the 'InnoDB: Unable to lock./ibdata1, error: 11' problem.I tried this but I get another problem. If I have an empty data dir and start mysqld on the command line on my workstation, I get this output: InnoDB: The first specified data file./ibdata1 did not exist: InnoDB: a new database to be created! 060503 11:18:13 InnoDB: Setting file./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait. 060503 11:18:14 InnoDB: Log file./iblogfile0 did not exist: new to be created InnoDB: Setting log file./iblogfile0 size to 5 MB InnoDB: Database physically writes the file full: wait.
060503 11:18:14 InnoDB: Log file./iblogfile1 did not exist: new to be created InnoDB: Setting log file./iblogfile1 size to 5 MB InnoDB: Database physically writes the file full: wait. InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 060503 11:18:14 InnoDB: Started; log sequence number 0 0 060503 11:18:14 ERROR Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist However, if I use the system tables created by running mysqld through connector-mxj, I get the same 'InnoDB: Unable to lock./ibdata1, error: 11' problem after starting mysqld from the command line. On the laptop, the second procedure works perfectly.
I will try to use another mysqld executable but this will probably not help. I just remembered that I tried the connector/mxj 5.0 development release with the same problem.
Regards, Andreas. I tried this but I get another problem. If I have an empty data dir and start mysqld on the command line on my workstation, I get this output: snip 060503 11:18:14 InnoDB: Started; log sequence number 0 0 060503 11:18:14 ERROR Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist However, if I use the system tables created by running mysqld through connector-mxj, I get the same 'InnoDB: Unable to lock./ibdata1, error: 11' problem after starting mysqld from the command line.Right, we need a datadir in order for mysqld to be able to run, but if we use the datadir that was created we have the same problem? This is beginning to point to it being outside of the Connector/MXJ wrapper and something more related to the server. However it might have something to do with the datadir files provided by the Connector/MXJ wrapper. Okay let's try this: inside the connector-jar file is a 'datadir.jar' jar xvf /path/connector-mxj.jar 4-1-13/datadir.jar mkdir data cd data jar xvf./4-1-13/datadir.jar this will unpack a 'fresh' datadir for us to work with.
I will try to use another mysqld executable but this will probably not help. I just remembered that I tried the connector/mxj 5.0 development release with the same problem.We could certainly try the 5.0 development release, but since you think it may not have made a difference, let's hold off on that for a moment.
It also may be that it would work fine with a fresh data dir. But that's a just a wild guess, I'd like to see if we can establish whether it's a a Connector/MXJ wrapper specific issue or not, first. Cheers and Good Luck!