MySQL has no InnoDB support #91
Assignees
Comments
|
My motivation was to have a minimal (time and space-wise) build of MySQL that is useful. Also, I'm not sure what the memory requirements are for running InnoDB as opposed to MyISAM which is quite lean. |
|
I think people do expect to have it available as it is the only one that supports relational features, such as foreign keys. https://stackoverflow.com/questions/12971246/why-doesnt-mysqls-myisam-engine-support-foreign-keys One thing that I have noticed though with my own compiled version is that it crashes when under heavy load (especially when threading is enabled since the load can be made higher). It will dump the contents of what seems to be the registers and just stop. I'm not sure if this has to do with InnoDB or something else. I have given it 2048MB memory just to be sure that was not the problem. |
|
If you want to isolate InnoDB as being the cause of the problem, can you run the same (or equivalent) load tests with a non-InnoDB build using MyISAM and report back? I've not actually load-tested MySQL so there may be bugs lurking. |
|
I just tested it with MyISAM and it also fails when being put under heavy load. This is the error btw: |
|
@JelteF did you manage to get a symbolic stack trace? If not, can you give simple how-to-repeat instructions? |
|
I tried debugging it with the xen gdbsx stuff, but I was unable to get a back trace using gdb in that since it freezes. Running it on QEMU does not result in an error, possibly because it is much slower and the necessary load cannot be reached. |
|
On 07/03/16 14:02, Jelte Fennema wrote:
Yea Xen gdbsx not giving backtraces mirrors my experience. What about with kvm instead of qemu? |
|
I got a backtrace using kvm: I'm not entirely sure if it is the same error though as I don't see the register dump in the curses output from qemu. It does freeze however under high load, after which I pressed ctrl+c in gdb and asked for a backtrace. |
|
Another one, which looks pretty much the same except that it has a couple of |
|
Yea that's not a crash. Also, it's not necessarily a freeze, you may just have found a code path in the application without any explicit scheduling points. If you can, try single-stepping and see if you can figure out what it's looping around (or read the code and try to guess). |
|
The |
|
hmm I got another error as well (we're using ext2 as a file system): backtrace |
|
file system panics like that are almost always pilot errors: not running fsck on a dirty file system. |
|
Running |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The currently compiled version of MySQL is compiled without InnoDB support. This seems rather weird since it's a quite often used database engine.
I got the compilation working with InnoDB quite easily. The only problem that I encountered was that the mysql tmpdir (
/var/tmp) did not exist. Simply changing it to/tmpdid the trick.Is there any reason why InnoDB is not compiled in by default? If not I'll make a pull request to enable it.
The text was updated successfully, but these errors were encountered: