[gentoo-user] MySQL5 and Innodb not working

[gentoo-user] MySQL5 and Innodb not working

[Thomas Balthazar]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hello,

I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R) Celeron(R)
CPU 2.66GHz.
I've added "dev-db/mysql innodb berkdb" to my package.use then I've run
emerge -1 dev-db/mysql.

I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
When I try to create a Innodb table, I get an error :
#2013 - Lost connection to MySQL server during query

After that, I cannot stop or start my MySQL server.
Everything seems to be corrupted, and all I can do is to erase all the
content of /var/lib/mysql and restart from scratch.

Has anyone heard of problems with MySQL/InnoDB/Gentoo?

Any help would be much appreciated!
Thanks in advance,
Thomas.

[-- Attachment #2: Type: text/html, Size: 744 bytes --]

Re: [gentoo-user] MySQL5 and Innodb not working

[Alexander Kirillov]

> I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R) 
> Celeron(R) CPU 2.66GHz.
> I've added "dev-db/mysql innodb berkdb" to my package.use then I've run 
> emerge -1 dev-db/mysql.
> 
> I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> When I try to create a Innodb table, I get an error :
> #2013 - Lost connection to MySQL server during query
> 
> After that, I cannot stop or start my MySQL server.
> Everything seems to be corrupted, and all I can do is to erase all the 
> content of /var/lib/mysql and restart from scratch.

Have you checked the logs in /var/log/mysql?
Anything relevant there?

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] MySQL5 and Innodb not working

[Thomas Balthazar]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

Hello,

Thanks for your answer.
You'll find my mysqld.err in attachment.

I must admin that I don't undersdand what all that mess mean.
Do you understand anything?
Thomas.

On 1/17/07, Alexander Kirillov <nevis2us@infoline.su> wrote:
>
> > I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R)
> > Celeron(R) CPU 2.66GHz.
> > I've added "dev-db/mysql innodb berkdb" to my package.use then I've run
> > emerge -1 dev-db/mysql.
> >
> > I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> > When I try to create a Innodb table, I get an error :
> > #2013 - Lost connection to MySQL server during query
> >
> > After that, I cannot stop or start my MySQL server.
> > Everything seems to be corrupted, and all I can do is to erase all the
> > content of /var/lib/mysql and restart from scratch.
>
> Have you checked the logs in /var/log/mysql?
> Anything relevant there?
>
> --
> gentoo-user@gentoo.org mailing list
>
>

[-- Attachment #1.2: Type: text/html, Size: 1375 bytes --]

[-- Attachment #2: mysqld.err --]
[-- Type: application/octet-stream, Size: 11606 bytes --]

070117 14:40:24 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 14:40:24 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 14:40:25 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 14:40:26 [Note] //usr/sbin/mysqld: ready for connections.
Version: '5.0.26-log'  socket: '//var/run/mysqld/mysqld12406.sock'  port: 0  Gentoo Linux mysql-5.0.26-r2
070117 14:40:33 [Note] //usr/sbin/mysqld: Normal shutdown

070117 14:40:33 [Note] //usr/sbin/mysqld: Shutdown complete

070117 14:53:22 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
070117 14:53:22  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
070117 14:53:23  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
070117 14:53:23  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 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
070117 14:53:24  InnoDB: Started; log sequence number 0 0
070117 14:53:24 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.26-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.26-r2
mysqld got signal 4;
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=258048
max_used_connections=2
max_connections=100
threads_connected=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x121ecc0
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...
Cannot determine thread, fp=0x43888068, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x72656e6f6d756173
New value of fp=0x121ecc0 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x122f150 = CREATE TABLE `attachments` (
  `id` int(11) NOT NULL auto_increment,
  `attached_to_id` int(11) NOT NULL default '0',
  `label` varchar(150) default NULL,
  `description` varchar(250) default NULL,
  `path` varchar(250) NOT NULL default '',
  `size` int(11) default NULL,
  `content_type` varchar(35) NOT NULL default '',
  `attach_type` varchar(255) default NULL,
  PRIMARY KEY  (`id`),
  KEY `attached_to_id` (`attached_to_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
thd->thread_id=16
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.
070117 16:58:06 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 16:58:06  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
070117 16:58:06  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43655.
InnoDB: Doing recovery: scanned up to log sequence number 0 43655
mysqld got signal 4;
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=0
read_buffer_size=258048
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 = 76399 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
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.
070117 16:59:08 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 16:59:08  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
070117 16:59:08  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43655.
InnoDB: Doing recovery: scanned up to log sequence number 0 43655
mysqld got signal 4;
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=0
read_buffer_size=258048
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 = 76399 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
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.
070117 16:59:59 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 16:59:59  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
070117 16:59:59  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43655.
InnoDB: Doing recovery: scanned up to log sequence number 0 43655
mysqld got signal 4;
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=0
read_buffer_size=258048
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 = 76399 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
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.
070117 17:00:19 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=ks34279-bin' to avoid this problem.
070117 17:00:19  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
070117 17:00:19  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43655.
InnoDB: Doing recovery: scanned up to log sequence number 0 43655
mysqld got signal 4;
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=0
read_buffer_size=258048
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 = 76399 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
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.

Re: [gentoo-user] MySQL5 and Innodb not working

[Alexander Kirillov]

mysql dies attempting to execute malformed, unknown,
or privileged instructions. You should probably run

# emerge --pretend --update --newuse --deep world
# revdep-rebuild -i

and see if this happens again.
There's also no need to start from scratch when it dies. Try

# /etc/init.d/mysql zap
# /etc/init.d/mysql start

HTH

> You'll find my mysqld.err in attachment.
> 
> I must admin that I don't undersdand what all that mess mean.
> Do you understand anything?
> Thomas.
> 
> On 1/17/07, *Alexander Kirillov* <nevis2us@infoline.su 
> <mailto:nevis2us@infoline.su>> wrote:
> 
>      > I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R)
>      > Celeron(R) CPU 2.66GHz.
>      > I've added "dev-db/mysql innodb berkdb" to my package.use then
>     I've run
>      > emerge -1 dev-db/mysql.
>      >
>      > I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
>      > When I try to create a Innodb table, I get an error :
>      > #2013 - Lost connection to MySQL server during query
>      >
>      > After that, I cannot stop or start my MySQL server.
>      > Everything seems to be corrupted, and all I can do is to erase
>     all the
>      > content of /var/lib/mysql and restart from scratch.
> 
>     Have you checked the logs in /var/log/mysql?
>     Anything relevant there?


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] MySQL5 and Innodb not working

[Thomas Balthazar]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Hello,

Thanks for your help. I do appreciate.
When I try :
# emerge --update --newuse --deep world
I get the following message :
[blocks B     ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.18.1)

How can I go further.
Thanks,
Thomas.

On 1/17/07, Alexander Kirillov <nevis2us@infoline.su> wrote:
>
>
> mysql dies attempting to execute malformed, unknown,
> or privileged instructions. You should probably run
>
> # emerge --pretend --update --newuse --deep world
> # revdep-rebuild -i
>
> and see if this happens again.
> There's also no need to start from scratch when it dies. Try
>
> # /etc/init.d/mysql zap
> # /etc/init.d/mysql start
>
> HTH
>
> > You'll find my mysqld.err in attachment.
> >
> > I must admin that I don't undersdand what all that mess mean.
> > Do you understand anything?
> > Thomas.
> >
> > On 1/17/07, *Alexander Kirillov* <nevis2us@infoline.su
> > <mailto:nevis2us@infoline.su>> wrote:
> >
> >      > I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R)
> >      > Celeron(R) CPU 2.66GHz.
> >      > I've added "dev-db/mysql innodb berkdb" to my package.use then
> >     I've run
> >      > emerge -1 dev-db/mysql.
> >      >
> >      > I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> >      > When I try to create a Innodb table, I get an error :
> >      > #2013 - Lost connection to MySQL server during query
> >      >
> >      > After that, I cannot stop or start my MySQL server.
> >      > Everything seems to be corrupted, and all I can do is to erase
> >     all the
> >      > content of /var/lib/mysql and restart from scratch.
> >
> >     Have you checked the logs in /var/log/mysql?
> >     Anything relevant there?
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2896 bytes --]

Re: [gentoo-user] MySQL5 and Innodb not working

[kashani]

Thomas Balthazar wrote:
> Hello,
> 
> I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R) 
> Celeron(R) CPU 2.66GHz.
> I've added "dev-db/mysql innodb berkdb" to my package.use then I've run 
> emerge -1 dev-db/mysql.
> 
> I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> When I try to create a Innodb table, I get an error :
> #2013 - Lost connection to MySQL server during query
> 
> After that, I cannot stop or start my MySQL server.
> Everything seems to be corrupted, and all I can do is to erase all the 
> content of /var/lib/mysql and restart from scratch.
> 
> Has anyone heard of problems with MySQL/InnoDB/Gentoo?
> 
> Any help would be much appreciated!
> Thanks in advance,
> Thomas.

Couple of things on this.

	This whole community vs enterprise is making things a bit weird at the 
moment for ebuilds. For Innodb I highly recommend going with the 
enterprise build, dev-db/mysql which you've already installed, and using 
the ~arch version of 5.0.32. It fixes a number of high concurrency/multi 
thread issues in Innodb and I'd move to it sooner rather than later.

	Have you modified your my.cnf at all? The default Innodb settings are 
TINY. Assuming you have at least a 1 GB of RAM in you machine I'd bump 
the following setting up so that you can fit real tables into Innodb.

#innodb_buffer_pool_size = 16M
innodb_buffer_pool_size = 128M

	Innodb buffers and general Mysql buffers like key, sort, etc are 
managed separately. If you're starting to migrate things into Innodb 
from Myisam you might need to decrease some of the current buffers if 
you've got limit RAM.

	The Gentoo Mysql startup script is a bit retarded when starting Mysql 
with Innodb tables turned on the first time, at least with large tables 
and log files. I use two 512M log files in production and the startup 
script fails though Mysql is actually running, it's just pausing to 
write the log files and initial ibdata files out. In your case I'd start 
and stop Mysql a few times before trying to create an Innodb table just 
to be sure that Mysql is finished with all the file writes.

I suspect the issues is Innodb not having enough memory assigned to it 
rather than the binary being borked. You might also try creating a 
simpler table in Innodb and see if you have the same issues.

I'd also recommend adding the setting, innodb_file_per_table, so that 
each table gets it's own ibdata file in the form of 
lib/mysql/$db/$table.idb. It performs better and it is a bit easier to 
tell how big your db is on disk or which db is using all your disk.

kashani
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] MySQL5 and Innodb not working

[Thomas Balthazar]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

Hello,

Thanks for your answer!
I've re-formatted the whole server and I'm re-installing Gentoo 32 bits
instead of 64 bits.
I want to see if I face the same problem.
I'll keep you posted.

Regards,
Thomas.

On 1/18/07, kashani <kashani-list@badapple.net> wrote:
>
> Thomas Balthazar wrote:
> > Hello,
> >
> > I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R)
> > Celeron(R) CPU 2.66GHz.
> > I've added "dev-db/mysql innodb berkdb" to my package.use then I've run
> > emerge -1 dev-db/mysql.
> >
> > I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> > When I try to create a Innodb table, I get an error :
> > #2013 - Lost connection to MySQL server during query
> >
> > After that, I cannot stop or start my MySQL server.
> > Everything seems to be corrupted, and all I can do is to erase all the
> > content of /var/lib/mysql and restart from scratch.
> >
> > Has anyone heard of problems with MySQL/InnoDB/Gentoo?
> >
> > Any help would be much appreciated!
> > Thanks in advance,
> > Thomas.
>
> Couple of things on this.
>
>         This whole community vs enterprise is making things a bit weird at
> the
> moment for ebuilds. For Innodb I highly recommend going with the
> enterprise build, dev-db/mysql which you've already installed, and using
> the ~arch version of 5.0.32. It fixes a number of high concurrency/multi
> thread issues in Innodb and I'd move to it sooner rather than later.
>
>         Have you modified your my.cnf at all? The default Innodb settings
> are
> TINY. Assuming you have at least a 1 GB of RAM in you machine I'd bump
> the following setting up so that you can fit real tables into Innodb.
>
> #innodb_buffer_pool_size = 16M
> innodb_buffer_pool_size = 128M
>
>         Innodb buffers and general Mysql buffers like key, sort, etc are
> managed separately. If you're starting to migrate things into Innodb
> from Myisam you might need to decrease some of the current buffers if
> you've got limit RAM.
>
>         The Gentoo Mysql startup script is a bit retarded when starting
> Mysql
> with Innodb tables turned on the first time, at least with large tables
> and log files. I use two 512M log files in production and the startup
> script fails though Mysql is actually running, it's just pausing to
> write the log files and initial ibdata files out. In your case I'd start
> and stop Mysql a few times before trying to create an Innodb table just
> to be sure that Mysql is finished with all the file writes.
>
> I suspect the issues is Innodb not having enough memory assigned to it
> rather than the binary being borked. You might also try creating a
> simpler table in Innodb and see if you have the same issues.
>
> I'd also recommend adding the setting, innodb_file_per_table, so that
> each table gets it's own ibdata file in the form of
> lib/mysql/$db/$table.idb. It performs better and it is a bit easier to
> tell how big your db is on disk or which db is using all your disk.
>
> kashani
> --
> gentoo-user@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 3738 bytes --]

Re: [gentoo-user] MySQL5 and Innodb not working

[Thomas Balthazar]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

I've re-installed a 32 version of Gentoo, installed the same components, and
it works now.
Maybe it was a problem with the 64 bits version.

Thanks to everybody for the support.
Thomas.

On 1/18/07, Thomas Balthazar <thomas.tmp@gmail.com> wrote:
>
> Hello,
>
> Thanks for your answer!
> I've re-formatted the whole server and I'm re-installing Gentoo 32 bits
> instead of 64 bits.
> I want to see if I face the same problem.
> I'll keep you posted.
>
> Regards,
> Thomas.
>
> On 1/18/07, kashani <kashani-list@badapple.net> wrote:
> >
> > Thomas Balthazar wrote:
> > > Hello,
> > >
> > > I'm using Gentoo Base System version 1.6.14 on a x86_64 Intel(R)
> > > Celeron(R) CPU 2.66GHz.
> > > I've added "dev-db/mysql innodb berkdb" to my package.use then I've
> > run
> > > emerge -1 dev-db/mysql.
> > >
> > > I've installed PHPMyAdmin that is up and running (MySQL 5.0.26).
> > > When I try to create a Innodb table, I get an error :
> > > #2013 - Lost connection to MySQL server during query
> > >
> > > After that, I cannot stop or start my MySQL server.
> > > Everything seems to be corrupted, and all I can do is to erase all the
> > > content of /var/lib/mysql and restart from scratch.
> > >
> > > Has anyone heard of problems with MySQL/InnoDB/Gentoo?
> > >
> > > Any help would be much appreciated!
> > > Thanks in advance,
> > > Thomas.
> >
> > Couple of things on this.
> >
> >         This whole community vs enterprise is making things a bit weird
> > at the
> > moment for ebuilds. For Innodb I highly recommend going with the
> > enterprise build, dev-db/mysql which you've already installed, and using
> > the ~arch version of 5.0.32. It fixes a number of high concurrency/multi
> > thread issues in Innodb and I'd move to it sooner rather than later.
> >
> >         Have you modified your my.cnf at all? The default Innodb
> > settings are
> > TINY. Assuming you have at least a 1 GB of RAM in you machine I'd bump
> > the following setting up so that you can fit real tables into Innodb.
> >
> > #innodb_buffer_pool_size = 16M
> > innodb_buffer_pool_size = 128M
> >
> >         Innodb buffers and general Mysql buffers like key, sort, etc are
> > managed separately. If you're starting to migrate things into Innodb
> > from Myisam you might need to decrease some of the current buffers if
> > you've got limit RAM.
> >
> >         The Gentoo Mysql startup script is a bit retarded when starting
> > Mysql
> > with Innodb tables turned on the first time, at least with large tables
> > and log files. I use two 512M log files in production and the startup
> > script fails though Mysql is actually running, it's just pausing to
> > write the log files and initial ibdata files out. In your case I'd start
> >
> > and stop Mysql a few times before trying to create an Innodb table just
> > to be sure that Mysql is finished with all the file writes.
> >
> > I suspect the issues is Innodb not having enough memory assigned to it
> > rather than the binary being borked. You might also try creating a
> > simpler table in Innodb and see if you have the same issues.
> >
> > I'd also recommend adding the setting, innodb_file_per_table, so that
> > each table gets it's own ibdata file in the form of
> > lib/mysql/$db/$table.idb. It performs better and it is a bit easier to
> > tell how big your db is on disk or which db is using all your disk.
> >
> > kashani
> > --
> > gentoo-user@gentoo.org mailing list
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 4509 bytes --]

Re: [gentoo-user] MySQL5 and Innodb not working

[kashani]

Thomas Balthazar wrote:
> I've re-installed a 32 version of Gentoo, installed the same components, 
> and it works now.
> Maybe it was a problem with the 64 bits version.
> 
> Thanks to everybody for the support.
> Thomas.

	That's pretty odd. I've got various versions of Mysql, 5.0.24, 5.0.26, 
5.0.30, and 5.0.32 running on IntelEMT under 64bit Gentoo and haven't 
had any issues over the past six months. Though I am not running the 
ebuild, 5.0.26-r2, that you are... I think my 5.0.26 is -r1. I'm also 
using pretty conservative settings in make.conf as I've been burned in 
the past with Mysql and overly aggressive cflags.

CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

64bit Mysql is significantly faster than 32 bit and it's nice to be able 
to address more than 3GB in Mysql. If that sort of raw performance 
matters it might be worth your time to try 64bit again, else I'd 
probably leave well enough alone.

kashani
-- 
gentoo-user@gentoo.org mailing list