In the process I noticed somehow someone had managed to install a
slightly different version of mysql vs. mysql-max, so I uninstalled
everything msyql related and started over, came right up with InnoDB
support!
-
Kevin Korngut
Mr. Magoo
JANIMATION INC.
www.janimation.com <http://www.janimation.com/>
Gleb Paharenko said the following on 5/13/2005 4:34 PM:
Hello.
You have a rather old version and it is built manually. I suggest you
to upgrade to the latest release (4.1.11 or if it is impossible, then
to 4.0.24). And check if problem is solved after that.
kevin korngut <[EMAIL PROTECTED]> wrote:
[-- text/plain, encoding 7bit, charset: ISO-8859-1, 74 lines --]
I'm attempting to configure mysql with InnoDB tables and I'm running
into problems. And am using the following version of mysqld-max, Ver
4.0.18-Max for suse-linux on i686 (Source distribution)
First I uncommented the following lines in /etc/my.cnf:
# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /var/lib/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql/
innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
Then I attempted to start mysqld-max as the user mysql (mysqld-max -u
mysql) and got the following:
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose
the problem, but since we have already crashed, something is definitely
wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
= 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8434638
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Bogus stack limit or frame pointer, fp=0xbffbcea4,
stack_bottom=0x7ca35f80, thread_stack=196608, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x7bcf0ff0 is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
I then tried mysqld-max -u root which created the InnoDB file; however,
when I then attempted to start mysql I got the above error (again,
running it as the user mysql and not as root)
Anyone seen this or happen to know what's going on?
