InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as default.

Can anybody help me?

Regards,

Ben







--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: InnoDB problems under 5.1.9

2006-05-23 Thread Logan, David (SST - Adelaide)
Hi Ben,

Try doing

SHOW ENGINES;

and see what it says. It should say InnoDB is supported, if not then it
hasn't compiled in.

Regards

---
** _/ **  David Logan 
***   _/ ***  ITO Delivery Specialist - Database
*_/*  Hewlett-Packard Australia Ltd
_/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
   _/  _/  _/  _/     Desk:   +618 8408 4273
  _/  _/  _/_/_/  Mobile: 0417 268 665
*_/   **
**  _/    Postal: 148 Frome Street,
   _/ **  Adelaide SA 5001
  Australia 
invent   
---

-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 May 2006 4:57 PM
To: mysql@lists.mysql.com
Subject: InnoDB problems under 5.1.9

Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.

I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
   a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
   `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*

I am using the large table .cnf file.  Everything else is much as
default.

Can anybody help me?

Regards,

Ben







-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Logan, David (SST - Adelaide) wrote:

Hi Ben,

Try doing

SHOW ENGINES;


Here: (pertinent cols only)

++--+--+-++
| Engine | Support  | Transactions | XA  | Savepoints |
++--+--+-++
| CSV| YES  | NO   | NO  | NO |
| MEMORY | YES  | NO   | NO  | NO |
| MRG_MYISAM | YES  | NO   | NO  | NO |
| InnoDB | DISABLED | YES  | YES | YES|
| BLACKHOLE  | YES  | NO   | NO  | NO |
| MyISAM | DEFAULT  | NO   | NO  | NO |
| BerkeleyDB | DISABLED | YES  | NO  | YES|
| ARCHIVE| YES  | NO   | NO  | NO |
++--+--+-++

Ok, now I believe this does mean I have compiled the InnoDB.

Just to save me trawling though the manual, can you tell me how I should 
enable InnoDB?


Thanks for the info!

Ben







and see what it says. It should say InnoDB is supported, if not then it
hasn't compiled in.

Regards

---
** _/ **  David Logan 
***   _/ ***  ITO Delivery Specialist - Database

*_/*  Hewlett-Packard Australia Ltd
_/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
   _/  _/  _/  _/     Desk:   +618 8408 4273
  _/  _/  _/_/_/  Mobile: 0417 268 665
*_/   **
**  _/    Postal: 148 Frome Street,

   _/ **  Adelaide SA 5001
  Australia 
invent   
---


-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 May 2006 4:57 PM

To: mysql@lists.mysql.com
Subject: InnoDB problems under 5.1.9

Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
   a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
   `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as
default.

Can anybody help me?

Regards,

Ben










--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: InnoDB problems under 5.1.9

2006-05-23 Thread Logan, David (SST - Adelaide)
Hi Ben,

I thought the InnoDB engine was included without having to set a
./configure option. On my latest build (admittedly a 5.0.18 one) InnoDB
was enabled without setting any ./configure option.

My options were

hambone /usr/dev/src/mysql-5.0.18 $ cat ../../build_scripts/mysql-5.0.18
#!/bin/bash

./configure \
--prefix=/usr/local/mysql-5.0.18 \
--enable-thread-safe-client \
--with-unix-socket-path=/tmp \
--with-openssl \
--with-example-storage-engine \
--with-archive-storage-engine \
--with-csv-storage-engine \
--with-blackhole-storage-engine \
--with-ndbcluster \
--with-ndb-test \
--with-ndb-port=3510 \
--with-ndb-port-base=3710 \
--with-federated-storage-engine

This worked fine. If I get time later, I may give it a punt with your
version. Sorry I can't be of more help.

Regards

---
** _/ **  David Logan 
***   _/ ***  ITO Delivery Specialist - Database
*_/*  Hewlett-Packard Australia Ltd
_/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
   _/  _/  _/  _/     Desk:   +618 8408 4273
  _/  _/  _/_/_/  Mobile: 0417 268 665
*_/   **
**  _/    Postal: 148 Frome Street,
   _/ **  Adelaide SA 5001
  Australia 
invent   
---

-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 May 2006 5:50 PM
To: Logan, David (SST - Adelaide)
Cc: mysql@lists.mysql.com
Subject: Re: InnoDB problems under 5.1.9

Logan, David (SST - Adelaide) wrote:
 Hi Ben,
 
 Try doing
 
 SHOW ENGINES;

Here: (pertinent cols only)

++--+--+-++
| Engine | Support  | Transactions | XA  | Savepoints |
++--+--+-++
| CSV| YES  | NO   | NO  | NO |
| MEMORY | YES  | NO   | NO  | NO |
| MRG_MYISAM | YES  | NO   | NO  | NO |
| InnoDB | DISABLED | YES  | YES | YES|
| BLACKHOLE  | YES  | NO   | NO  | NO |
| MyISAM | DEFAULT  | NO   | NO  | NO |
| BerkeleyDB | DISABLED | YES  | NO  | YES|
| ARCHIVE| YES  | NO   | NO  | NO |
++--+--+-++

Ok, now I believe this does mean I have compiled the InnoDB.

Just to save me trawling though the manual, can you tell me how I should

enable InnoDB?

Thanks for the info!

Ben





 
 and see what it says. It should say InnoDB is supported, if not then
it
 hasn't compiled in.
 
 Regards
 
 ---
 ** _/ **  David Logan 
 ***   _/ ***  ITO Delivery Specialist - Database
 *_/*  Hewlett-Packard Australia Ltd
 _/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
    _/  _/  _/  _/     Desk:   +618 8408 4273
   _/  _/  _/_/_/  Mobile: 0417 268 665
 *_/   **
 **  _/    Postal: 148 Frome Street,
    _/ **  Adelaide SA 5001
   Australia 
 invent   
 ---
 
 -Original Message-
 From: Ben Clewett [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, 23 May 2006 4:57 PM
 To: mysql@lists.mysql.com
 Subject: InnoDB problems under 5.1.9
 
 Dear MySQL,
 
 I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
 InnoDB tables respected.
 
 I have used the correct compilation flag (--with-innodb).
 SHOW VARIABLES; lists all the usual innodb variables.
 The innodb table space has been created in ~/var/ibdata1.
 
 But if I enter:
 
 CREATE TABLE a (
a int NOT NULL PRIMARY KEY
 ) ENGINE=InnoDB;
 
 SHOW CREATE TABLE a;
 
 CREATE TABLE `a` (
`a` int(10) NOT NULL PRIMARY KEY
 ) ENGINE=MyISAM
 
 As you can see, an InnoDB has become an MyISAM and will be stored in 
 ~/var/test/a.*
 
 I am using the large table .cnf file.  Everything else is much as
 default.
 
 Can anybody help me?
 
 Regards,
 
 Ben
 
 
 
 
 
 
 


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Very very odd.

I am compiling with the --use-innodb option.  I am starting mysqld with 
the --innodb option.


The table space is created for innodb.  But SHOW ENGINE shows InnoDB = 
DISABLED.


There are relevant no errors in the .err file.

Thanks for sending me your compilation options.  I'll give those a go 
and see what happens...


Regards,

Ben.



Logan, David (SST - Adelaide) wrote:

Hi Ben,

I thought the InnoDB engine was included without having to set a
./configure option. On my latest build (admittedly a 5.0.18 one) InnoDB
was enabled without setting any ./configure option.

My options were

hambone /usr/dev/src/mysql-5.0.18 $ cat ../../build_scripts/mysql-5.0.18
#!/bin/bash

./configure \
--prefix=/usr/local/mysql-5.0.18 \
--enable-thread-safe-client \
--with-unix-socket-path=/tmp \
--with-openssl \
--with-example-storage-engine \
--with-archive-storage-engine \
--with-csv-storage-engine \
--with-blackhole-storage-engine \
--with-ndbcluster \
--with-ndb-test \
--with-ndb-port=3510 \
--with-ndb-port-base=3710 \
--with-federated-storage-engine

This worked fine. If I get time later, I may give it a punt with your
version. Sorry I can't be of more help.

Regards

---
** _/ **  David Logan 
***   _/ ***  ITO Delivery Specialist - Database

*_/*  Hewlett-Packard Australia Ltd
_/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
   _/  _/  _/  _/     Desk:   +618 8408 4273
  _/  _/  _/_/_/  Mobile: 0417 268 665
*_/   **
**  _/    Postal: 148 Frome Street,

   _/ **  Adelaide SA 5001
  Australia 
invent   
---


-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 May 2006 5:50 PM

To: Logan, David (SST - Adelaide)
Cc: mysql@lists.mysql.com
Subject: Re: InnoDB problems under 5.1.9

Logan, David (SST - Adelaide) wrote:

Hi Ben,

Try doing

SHOW ENGINES;


Here: (pertinent cols only)

++--+--+-++
| Engine | Support  | Transactions | XA  | Savepoints |
++--+--+-++
| CSV| YES  | NO   | NO  | NO |
| MEMORY | YES  | NO   | NO  | NO |
| MRG_MYISAM | YES  | NO   | NO  | NO |
| InnoDB | DISABLED | YES  | YES | YES|
| BLACKHOLE  | YES  | NO   | NO  | NO |
| MyISAM | DEFAULT  | NO   | NO  | NO |
| BerkeleyDB | DISABLED | YES  | NO  | YES|
| ARCHIVE| YES  | NO   | NO  | NO |
++--+--+-++

Ok, now I believe this does mean I have compiled the InnoDB.

Just to save me trawling though the manual, can you tell me how I should

enable InnoDB?

Thanks for the info!

Ben






and see what it says. It should say InnoDB is supported, if not then

it

hasn't compiled in.

Regards

---
** _/ **  David Logan 
***   _/ ***  ITO Delivery Specialist - Database

*_/*  Hewlett-Packard Australia Ltd
_/_/_/  _/_/_/    E-Mail: [EMAIL PROTECTED]
   _/  _/  _/  _/     Desk:   +618 8408 4273
  _/  _/  _/_/_/  Mobile: 0417 268 665
*_/   **
**  _/    Postal: 148 Frome Street,

   _/ **  Adelaide SA 5001
  Australia 
invent   
---


-Original Message-
From: Ben Clewett [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 23 May 2006 4:57 PM

To: mysql@lists.mysql.com
Subject: InnoDB problems under 5.1.9

Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
   a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
   `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as
default.

Can anybody help me?

Regards,

Ben













--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http

Re: InnoDB problems under 5.1.9

2006-05-23 Thread gerald_clark

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the command 
line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the command 
line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Dan Buettner
Ben, what does SHOW ENGINES show you?  It should list all known storage 
engines and indicate whether your MySQL install supports it or not.


Here's mine (5.0.21) for comparison; I was able to create a test table 
as InnoDB and the SHOW CREATE showed it as InnoDB:


- show engines;
++-++
| Engine | Support | Comment 
|

++-++
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great 
performance |
| MEMORY | YES | Hash based, stored in memory, useful for 
temporary tables  |
| InnoDB | YES | Supports transactions, row-level locking, and 
foreign keys |
| BerkeleyDB | NO  | Supports transactions and page-level locking 
|
| BLACKHOLE  | NO  | /dev/null storage engine (anything you write to 
it disappears) |
| EXAMPLE| NO  | Example storage engine 
|
| ARCHIVE| YES | Archive storage engine 
|
| CSV| NO  | CSV storage engine 
|
| ndbcluster | NO  | Clustered, fault-tolerant, memory-based tables 
|
| FEDERATED  | NO  | Federated MySQL storage engine 
|
| MRG_MYISAM | YES | Collection of identical MyISAM tables 
|
| ISAM   | NO  | Obsolete storage engine 
|

++-++
12 rows in set (0.00 sec)




Ben Clewett wrote:

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the command 
line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.






--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Hi Dan,

This is what I have.  What does this mean with regards to InnoDB?

++--++--+-++
| Engine | Support  | Comment 
 | Transactions | XA  | Savepoints |

++--++--+-++
| CSV| YES  | CSV storage engine 
 | NO   | NO  | NO |
| MEMORY | YES  | Hash based, stored in memory, useful for 
temporary tables  | NO   | NO  | NO |
| MRG_MYISAM | YES  | Collection of identical MyISAM tables 
 | NO   | NO  | NO |
| InnoDB | DISABLED | Supports transactions, row-level locking, and 
foreign keys | YES  | YES | YES|
| BLACKHOLE  | YES  | /dev/null storage engine (anything you write 
to it disappears) | NO   | NO  | NO |
| MyISAM | DEFAULT  | Default engine as of MySQL 3.23 with great 
performance | NO   | NO  | NO |
| BerkeleyDB | DISABLED | Supports transactions and page-level locking 
 | YES  | NO  | YES|
| ARCHIVE| YES  | Archive storage engine 
 | NO   | NO  | NO |

++--++--+-++

Thanks,


Dan Buettner wrote:
Ben, what does SHOW ENGINES show you?  It should list all known storage 
engines and indicate whether your MySQL install supports it or not.


Here's mine (5.0.21) for comparison; I was able to create a test table 
as InnoDB and the SHOW CREATE showed it as InnoDB:


- show engines;
++-++ 


| Engine | Support | Comment |
++-++ 

| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great 
performance |
| MEMORY | YES | Hash based, stored in memory, useful for 
temporary tables  |
| InnoDB | YES | Supports transactions, row-level locking, and 
foreign keys |
| BerkeleyDB | NO  | Supports transactions and page-level locking 
|
| BLACKHOLE  | NO  | /dev/null storage engine (anything you write to 
it disappears) |

| EXAMPLE| NO  | Example storage engine |
| ARCHIVE| YES | Archive storage engine |
| CSV| NO  | CSV storage engine |
| ndbcluster | NO  | Clustered, fault-tolerant, memory-based tables 
|

| FEDERATED  | NO  | Federated MySQL storage engine |
| MRG_MYISAM | YES | Collection of identical MyISAM tables 
|

| ISAM   | NO  | Obsolete storage engine |
++-++ 


12 rows in set (0.00 sec)




Ben Clewett wrote:

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the command 
line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored in 
~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.









--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Dan Buettner
Ben, looks like you've either got it disabled in my.cnf or with a 
startup flag, or you've not set all the needed options for InnoDB.


See http://dev.mysql.com/doc/refman/5.0/en/mysqld-max.html, near the 
bottom of the page it explains what DISABLED means and refers you to the 
error log for messages.


Dan

Ben Clewett wrote:

Hi Dan,

This is what I have.  What does this mean with regards to InnoDB?

++--++--+-++ 

| Engine | Support  | Comment  | Transactions | XA  
| Savepoints |
++--++--+-++ 

| CSV| YES  | CSV storage engine  | 
NO   | NO  | NO |
| MEMORY | YES  | Hash based, stored in memory, useful for 
temporary tables  | NO   | NO  | NO |
| MRG_MYISAM | YES  | Collection of identical MyISAM tables 
 | NO   | NO  | NO |
| InnoDB | DISABLED | Supports transactions, row-level locking, and 
foreign keys | YES  | YES | YES|
| BLACKHOLE  | YES  | /dev/null storage engine (anything you write 
to it disappears) | NO   | NO  | NO |
| MyISAM | DEFAULT  | Default engine as of MySQL 3.23 with great 
performance | NO   | NO  | NO |
| BerkeleyDB | DISABLED | Supports transactions and page-level locking 
 | YES  | NO  | YES|
| ARCHIVE| YES  | Archive storage engine  | 
NO   | NO  | NO |
++--++--+-++ 



Thanks,


Dan Buettner wrote:
Ben, what does SHOW ENGINES show you?  It should list all known 
storage engines and indicate whether your MySQL install supports it or 
not.


Here's mine (5.0.21) for comparison; I was able to create a test table 
as InnoDB and the SHOW CREATE showed it as InnoDB:


- show engines;
++-++ 


| Engine | Support | Comment |
++-++ 

| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great 
performance |
| MEMORY | YES | Hash based, stored in memory, useful for 
temporary tables  |
| InnoDB | YES | Supports transactions, row-level locking, and 
foreign keys |
| BerkeleyDB | NO  | Supports transactions and page-level locking 
|
| BLACKHOLE  | NO  | /dev/null storage engine (anything you write 
to it disappears) |

| EXAMPLE| NO  | Example storage engine |
| ARCHIVE| YES | Archive storage engine |
| CSV| NO  | CSV storage engine |
| ndbcluster | NO  | Clustered, fault-tolerant, memory-based 
tables |

| FEDERATED  | NO  | Federated MySQL storage engine |
| MRG_MYISAM | YES | Collection of identical MyISAM tables 
|

| ISAM   | NO  | Obsolete storage engine |
++-++ 


12 rows in set (0.00 sec)




Ben Clewett wrote:

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the command 
line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't get 
InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored 
in ~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.











--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Thanks for the excellent reference, this gives me a lot to go on.

My server is in bits at the moment, I'll let you know when it's up again!

Ben

Dan Buettner wrote:
Ben, looks like you've either got it disabled in my.cnf or with a 
startup flag, or you've not set all the needed options for InnoDB.


See http://dev.mysql.com/doc/refman/5.0/en/mysqld-max.html, near the 
bottom of the page it explains what DISABLED means and refers you to the 
error log for messages.


Dan

Ben Clewett wrote:

Hi Dan,

This is what I have.  What does this mean with regards to InnoDB?

++--++--+-++ 

| Engine | Support  | Comment  | Transactions | 
XA  | Savepoints |
++--++--+-++ 

| CSV| YES  | CSV storage engine  | 
NO   | NO  | NO |
| MEMORY | YES  | Hash based, stored in memory, useful for 
temporary tables  | NO   | NO  | NO |
| MRG_MYISAM | YES  | Collection of identical MyISAM tables 
 | NO   | NO  | NO |
| InnoDB | DISABLED | Supports transactions, row-level locking, 
and foreign keys | YES  | YES | YES|
| BLACKHOLE  | YES  | /dev/null storage engine (anything you write 
to it disappears) | NO   | NO  | NO |
| MyISAM | DEFAULT  | Default engine as of MySQL 3.23 with great 
performance | NO   | NO  | NO |
| BerkeleyDB | DISABLED | Supports transactions and page-level locking 
 | YES  | NO  | YES|
| ARCHIVE| YES  | Archive storage engine  | 
NO   | NO  | NO |
++--++--+-++ 



Thanks,


Dan Buettner wrote:
Ben, what does SHOW ENGINES show you?  It should list all known 
storage engines and indicate whether your MySQL install supports it 
or not.


Here's mine (5.0.21) for comparison; I was able to create a test 
table as InnoDB and the SHOW CREATE showed it as InnoDB:


- show engines;
++-++ 


| Engine | Support | Comment |
++-++ 

| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great 
performance |
| MEMORY | YES | Hash based, stored in memory, useful for 
temporary tables  |
| InnoDB | YES | Supports transactions, row-level locking, 
and foreign keys |
| BerkeleyDB | NO  | Supports transactions and page-level locking 
|
| BLACKHOLE  | NO  | /dev/null storage engine (anything you write 
to it disappears) |

| EXAMPLE| NO  | Example storage engine |
| ARCHIVE| YES | Archive storage engine |
| CSV| NO  | CSV storage engine |
| ndbcluster | NO  | Clustered, fault-tolerant, memory-based 
tables |
| FEDERATED  | NO  | Federated MySQL storage 
engine |
| MRG_MYISAM | YES | Collection of identical MyISAM tables 
|

| ISAM   | NO  | Obsolete storage engine |
++-++ 


12 rows in set (0.00 sec)




Ben Clewett wrote:

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the 
command line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't 
get InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored 
in ~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.














--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems under 5.1.9

2006-05-23 Thread Ben Clewett

Thanks for the tip.

Simple problem, my innodb data file was created with the default my.cnf.

When I started it with the large_table version, it used different innodb 
table space size.  Therefore would not start :)


Cheers,

Ben


Dan Buettner wrote:
Ben, looks like you've either got it disabled in my.cnf or with a 
startup flag, or you've not set all the needed options for InnoDB.


See http://dev.mysql.com/doc/refman/5.0/en/mysqld-max.html, near the 
bottom of the page it explains what DISABLED means and refers you to the 
error log for messages.


Dan

Ben Clewett wrote:

Hi Dan,

This is what I have.  What does this mean with regards to InnoDB?

++--++--+-++ 

| Engine | Support  | Comment  | Transactions | 
XA  | Savepoints |
++--++--+-++ 

| CSV| YES  | CSV storage engine  | 
NO   | NO  | NO |
| MEMORY | YES  | Hash based, stored in memory, useful for 
temporary tables  | NO   | NO  | NO |
| MRG_MYISAM | YES  | Collection of identical MyISAM tables 
 | NO   | NO  | NO |
| InnoDB | DISABLED | Supports transactions, row-level locking, 
and foreign keys | YES  | YES | YES|
| BLACKHOLE  | YES  | /dev/null storage engine (anything you write 
to it disappears) | NO   | NO  | NO |
| MyISAM | DEFAULT  | Default engine as of MySQL 3.23 with great 
performance | NO   | NO  | NO |
| BerkeleyDB | DISABLED | Supports transactions and page-level locking 
 | YES  | NO  | YES|
| ARCHIVE| YES  | Archive storage engine  | 
NO   | NO  | NO |
++--++--+-++ 



Thanks,


Dan Buettner wrote:
Ben, what does SHOW ENGINES show you?  It should list all known 
storage engines and indicate whether your MySQL install supports it 
or not.


Here's mine (5.0.21) for comparison; I was able to create a test 
table as InnoDB and the SHOW CREATE showed it as InnoDB:


- show engines;
++-++ 


| Engine | Support | Comment |
++-++ 

| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great 
performance |
| MEMORY | YES | Hash based, stored in memory, useful for 
temporary tables  |
| InnoDB | YES | Supports transactions, row-level locking, 
and foreign keys |
| BerkeleyDB | NO  | Supports transactions and page-level locking 
|
| BLACKHOLE  | NO  | /dev/null storage engine (anything you write 
to it disappears) |

| EXAMPLE| NO  | Example storage engine |
| ARCHIVE| YES | Archive storage engine |
| CSV| NO  | CSV storage engine |
| ndbcluster | NO  | Clustered, fault-tolerant, memory-based 
tables |
| FEDERATED  | NO  | Federated MySQL storage 
engine |
| MRG_MYISAM | YES | Collection of identical MyISAM tables 
|

| ISAM   | NO  | Obsolete storage engine |
++-++ 


12 rows in set (0.00 sec)




Ben Clewett wrote:

Hi Gerald,

I am sure I don't have this in my my.cfg.  I am using the supplied 
'large table' my.cfg.  The *only* innodb option I have is the 
command line parameter to mysqld:


--innodb

If anybody has any other options about how to get innodb working in 
5.1.9, I'd be very interested!


Thanks for the advise,

Ben


gerald_clark wrote:

Ben Clewett wrote:


Dear MySQL,

I've installed 5.1.9 from source on a SUSE 10 box.  But I can't 
get InnoDB tables respected.


I have used the correct compilation flag (--with-innodb).
SHOW VARIABLES; lists all the usual innodb variables.
The innodb table space has been created in ~/var/ibdata1.

But if I enter:

CREATE TABLE a (
  a int NOT NULL PRIMARY KEY
) ENGINE=InnoDB;

SHOW CREATE TABLE a;

CREATE TABLE `a` (
  `a` int(10) NOT NULL PRIMARY KEY
) ENGINE=MyISAM

As you can see, an InnoDB has become an MyISAM and will be stored 
in ~/var/test/a.*


I am using the large table .cnf file.  Everything else is much as 
default.


Can anybody help me?

Regards,

Ben


make sure you don't have
skip--innodb
in your my.cnf file.














--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDB problems ...

2005-03-31 Thread Ware Adams
On Mar 31, 2005, at 1:13 AM, Rafal Kedziorski wrote:
I'm working with JBoss and MySQL 4.0.22 (and 4.0.18 on Testsystem). 
But under the load, I get sometimes Exceptions like this:

java.sql.SQLException: Deadlock found when trying to get lock; Try 
restarting transaction message from server: Lock wait timeout 
exceeded; Try restarting transaction

It looks like InnoDB problem. Is there a way to find out why this 
happens?
InnoDB has detected a deadlock, which is described pretty well in the 
InnoDB manual (at innodb.com or the mysql.com version of the manual).

When this happens run
show innodb status\G
from the command line client.  InnoDB will print out status info, and 
at the top will be details of the last detected deadlock which will 
show the conflicting queries.  You then need to modify the queries or 
the application so it doesn't happen.

--Ware
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]


InnoDB problems ...

2005-03-30 Thread Rafal Kedziorski
Hi,
I'm working with JBoss and MySQL 4.0.22 (and 4.0.18 on Testsystem). But 
under the load, I get sometimes Exceptions like this:

java.sql.SQLException: Deadlock found when trying to get lock; Try 
restarting transaction message from server: Lock wait timeout exceeded; 
Try restarting transaction

It looks like InnoDB problem. Is there a way to find out why this happens?
This is my mysql-ds.xml:
?xml version=1.0 encoding=UTF-8?
datasources
  local-tx-datasource
jndi-nameOmaDS/jndi-name
connection-urljdbc:mysql://localhost/ofa/connection-url
driver-classcom.mysql.jdbc.Driver/driver-class
user-nameuser/user-name
passwordxxx/password
connection-property name=autoReconnecttrue/connection-property
!-- 
transaction-isolationTRANSACTION_READ_COMMITTED/transaction-isolation --

!--pooling parameters--
min-pool-size25/min-pool-size
max-pool-size100/max-pool-size
blocking-timeout-millis5000/blocking-timeout-millis
idle-timeout-minutes15/idle-timeout-minutes
prepared-statement-cache-size1000/prepared-statement-cache-size
  /local-tx-datasource
/datasources
Our beans are configured to make SELECT ... FOR UPDATE calls.
Best Regards,
Rafal 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]


Re: BIG InnoDB problems!

2005-01-10 Thread Heikki Tuuri
Andy,
- Alkuperäinen viesti - 
Lähettäjä: Andy Davidson [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Lähetetty: Tuesday, January 04, 2005 5:02 PM
Aihe: Re: BIG InnoDB problems!

...¨
On Mon, 3 Jan 2005, Heikki Tuuri wrote:
the problem you had was serious corruption in the ibdata files. It can
be caused by an InnoDB bug, an OS bug, faulty hardware, and also by an
error of the database administrator.
Linux kernels 2.4.18 seemed to have corruption issues.
Hi, Heikki --
Is this something that you ONLY seem to see in 2.4.18, or is it all
kernels up to 2.4.18 (excluding .15 of course), or all kernels since ?
kernels 2.4.x, where x  = 18.
How have you reached a conclusion about this kernel version, please ?
2.4.18 is the stock kernel in recent Debians, for instance, and it seems
that it's capable of stable MySQL/InnoDB environments.  Though if I am
wrong, I would be delighted to know why so that we can change things
quickly. ;-)
Red Hat kernels 2.4.18 are suspect. I have little feedback from 
Debian-2.4.18.

--
Andy Davidson
Systems Administrator
Ebuyer UK Ltd., 201 Woodbourn Road, Sheffield, S9 3LR
Regards,
Heikki 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]


BIG INNODB Problems solved.. I think

2005-01-07 Thread jsf
A few days ago I did the following:

Turned off MySQL.  Installed 4.1.8a, then I  went into the directory
where all of the database files are located.  I moved everything
having to do with INNODB tables and logs into another location for
safekeeping.  Then I started up the new version of MySQL.

I had our developer basically start from scratch (using her stored
text files)...  so far, there have been no problems...

We're keeping our fingers crossed!

:-)

J.

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: BIG InnoDB problems!

2005-01-03 Thread Heikki Tuuri
Joshua,
the stack trace below shows that you are trying to drop a database? Why?
If you can, you should use SELECT ... INTO OUTFILE to save of your tables 
what you can save, then rebuild the whole InnoDB tablespace, and import the 
tables back to MySQL.

The .err file below starts from a situation where you have already set 
innodb_force_recovery to 5.


5 (SRV_FORCE_NO_UNDO_LOG_SCAN) Do not look at undo logs when starting the 
database: InnoDB will treat even incomplete transactions as committed.


Was the original problem the same as what we see below? The history list of 
InnoDB in the ibdata files seems to be corrupt. The only way to fix that 
kind of corruption is to rebuild the whole tablespace.

Best regards,
Heikki
Innobase Oy
InnoDB - transactions, row level locking, and foreign keys for MySQL
InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM 
tables
http://www.innodb.com/order.php

Order MySQL support from http://www.mysql.com/support/index.html
- Alkuperäinen viesti - 
Lähettäjä: jsf [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Kopio: mysql@lists.mysql.com
Lähetetty: Friday, December 31, 2004 5:21 PM
Aihe: Re: BIG InnoDB problems!


Greetings Heikki and Happy New Year!
Here's what I got.  I hope it's useful.
beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n 
mysqld.stack
0x815f0cf handle_segfault + 575
0xe420 _end + -138916432
0x82e71d5 buf_read_page + 165
0x82e71d5 buf_read_page + 165
0x82db68f buf_page_get_gen + 175
0x830479f flst_insert_before + 239
0x8304cc8 flst_add_first + 152
0x82be800 trx_purge_add_update_undo_to_history + 624
0x82d14a6 trx_undo_update_cleanup + 38
0x82ccafb trx_commit_off_kernel + 363
0x82cd865 trx_sig_start_handle + 1109
0x826232b que_run_threads + 2299
0x827915a row_drop_table_for_mysql + 2314
0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
0x81ef33c _Z15ha_delete_table7db_typePKc + 60
0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb + 93
0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
0x81796cb _Z21mysql_execute_commandP3THD + 19339
0x817c1b4 _Z11mysql_parseP3THDPcj + 484
0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
0x817f137 handle_one_connection + 2391
0x401619ed _end + 936280957
0x403519ca _end + 938312538

p.s.  the whole error file is only 301 lines long.  If you wish I
could send it to you...
Here's a segment from lines 1 - 41:
041230 11:12:10  mysqld started
041230 11:12:10  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...
041230 11:12:10  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 241342003.
InnoDB: Doing recovery: scanned up to log sequence number 0 241342036
InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.47
041230 11:12:10  InnoDB: Flushing modified pages from the buffer pool...
041230 11:12:10  InnoDB: Started; log sequence number 0 241342036
InnoDB: !!! innodb_force_recovery is set to 5 !!!
041230 11:12:10 [Warning] mysql.user table is not updated to new
password format; Disabling new password usage until
mysql_fix_privilege_tables is run
041230 11:12:10 [Warning] Can't open and lock time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without
them
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
distribution
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: Error: trying to access page number 940269659 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
041230 16:42:57InnoDB: Assertion failure in thread 1124068272 in file
fil0fil.c line 3729
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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

Re: BIG InnoDB problems!

2005-01-03 Thread jsf
Hi Heikki,

Please see below...


On Mon, 3 Jan 2005 15:14:12 +0200, Heikki Tuuri [EMAIL PROTECTED] wrote:
 Joshua,
 
 the stack trace below shows that you are trying to drop a database? Why?

At that point, I'd heard from our developer of so many problems I
figured what I would do is test things out.  I created a database.  I
created a table in the database as an InnoDB .  I tried to insert data
into it and was unsuccessful.. I tried a few more things.. all
unsuccessful, so I figured I'd just try to drop the database. But I
couldn't do that either.

 
 If you can, you should use SELECT ... INTO OUTFILE to save of your tables
 what you can save, then rebuild the whole InnoDB tablespace, and import the
 tables back to MySQL.

I'm going to have to 'go to school' on InnoDB tablespace.  I have only
the most rudimentary understanding of what you've written here.


 
 The .err file below starts from a situation where you have already set
 innodb_force_recovery to 5.
 
 

Is that bad?

 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) Do not look at undo logs when starting the
 database: InnoDB will treat even incomplete transactions as committed.
 
 
 Was the original problem the same as what we see below? The history list of
 InnoDB in the ibdata files seems to be corrupt. The only way to fix that
 kind of corruption is to rebuild the whole tablespace.

Is there a tutorial on rebuilding the tablespace?  or deleting the
table space and starting over?

 
 Best regards,
 
 Heikki
 Innobase Oy
 InnoDB - transactions, row level locking, and foreign keys for MySQL
 InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM
 tables
 http://www.innodb.com/order.php
 
 Order MySQL support from http://www.mysql.com/support/index.html
 
 - Alkuperäinen viesti -
 Lähettäjä: jsf [EMAIL PROTECTED]
 Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
 Kopio: mysql@lists.mysql.com
 Lähetetty: Friday, December 31, 2004 5:21 PM
 Aihe: Re: BIG InnoDB problems!
 
 
  Greetings Heikki and Happy New Year!
 
  Here's what I got.  I hope it's useful.
 
  beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n
  mysqld.stack
  0x815f0cf handle_segfault + 575
  0xe420 _end + -138916432
  0x82e71d5 buf_read_page + 165
  0x82e71d5 buf_read_page + 165
  0x82db68f buf_page_get_gen + 175
  0x830479f flst_insert_before + 239
  0x8304cc8 flst_add_first + 152
  0x82be800 trx_purge_add_update_undo_to_history + 624
  0x82d14a6 trx_undo_update_cleanup + 38
  0x82ccafb trx_commit_off_kernel + 363
  0x82cd865 trx_sig_start_handle + 1109
  0x826232b que_run_threads + 2299
  0x827915a row_drop_table_for_mysql + 2314
  0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
  0x81ef33c _Z15ha_delete_table7db_typePKc + 60
  0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
  0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb + 93
  0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
  0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
  0x81796cb _Z21mysql_execute_commandP3THD + 19339
  0x817c1b4 _Z11mysql_parseP3THDPcj + 484
  0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
  0x817f137 handle_one_connection + 2391
  0x401619ed _end + 936280957
  0x403519ca _end + 938312538
 
 
  p.s.  the whole error file is only 301 lines long.  If you wish I
  could send it to you...
 
  Here's a segment from lines 1 - 41:
 
  041230 11:12:10  mysqld started
  041230 11:12:10  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...
  041230 11:12:10  InnoDB: Starting log scan based on checkpoint at
  InnoDB: log sequence number 0 241342003.
  InnoDB: Doing recovery: scanned up to log sequence number 0 241342036
  InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.47
  041230 11:12:10  InnoDB: Flushing modified pages from the buffer pool...
  041230 11:12:10  InnoDB: Started; log sequence number 0 241342036
  InnoDB: !!! innodb_force_recovery is set to 5 !!!
  041230 11:12:10 [Warning] mysql.user table is not updated to new
  password format; Disabling new password usage until
  mysql_fix_privilege_tables is run
  041230 11:12:10 [Warning] Can't open and lock time zone table: Table
  'mysql.time_zone_leap_second' doesn't exist trying to live without
  them
  /usr/local/libexec/mysqld: ready for connections.
  Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
  distribution
  InnoDB: A new raw disk partition was initialized or
  InnoDB: innodb_force_recovery is on: we do not allow
  InnoDB: database modifications by the user. Shut down
  InnoDB: mysqld and edit my.cnf so that newraw is replaced
  InnoDB: with raw, and innodb_force_... is removed.
  InnoDB: Error: trying to access page number 940269659 in space 0,
  InnoDB: space name ./ibdata1,
  InnoDB: which is outside the tablespace

Re: BIG InnoDB problems!

2005-01-03 Thread Heikki Tuuri
Joshua,
about dumping tables from a corrupt database, see:
http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
This describes how to remove the whole InnoDB database:
http://dev.mysql.com/doc/mysql/en/Error_creating_InnoDB.html
Be very careful. You do not want to lose your valuable data.
Regards,
Heikki
- Alkuperäinen viesti - 
Lähettäjä: jsf [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Kopio: mysql@lists.mysql.com
Lähetetty: Monday, January 03, 2005 4:31 PM
Aihe: Re: BIG InnoDB problems!

Hi Heikki,
Please see below...
On Mon, 3 Jan 2005 15:14:12 +0200, Heikki Tuuri [EMAIL PROTECTED] 
wrote:
Joshua,
the stack trace below shows that you are trying to drop a database? Why?
At that point, I'd heard from our developer of so many problems I
figured what I would do is test things out.  I created a database.  I
created a table in the database as an InnoDB .  I tried to insert data
into it and was unsuccessful.. I tried a few more things.. all
unsuccessful, so I figured I'd just try to drop the database. But I
couldn't do that either.
If you can, you should use SELECT ... INTO OUTFILE to save of your tables
what you can save, then rebuild the whole InnoDB tablespace, and import 
the
tables back to MySQL.
I'm going to have to 'go to school' on InnoDB tablespace.  I have only
the most rudimentary understanding of what you've written here.

The .err file below starts from a situation where you have already set
innodb_force_recovery to 5.

Is that bad?
5 (SRV_FORCE_NO_UNDO_LOG_SCAN) Do not look at undo logs when starting the
database: InnoDB will treat even incomplete transactions as committed.

Was the original problem the same as what we see below? The history list 
of
InnoDB in the ibdata files seems to be corrupt. The only way to fix that
kind of corruption is to rebuild the whole tablespace.
Is there a tutorial on rebuilding the tablespace?  or deleting the
table space and starting over?
Best regards,
Heikki
Innobase Oy
InnoDB - transactions, row level locking, and foreign keys for MySQL
InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up 
MyISAM
tables
http://www.innodb.com/order.php

Order MySQL support from http://www.mysql.com/support/index.html
- Alkuperäinen viesti -
Lähettäjä: jsf [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Kopio: mysql@lists.mysql.com
Lähetetty: Friday, December 31, 2004 5:21 PM
Aihe: Re: BIG InnoDB problems!
 Greetings Heikki and Happy New Year!

 Here's what I got.  I hope it's useful.

 beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n
 mysqld.stack
 0x815f0cf handle_segfault + 575
 0xe420 _end + -138916432
 0x82e71d5 buf_read_page + 165
 0x82e71d5 buf_read_page + 165
 0x82db68f buf_page_get_gen + 175
 0x830479f flst_insert_before + 239
 0x8304cc8 flst_add_first + 152
 0x82be800 trx_purge_add_update_undo_to_history + 624
 0x82d14a6 trx_undo_update_cleanup + 38
 0x82ccafb trx_commit_off_kernel + 363
 0x82cd865 trx_sig_start_handle + 1109
 0x826232b que_run_threads + 2299
 0x827915a row_drop_table_for_mysql + 2314
 0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
 0x81ef33c _Z15ha_delete_table7db_typePKc + 60
 0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
 0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb + 
 93
 0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
 0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
 0x81796cb _Z21mysql_execute_commandP3THD + 19339
 0x817c1b4 _Z11mysql_parseP3THDPcj + 484
 0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
 0x817f137 handle_one_connection + 2391
 0x401619ed _end + 936280957
 0x403519ca _end + 938312538


 p.s.  the whole error file is only 301 lines long.  If you wish I
 could send it to you...

 Here's a segment from lines 1 - 41:

 041230 11:12:10  mysqld started
 041230 11:12:10  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...
 041230 11:12:10  InnoDB: Starting log scan based on checkpoint at
 InnoDB: log sequence number 0 241342003.
 InnoDB: Doing recovery: scanned up to log sequence number 0 241342036
 InnoDB: Last MySQL binlog file position 0 79, file name 
 ./beech-bin.47
 041230 11:12:10  InnoDB: Flushing modified pages from the buffer pool...
 041230 11:12:10  InnoDB: Started; log sequence number 0 241342036
 InnoDB: !!! innodb_force_recovery is set to 5 !!!
 041230 11:12:10 [Warning] mysql.user table is not updated to new
 password format; Disabling new password usage until
 mysql_fix_privilege_tables is run
 041230 11:12:10 [Warning] Can't open and lock time zone table: Table
 'mysql.time_zone_leap_second' doesn't exist trying to live without
 them
 /usr/local/libexec/mysqld: ready for connections.
 Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
 distribution
 InnoDB

Re: BIG InnoDB problems!

2005-01-03 Thread jsf
well, since we were having so many problems with the InnoDB tables, we
created a non-InnoDB version of the database in question...

Basically we want to do whatever it will take to get InnoDB tables
working in our environment.  Any assistance you can offer towards this
goal will be greatly appreciated!

Cheers,

J.


On Mon, 3 Jan 2005 16:36:42 +0200, Heikki Tuuri [EMAIL PROTECTED] wrote:
 Joshua,
 
 about dumping tables from a corrupt database, see:
 http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
 
 This describes how to remove the whole InnoDB database:
 http://dev.mysql.com/doc/mysql/en/Error_creating_InnoDB.html
 
 Be very careful. You do not want to lose your valuable data.
 
 Regards,
 
 Heikki
 
 - Alkuperäinen viesti -
 Lähettäjä: jsf [EMAIL PROTECTED]
 Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
 Kopio: mysql@lists.mysql.com
 Lähetetty: Monday, January 03, 2005 4:31 PM
 Aihe: Re: BIG InnoDB problems!
 
 Hi Heikki,
 
 Please see below...
 
 On Mon, 3 Jan 2005 15:14:12 +0200, Heikki Tuuri [EMAIL PROTECTED]
 wrote:
  Joshua,
 
  the stack trace below shows that you are trying to drop a database? Why?
 
 At that point, I'd heard from our developer of so many problems I
 figured what I would do is test things out.  I created a database.  I
 created a table in the database as an InnoDB .  I tried to insert data
 into it and was unsuccessful.. I tried a few more things.. all
 unsuccessful, so I figured I'd just try to drop the database. But I
 couldn't do that either.
 
 
  If you can, you should use SELECT ... INTO OUTFILE to save of your tables
  what you can save, then rebuild the whole InnoDB tablespace, and import
  the
  tables back to MySQL.
 
 I'm going to have to 'go to school' on InnoDB tablespace.  I have only
 the most rudimentary understanding of what you've written here.
 
 
  The .err file below starts from a situation where you have already set
  innodb_force_recovery to 5.
 
  
 
 Is that bad?
 
  5 (SRV_FORCE_NO_UNDO_LOG_SCAN) Do not look at undo logs when starting the
  database: InnoDB will treat even incomplete transactions as committed.
  
 
  Was the original problem the same as what we see below? The history list
  of
  InnoDB in the ibdata files seems to be corrupt. The only way to fix that
  kind of corruption is to rebuild the whole tablespace.
 
 Is there a tutorial on rebuilding the tablespace?  or deleting the
 table space and starting over?
 
 
  Best regards,
 
  Heikki
  Innobase Oy
  InnoDB - transactions, row level locking, and foreign keys for MySQL
  InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up
  MyISAM
  tables
  http://www.innodb.com/order.php
 
  Order MySQL support from http://www.mysql.com/support/index.html
 
  - Alkuperäinen viesti -
  Lähettäjä: jsf [EMAIL PROTECTED]
  Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
  Kopio: mysql@lists.mysql.com
  Lähetetty: Friday, December 31, 2004 5:21 PM
  Aihe: Re: BIG InnoDB problems!
 
 
   Greetings Heikki and Happy New Year!
  
   Here's what I got.  I hope it's useful.
  
   beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n
   mysqld.stack
   0x815f0cf handle_segfault + 575
   0xe420 _end + -138916432
   0x82e71d5 buf_read_page + 165
   0x82e71d5 buf_read_page + 165
   0x82db68f buf_page_get_gen + 175
   0x830479f flst_insert_before + 239
   0x8304cc8 flst_add_first + 152
   0x82be800 trx_purge_add_update_undo_to_history + 624
   0x82d14a6 trx_undo_update_cleanup + 38
   0x82ccafb trx_commit_off_kernel + 363
   0x82cd865 trx_sig_start_handle + 1109
   0x826232b que_run_threads + 2299
   0x827915a row_drop_table_for_mysql + 2314
   0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
   0x81ef33c _Z15ha_delete_table7db_typePKc + 60
   0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
   0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb +
   93
   0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
   0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
   0x81796cb _Z21mysql_execute_commandP3THD + 19339
   0x817c1b4 _Z11mysql_parseP3THDPcj + 484
   0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
   0x817f137 handle_one_connection + 2391
   0x401619ed _end + 936280957
   0x403519ca _end + 938312538
  
  
   p.s.  the whole error file is only 301 lines long.  If you wish I
   could send it to you...
  
   Here's a segment from lines 1 - 41:
  
   041230 11:12:10  mysqld started
   041230 11:12:10  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...
   041230 11:12:10  InnoDB: Starting log scan based on checkpoint at
   InnoDB: log sequence number 0 241342003.
   InnoDB: Doing recovery: scanned up to log sequence number 0 241342036
   InnoDB: Last MySQL binlog file position 0 79, file name
   ./beech-bin.47

Re: BIG InnoDB problems!

2005-01-03 Thread Heikki Tuuri
Joshua,
the problem you had was serious corruption in the ibdata files. It can be 
caused by an InnoDB bug, an OS bug, faulty hardware, and also by an error of 
the database administrator.

Linux kernels 2.4.18 seemed to have corruption issues.
There are no known corruption bugs of this type in InnoDB. If this happens 
again, please make a very detailed bug report, with the complete .err log, 
all the way from the birth of the installation up to the corruption.

Regards,
Heikki
- Alkuperäinen viesti - 
Lähettäjä: jsf [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Kopio: mysql@lists.mysql.com
Lähetetty: Monday, January 03, 2005 4:56 PM
Aihe: Re: BIG InnoDB problems!

well, since we were having so many problems with the InnoDB tables, we
created a non-InnoDB version of the database in question...
Basically we want to do whatever it will take to get InnoDB tables
working in our environment.  Any assistance you can offer towards this
goal will be greatly appreciated!
Cheers,
J.
On Mon, 3 Jan 2005 16:36:42 +0200, Heikki Tuuri [EMAIL PROTECTED] 
wrote:
Joshua,
about dumping tables from a corrupt database, see:
http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
This describes how to remove the whole InnoDB database:
http://dev.mysql.com/doc/mysql/en/Error_creating_InnoDB.html
Be very careful. You do not want to lose your valuable data.
Regards,
Heikki
- Alkuperäinen viesti -
Lähettäjä: jsf [EMAIL PROTECTED]
Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
Kopio: mysql@lists.mysql.com
Lähetetty: Monday, January 03, 2005 4:31 PM
Aihe: Re: BIG InnoDB problems!
Hi Heikki,
Please see below...
On Mon, 3 Jan 2005 15:14:12 +0200, Heikki Tuuri [EMAIL PROTECTED]
wrote:
 Joshua,

 the stack trace below shows that you are trying to drop a database? Why?
At that point, I'd heard from our developer of so many problems I
figured what I would do is test things out.  I created a database.  I
created a table in the database as an InnoDB .  I tried to insert data
into it and was unsuccessful.. I tried a few more things.. all
unsuccessful, so I figured I'd just try to drop the database. But I
couldn't do that either.

 If you can, you should use SELECT ... INTO OUTFILE to save of your 
 tables
 what you can save, then rebuild the whole InnoDB tablespace, and import
 the
 tables back to MySQL.

I'm going to have to 'go to school' on InnoDB tablespace.  I have only
the most rudimentary understanding of what you've written here.

 The .err file below starts from a situation where you have already set
 innodb_force_recovery to 5.

 
Is that bad?
 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) Do not look at undo logs when starting 
 the
 database: InnoDB will treat even incomplete transactions as committed.
 

 Was the original problem the same as what we see below? The history list
 of
 InnoDB in the ibdata files seems to be corrupt. The only way to fix that
 kind of corruption is to rebuild the whole tablespace.

Is there a tutorial on rebuilding the tablespace?  or deleting the
table space and starting over?

 Best regards,

 Heikki
 Innobase Oy
 InnoDB - transactions, row level locking, and foreign keys for MySQL
 InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up
 MyISAM
 tables
 http://www.innodb.com/order.php

 Order MySQL support from http://www.mysql.com/support/index.html

 - Alkuperäinen viesti -
 Lähettäjä: jsf [EMAIL PROTECTED]
 Vastaanottaja: Heikki Tuuri [EMAIL PROTECTED]
 Kopio: mysql@lists.mysql.com
 Lähetetty: Friday, December 31, 2004 5:21 PM
 Aihe: Re: BIG InnoDB problems!


  Greetings Heikki and Happy New Year!
 
  Here's what I got.  I hope it's useful.
 
  beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n
  mysqld.stack
  0x815f0cf handle_segfault + 575
  0xe420 _end + -138916432
  0x82e71d5 buf_read_page + 165
  0x82e71d5 buf_read_page + 165
  0x82db68f buf_page_get_gen + 175
  0x830479f flst_insert_before + 239
  0x8304cc8 flst_add_first + 152
  0x82be800 trx_purge_add_update_undo_to_history + 624
  0x82d14a6 trx_undo_update_cleanup + 38
  0x82ccafb trx_commit_off_kernel + 363
  0x82cd865 trx_sig_start_handle + 1109
  0x826232b que_run_threads + 2299
  0x827915a row_drop_table_for_mysql + 2314
  0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
  0x81ef33c _Z15ha_delete_table7db_typePKc + 60
  0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
  0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb +
  93
  0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
  0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
  0x81796cb _Z21mysql_execute_commandP3THD + 19339
  0x817c1b4 _Z11mysql_parseP3THDPcj + 484
  0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
  0x817f137 handle_one_connection + 2391
  0x401619ed _end + 936280957
  0x403519ca _end + 938312538
 
 
  p.s.  the whole error file is only 301 lines long.  If you wish I
  could send it to you...
 
  Here's a segment from lines 1 - 41:
 
  041230

Re: BIG InnoDB problems!

2004-12-31 Thread jsf
Greetings Heikki and Happy New Year!

Here's what I got.  I hope it's useful.

beech:/home/jfreeman # resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
0x815f0cf handle_segfault + 575
0xe420 _end + -138916432
0x82e71d5 buf_read_page + 165
0x82e71d5 buf_read_page + 165
0x82db68f buf_page_get_gen + 175
0x830479f flst_insert_before + 239
0x8304cc8 flst_add_first + 152
0x82be800 trx_purge_add_update_undo_to_history + 624
0x82d14a6 trx_undo_update_cleanup + 38
0x82ccafb trx_commit_off_kernel + 363
0x82cd865 trx_sig_start_handle + 1109
0x826232b que_run_threads + 2299
0x827915a row_drop_table_for_mysql + 2314
0x81fe924 _ZN11ha_innobase12delete_tableEPKc + 404
0x81ef33c _Z15ha_delete_table7db_typePKc + 60
0x820aead _Z20mysql_rm_table_part2P3THDP13st_table_listbbb + 989
0x820b19d _Z30mysql_rm_table_part2_with_lockP3THDP13st_table_listbbb + 93
0x8201554 _Z20mysql_rm_known_filesP3THDP9st_my_dirPKcS4_j + 1428
0x8202739 _Z11mysql_rm_dbP3THDPcbb + 345
0x81796cb _Z21mysql_execute_commandP3THD + 19339
0x817c1b4 _Z11mysql_parseP3THDPcj + 484
0x817de5d _Z16dispatch_command19enum_server_commandP3THDPcj + 2685
0x817f137 handle_one_connection + 2391
0x401619ed _end + 936280957
0x403519ca _end + 938312538


p.s.  the whole error file is only 301 lines long.  If you wish I
could send it to you...

Here's a segment from lines 1 - 41:

041230 11:12:10  mysqld started
041230 11:12:10  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...
041230 11:12:10  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 241342003.
InnoDB: Doing recovery: scanned up to log sequence number 0 241342036
InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.47
041230 11:12:10  InnoDB: Flushing modified pages from the buffer pool...
041230 11:12:10  InnoDB: Started; log sequence number 0 241342036
InnoDB: !!! innodb_force_recovery is set to 5 !!!
041230 11:12:10 [Warning] mysql.user table is not updated to new
password format; Disabling new password usage until
mysql_fix_privilege_tables is run
041230 11:12:10 [Warning] Can't open and lock time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without
them
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
distribution
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: Error: trying to access page number 940269659 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
041230 16:42:57InnoDB: Assertion failure in thread 1124068272 in file
fil0fil.c line 3729
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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.

On Fri, 31 Dec 2004 07:46:01 +0200, Heikki Tuuri
[EMAIL PROTECTED] wrote:
 Joshua,
 
 please show what the FIRST InnoDB error in the .err log was. The first error
 is always the important thing to report.
 
 Please follow these instructions:
 
  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
 
 Best regards,
 
 Heikki Tuuri
 Innobase Oy
 Foreign keys, transactions, and row level locking for MySQL
 InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM
 tables
 http://www.innodb.com/order.php
 
 Order MySQL technical support from https://order.mysql.com/
 
 
 - Original Message -
 From: jsf [EMAIL PROTECTED]
 Newsgroups: mailing.database.myodbc
 Sent: Friday, December 31, 2004 12:26 AM
 Subject: BIG InnoDB problems!
 
  I've been struggling with this problem for the last few days.  I've
  enlisted the help of some colleagues on the NYLUG (NY Linux User's
  Group) list but finally we figured this is the best place to look

BIG InnoDB problems!

2004-12-30 Thread jsf
I've been struggling with this problem for the last few days.  I've
enlisted the help of some colleagues on the NYLUG (NY Linux User's
Group) list but finally we figured this is the best place to look for
some help.

We have a server running SLES 9.0 (SuSE Linux Enterprise Server 9.0) and:

mysqladmin  Ver 8.41 Distrib 4.1.8a, for pc-linux-gnu on i686

There are 5 MySQL databases on the server.  The smallest has 5 tables,
the largest 14 tables.  All the tables in all the databases are myISAM
tables.

There is ONE database on the server that we are trying to create/work
with that is all InnoDB tables.

We are having serious problems with these tables.

There are indications in the error logfile regarding what to do to try
and discover the root of these problems and fix them.  I will begin
pursuing those options shortly after posting this but as:

1) We're under a deadline with the application in question that
requires the InnoDB tables and

2) Although I'm the most qualified person, from a technical
standpoint, at my institution to try and get this fixed, that's not
saying much as I'm not THAT deeply technical.

I thought I'd risk posting some of the logfile here to see what the
experts have to say.  Please accept my apologies for just coming here
and dumping this on the list's lap.

I will try to figure it out myself but if anyone can help guide me
towards a solution in the meantime I'd be much obliged.

Many thanks in advance.

Joshua

Here is the output of 'tail -100' on the error logfile:

--snip--

InnoDB: log sequence number 0 241346488.
InnoDB: Doing recovery: scanned up to log sequence number 0 241346521
InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.52
041230 16:43:20  InnoDB: Flushing modified pages from the buffer pool...
041230 16:43:20  InnoDB: Started; log sequence number 0 241346521
InnoDB: !!! innodb_force_recovery is set to 5 !!!
041230 16:43:20 [Warning] mysql.user table is not updated to new
password format; Disabling new password usage until
mysql_fix_privilege_tables is run
041230 16:43:20 [Warning] Can't open and lock time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without
them
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
distribution
InnoDB: Error: trying to access page number 940269659 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
041230 16:46:01InnoDB: Assertion failure in thread 1123867568 in file
fil0fil.c line 3729
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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=2
max_connections=100
threads_connected=1
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=0x89441a8
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=0x42fcb1ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815f0cf
0xe420
0x82e71d5
0x82e71d5
0x82db68f
0x830479f
0x8304cc8
0x82be800
0x82d14a6
0x82ccafb
0x82cd865
0x826232b
0x827915a
0x81fe924
0x81ef33c
0x820aead
0x820b19d
0x8201554
0x8202739
0x81796cb
0x817c1b4
0x817de5d
0x817f137
0x401619ed
0x403519ca
New value of fp=(nil) 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 0x8951778 = DROP DATABASE `josh_Test`
thd-thread_id=5
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.

Number of processes running now: 0
041230 16:46:01  mysqld restarted
041230 16:46:01  InnoDB: Database was not shut 

Re: BIG InnoDB problems!

2004-12-30 Thread Eric Bergen
It looks like your tablespace is corrupt.  Check this doc out:
http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html



On Thu, 30 Dec 2004 17:21:40 -0500, jsf [EMAIL PROTECTED] wrote:
 I've been struggling with this problem for the last few days.  I've
 enlisted the help of some colleagues on the NYLUG (NY Linux User's
 Group) list but finally we figured this is the best place to look for
 some help.
 
 We have a server running SLES 9.0 (SuSE Linux Enterprise Server 9.0) and:
 
 mysqladmin  Ver 8.41 Distrib 4.1.8a, for pc-linux-gnu on i686
 
 There are 5 MySQL databases on the server.  The smallest has 5 tables,
 the largest 14 tables.  All the tables in all the databases are myISAM
 tables.
 
 There is ONE database on the server that we are trying to create/work
 with that is all InnoDB tables.
 
 We are having serious problems with these tables.
 
 There are indications in the error logfile regarding what to do to try
 and discover the root of these problems and fix them.  I will begin
 pursuing those options shortly after posting this but as:
 
 1) We're under a deadline with the application in question that
 requires the InnoDB tables and
 
 2) Although I'm the most qualified person, from a technical
 standpoint, at my institution to try and get this fixed, that's not
 saying much as I'm not THAT deeply technical.
 
 I thought I'd risk posting some of the logfile here to see what the
 experts have to say.  Please accept my apologies for just coming here
 and dumping this on the list's lap.
 
 I will try to figure it out myself but if anyone can help guide me
 towards a solution in the meantime I'd be much obliged.
 
 Many thanks in advance.
 
 Joshua
 
 Here is the output of 'tail -100' on the error logfile:
 
 --snip--
 
 InnoDB: log sequence number 0 241346488.
 InnoDB: Doing recovery: scanned up to log sequence number 0 241346521
 InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.52
 041230 16:43:20  InnoDB: Flushing modified pages from the buffer pool...
 041230 16:43:20  InnoDB: Started; log sequence number 0 241346521
 InnoDB: !!! innodb_force_recovery is set to 5 !!!
 041230 16:43:20 [Warning] mysql.user table is not updated to new
 password format; Disabling new password usage until
 mysql_fix_privilege_tables is run
 041230 16:43:20 [Warning] Can't open and lock time zone table: Table
 'mysql.time_zone_leap_second' doesn't exist trying to live without
 them
 /usr/local/libexec/mysqld: ready for connections.
 Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
 distribution
 InnoDB: Error: trying to access page number 940269659 in space 0,
 InnoDB: space name ./ibdata1,
 InnoDB: which is outside the tablespace bounds.
 InnoDB: Byte offset 0, len 16384, i/o type 10
 041230 16:46:01InnoDB: Assertion failure in thread 1123867568 in file
 fil0fil.c line 3729
 InnoDB: We intentionally generate a memory trap.
 InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 InnoDB: If you get repeated assertion failures or crashes, even
 InnoDB: immediately after the mysqld startup, there may be
 InnoDB: corruption in the InnoDB tablespace. Please refer to
 InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
 InnoDB: about forcing recovery.
 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=2
 max_connections=100
 threads_connected=1
 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=0x89441a8
 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=0x42fcb1ac, backtrace may not be correct.
 Stack range sanity check OK, backtrace follows:
 0x815f0cf
 0xe420
 0x82e71d5
 0x82e71d5
 0x82db68f
 0x830479f
 0x8304cc8
 0x82be800
 0x82d14a6
 0x82ccafb
 0x82cd865
 0x826232b
 0x827915a
 0x81fe924
 0x81ef33c
 0x820aead
 0x820b19d
 0x8201554
 0x8202739
 0x81796cb
 0x817c1b4
 0x817de5d
 0x817f137
 0x401619ed
 0x403519ca
 New value of fp=(nil) 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...
 

Re: BIG InnoDB problems!

2004-12-30 Thread jsf
Thanks Eric,

We already tried levels 1, 3 and 5...

no soap.  I'm on the verge of thinking it's a bug.



:-(

J.


On Fri, 31 Dec 2004 00:06:28 +, Eric Bergen [EMAIL PROTECTED] wrote:
 It looks like your tablespace is corrupt.  Check this doc out:
 http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
 
 On Thu, 30 Dec 2004 17:21:40 -0500, jsf [EMAIL PROTECTED] wrote:
  I've been struggling with this problem for the last few days.  I've
  enlisted the help of some colleagues on the NYLUG (NY Linux User's
  Group) list but finally we figured this is the best place to look for
  some help.
 
  We have a server running SLES 9.0 (SuSE Linux Enterprise Server 9.0) and:
 
  mysqladmin  Ver 8.41 Distrib 4.1.8a, for pc-linux-gnu on i686
 
  There are 5 MySQL databases on the server.  The smallest has 5 tables,
  the largest 14 tables.  All the tables in all the databases are myISAM
  tables.
 
  There is ONE database on the server that we are trying to create/work
  with that is all InnoDB tables.
 
  We are having serious problems with these tables.
 
  There are indications in the error logfile regarding what to do to try
  and discover the root of these problems and fix them.  I will begin
  pursuing those options shortly after posting this but as:
 
  1) We're under a deadline with the application in question that
  requires the InnoDB tables and
 
  2) Although I'm the most qualified person, from a technical
  standpoint, at my institution to try and get this fixed, that's not
  saying much as I'm not THAT deeply technical.
 
  I thought I'd risk posting some of the logfile here to see what the
  experts have to say.  Please accept my apologies for just coming here
  and dumping this on the list's lap.
 
  I will try to figure it out myself but if anyone can help guide me
  towards a solution in the meantime I'd be much obliged.
 
  Many thanks in advance.
 
  Joshua
 
  Here is the output of 'tail -100' on the error logfile:
 
  --snip--
 
  InnoDB: log sequence number 0 241346488.
  InnoDB: Doing recovery: scanned up to log sequence number 0 241346521
  InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.52
  041230 16:43:20  InnoDB: Flushing modified pages from the buffer pool...
  041230 16:43:20  InnoDB: Started; log sequence number 0 241346521
  InnoDB: !!! innodb_force_recovery is set to 5 !!!
  041230 16:43:20 [Warning] mysql.user table is not updated to new
  password format; Disabling new password usage until
  mysql_fix_privilege_tables is run
  041230 16:43:20 [Warning] Can't open and lock time zone table: Table
  'mysql.time_zone_leap_second' doesn't exist trying to live without
  them
  /usr/local/libexec/mysqld: ready for connections.
  Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
  distribution
  InnoDB: Error: trying to access page number 940269659 in space 0,
  InnoDB: space name ./ibdata1,
  InnoDB: which is outside the tablespace bounds.
  InnoDB: Byte offset 0, len 16384, i/o type 10
  041230 16:46:01InnoDB: Assertion failure in thread 1123867568 in file
  fil0fil.c line 3729
  InnoDB: We intentionally generate a memory trap.
  InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
  InnoDB: If you get repeated assertion failures or crashes, even
  InnoDB: immediately after the mysqld startup, there may be
  InnoDB: corruption in the InnoDB tablespace. Please refer to
  InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
  InnoDB: about forcing recovery.
  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=2
  max_connections=100
  threads_connected=1
  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=0x89441a8
  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=0x42fcb1ac, backtrace may not be correct.
  Stack range sanity check OK, backtrace follows:
  0x815f0cf
  0xe420
  0x82e71d5
  0x82e71d5
  0x82db68f
  0x830479f
  0x8304cc8
  0x82be800
  0x82d14a6
  0x82ccafb
  0x82cd865
  0x826232b
  0x827915a
  0x81fe924
  0x81ef33c
  0x820aead
  0x820b19d
  0x8201554
  0x8202739
  0x81796cb
  0x817c1b4
  0x817de5d
  0x817f137
  0x401619ed
  0x403519ca
  New value of fp=(nil) failed sanity check, terminating stack trace!
  Please read 

Re: BIG InnoDB problems!

2004-12-30 Thread Heikki Tuuri
Joshua,
please show what the FIRST InnoDB error in the .err log was. The first error 
is always the important thing to report.

Please follow these instructions:
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
Best regards,
Heikki Tuuri
Innobase Oy
Foreign keys, transactions, and row level locking for MySQL
InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM 
tables
http://www.innodb.com/order.php

Order MySQL technical support from https://order.mysql.com/
- Original Message - 
From: jsf [EMAIL PROTECTED]
Newsgroups: mailing.database.myodbc
Sent: Friday, December 31, 2004 12:26 AM
Subject: BIG InnoDB problems!


I've been struggling with this problem for the last few days.  I've
enlisted the help of some colleagues on the NYLUG (NY Linux User's
Group) list but finally we figured this is the best place to look for
some help.
We have a server running SLES 9.0 (SuSE Linux Enterprise Server 9.0) and:
mysqladmin  Ver 8.41 Distrib 4.1.8a, for pc-linux-gnu on i686
There are 5 MySQL databases on the server.  The smallest has 5 tables,
the largest 14 tables.  All the tables in all the databases are myISAM
tables.
There is ONE database on the server that we are trying to create/work
with that is all InnoDB tables.
We are having serious problems with these tables.
There are indications in the error logfile regarding what to do to try
and discover the root of these problems and fix them.  I will begin
pursuing those options shortly after posting this but as:
1) We're under a deadline with the application in question that
requires the InnoDB tables and
2) Although I'm the most qualified person, from a technical
standpoint, at my institution to try and get this fixed, that's not
saying much as I'm not THAT deeply technical.
I thought I'd risk posting some of the logfile here to see what the
experts have to say.  Please accept my apologies for just coming here
and dumping this on the list's lap.
I will try to figure it out myself but if anyone can help guide me
towards a solution in the meantime I'd be much obliged.
Many thanks in advance.
Joshua
Here is the output of 'tail -100' on the error logfile:
--snip--
InnoDB: log sequence number 0 241346488.
InnoDB: Doing recovery: scanned up to log sequence number 0 241346521
InnoDB: Last MySQL binlog file position 0 79, file name ./beech-bin.52
041230 16:43:20  InnoDB: Flushing modified pages from the buffer pool...
041230 16:43:20  InnoDB: Started; log sequence number 0 241346521
InnoDB: !!! innodb_force_recovery is set to 5 !!!
041230 16:43:20 [Warning] mysql.user table is not updated to new
password format; Disabling new password usage until
mysql_fix_privilege_tables is run
041230 16:43:20 [Warning] Can't open and lock time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without
them
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.8a-log'  socket: '/tmp/mysql.sock'  port: 3306  Source
distribution
InnoDB: Error: trying to access page number 940269659 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
041230 16:46:01InnoDB: Assertion failure in thread 1123867568 in file
fil0fil.c line 3729
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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=2
max_connections=100
threads_connected=1
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=0x89441a8
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=0x42fcb1ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815f0cf
0xe420
0x82e71d5
0x82e71d5
0x82db68f
0x830479f
0x8304cc8
0x82be800
0x82d14a6
0x82ccafb
0x82cd865
0x826232b
0x827915a
0x81fe924

mysqld crash due to innoDB problems?

2004-05-17 Thread Rusty W. Shanklin

DESCRIPTION:
  Mysqld appears to crash every few days or so.  The .err file shows
that it may be an innodb problem.  (See below for detail)

How-To-Repeat
  I am not able to repeat the problem.  The query that runs when the
mysqld server dies, is automatically re-run when the server comes back
up.  The query always appears to run successfully after the restart.

Fix:
   The automatic restart of mysqld solves the problem, however the
server going down is now my problem.

Submitter-ID: RustyShanklin
Organization: Pikeville Medical Center
MySQL support: NONE
Synopsis: mysqld crash - Possible InnoDB corruption?
Severity: serious
Severity: medium
Category: mysql
Class: sw-bug
Release:   mysql-4.0.18-standard (Official MySQL-standard binary)
C compiler:2.95.3
C++ compiler:  2.95.3
Environment:
System: Linux mish02.pikevillehospital.org 2.4.18-14smp 
#1 SMP Wed Sep 4 12:34:47 EDT 2002 i686 i686 i386 GNU/Linux
 (4 processor system) 2GB Ram.
Architecture: i686 
Some paths:  /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc
/usr/bin/cc
GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --disable-checking
--host=i
386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Compilation info: CC='gcc'  CFLAGS='-O2 -mcpu=pentiumpro'  CXX='gcc'
CXXFLAGS='
-O2 -mcpu=pentiumpro -felide-constructors'  LDFLAGS=''  ASFLAGS=''
LIBC:
lrwxrwxrwx1 root root   14 Mar  4  2003 /lib/libc.so.6
- libc-2
.2.93.so
-rwxr-xr-x1 root root  1235468 Sep  5  2002
/lib/libc-2.2.93.so
-rw-r--r--1 root root  2233342 Mar 10  2003 /usr/lib/libc.a
-rw-r--r--1 root root  178 Mar 10  2003 /usr/lib/libc.so
Configure command: ./configure '--prefix=/usr/local/mysql'
'--localstatedir=/usr
/local/mysql/data' '--libexecdir=/usr/local/mysql/bin'
'--with-comment=Official
MySQL-standard binary' '--with-extra-charsets=complex'
'--with-server-suffix=-st
andard' '--enable-thread-safe-client' '--enable-local-infile'
'--enable-assemble
r' '--disable-shared' '--with-client-ldflags=-all-static'
'--with-mysqld-ldflags
=-all-static' '--with-embedded-server' '--with-innodb' 'CFLAGS=-O2
-mcpu=pentium
pro' 'CXXFLAGS=-O2 -mcpu=pentiumpro -felide-constructors' 'CXX=gcc'

--mysql.err file:
InnoDB: Error: Mem area size is 0. Possibly a memory overrun of the
InnoDB: previous allocated area!
InnoDB: Apparent memory corruption: mem dump  len 500; hex
4e43303b5350433a4c414
23b3133343a3a3a3a3a3a3a4e3a3a3a3a3a31333439383b5354414d5045523b44414
e49454c3
b483b3b3b4d443a3a3a3a3a3a3230303430353135323230343a3b20203a3a4f7
26465726
5643a3a313b3b3b3230303430353136303230323b3b333b3b3b3a3a3a222
23a3a3a3
a3a3a0d4447313a39393a49393a3a3a3a574f524b494e473a3a3a3a3a3a3a3a0d5a43413
a3a2
2223a3b3b3b0d3506001e05353738303708535441525f57454213323030342d30352d313
52032323
a30343a3133016e03413038fc09064d53483a3b7e5c263aa
9010
000b010a808a001f63d775f9268a520773073656c2e6300a2080

000900190014000f
00e41084
d53483a3b7e5c263a48424f433a413a534f46544c41423a413a323030343035313530373
33830363
a3a4f524d3b4f30313b30313a373239303430343a503a322e313a373239303430343a3a0
d5049443
a3a3a3031303030353b3b3b413a3a5455524e45523b4b4154484c45454e3a3a313933303
03631333
a463a3a3a3a3a3a3a3a3a3a30343133313036373b3b3b413a3430302d33382d38393
1380d4f5
2433a4e413a31353630; asc
NC0;SPC:LAB;134:::N:13498;STAMPER;DANIEL;H;;;
MD::200405152204:;
::Ordered::1;;;200405160202;;3;;;:.D
G1:99:I9WORKING.ZCA:::;;;.557807.STAR_WEB.2004-05-15
22:04:1
3.n.A08...MSH:;~\:.=w_.h.
w0sel.c..
[EMAIL PROTECTED]:;~\:HBOC:A:SOFTLAB:A:20040515073
806::ORM
;O01;01:7290404:P:2.1:7290404::.PID:::010005;;;A::TURNER;KATHLEEN::19300
613:F:::
:::0413103367;;;A:400-38-8918.ORC:NA:1560;
InnoDB: Scanning backward trying to find previous allocated mem blocks
Freed mem block at - 52160, file w0sel.c, line 2210
Freed mem block at - 53016, file w0sel.c, line 2210
Freed mem block at - 54584, file w0sel.c, line 2210
Freed mem block at - 117720, file w0sel.c, line 2210
Mem block at - 117912, file 0pcur.c, line 28
Mem block at - 118128, file w0upd.c, line 289
Mem block at - 118232, file m0rec.c, line 443
Freed mem block at - 124928, file w0sel.c, line 2210
Mem block at - 125216, file w0sel.c, line 2273
Mem block at - 126704, file w0sel.c, line 2210
InnoDB: Scanning forward trying to find next allocated mem blocks
Freed mem block at + 16, file w0sel.c, line 2210
Mem block at + 2448, file nodb.cc, line 1920
Freed mem block at + 2736, file w0sel.c, line 2210
Mem block at + 3832, file m0rec.c, line 443
Mem block at + 3936, file w0upd.c, line 289
Mem block at + 

Re: InnoDB problems with 4.0.18-max

2004-04-06 Thread Heikki Tuuri
Rick,

- Original Message - 
From: Rick Ellis [EMAIL PROTECTED]
Newsgroups: mailing.database.myodbc
Sent: Thursday, April 01, 2004 11:27 AM
Subject: InnoDB problems with 4.0.18-max


 Hi Guys,

 We are currently using MySQL as the backend to the RT Request Tracker
 Ticketing system. The problem is that we are seeing total data loss from
 the InnoDB after a proper shutdown of the database using mysqladmin
 shutdown.

 We have observed this once on a Sparc Enterprise 420R with 4 CPU's and 4
 gigs of RAM, using the my-large.cnf as a template and Solaris 9, but we
 see this most often on mysql 4.0-18-max running on a Enterprise 220R
 with 2 CPU's and 2 gigs of ram, based on my-small.cnf and Solaris 8.

 Both setups are using perl 5.8.3 and the latest Apache 3 release.

 On restarting the Mysql server, (which serves a number of other
 application, not using InnoDB perfectly) we cannot log in. Going into
 Mysql itself, and use rt3; it complains that most of the tables are
 blank. See extract below from the .err log file:


 040310  7:03:37  /usr/local/mysql/bin/mysqld: Normal shutdown

 040310  7:03:38  InnoDB: Starting shutdown...
 040310  7:03:42  InnoDB: Shutdown completed
 040310  7:03:42  /usr/local/mysql/bin/mysqld: Shutdown Complete

 040310 07:04:06  mysqld started
 040310  7:04:07  InnoDB: Database was not shut down normally.
 InnoDB: Starting recovery from log files...
 InnoDB: Starting log scan based on checkpoint at
 InnoDB: log sequence number 0 2488475
 InnoDB: Doing recovery: scanned up to log sequence number 0 2488475
 040310  7:04:07  InnoDB: Flushing modified pages from the buffer pool...
 040310  7:04:07  InnoDB: Started
 /export/mysql4/bin/mysqld: ready for connections.
 Version: '4.0.18-max'  socket: '/tmp/mysql.sock'  port: 3306
 040310  7:05:41  InnoDB error:
 Cannot find table rt3/Users from the internal data dictionary
 of InnoDB though the .frm file for the table exists. Maybe you
 have deleted and recreated InnoDB data files but have forgotten
 to delete the corresponding .frm files of InnoDB tables, or you
 have moved .frm files to another database?
 Look from section 15.1 of http://www.innodb.com/ibman.html
 how you can resolve the problem.
 040310  7:05:41  InnoDB error:
 Cannot find table rt3/Users from the internal data dictionary
 of InnoDB though the .frm file for the table exists. Maybe you
 have deleted and recreated InnoDB data files but have forgotten
 to delete the corresponding .frm files of InnoDB tables, or you
 have moved .frm files to another database?
 Look from section 15.1 of http://www.innodb.com/ibman.html
 how you can resolve the problem.
 040310  7:05:41  InnoDB error:
 Cannot find table rt3/Users from the internal data dictionary
 of InnoDB though the .frm file for the table exists. Maybe you
 have deleted and recreated InnoDB data files but have forgotten
 to delete the corresponding .frm files of InnoDB tables, or you
 have moved .frm files to another database?
 Look from section 15.1 of http://www.innodb.com/ibman.html
 how you can resolve the problem.
 040310  7:05:41  InnoDB error:
 Cannot find table rt3/Users from the internal data dictionary
 of InnoDB though the .frm file for the table exists. Maybe you
 have deleted and recreated InnoDB data files but have forgotten
 to delete the corresponding .frm files of InnoDB tables, or you
 have moved .frm files to another database?
 Look from section 15.1 of http://www.innodb.com/ibman.html
 how you can resolve the problem.
 040310  7:05:41  InnoDB error:
 Cannot find table rt3/Users from the internal data dictionary
 of InnoDB though the .frm file for the table exists. Maybe you
 have deleted and recreated InnoDB data files but have forgotten
 to delete the corresponding .frm files of InnoDB tables, or you
 have moved .frm files to another database?
 Look from section 15.1 of http://www.innodb.com/ibman.html
 how you can resolve the problem.

 Settings from the worst affected system' my.cnf file are:

 # Uncomment the following if you are using InnoDB tables
 innodb_data_home_dir = /usr/local/mysql/data/
 innodb_data_file_path = ibdata1:10M:autoextend
 innodb_log_group_home_dir = /usr/local/mysql/data/
 innodb_log_arch_dir = /usr/local/mysql/data/
 # You can set .._buffer_pool_size up to 50 - 80 %
 # of RAM but beware of setting memory usage too high
 set-variable = innodb_buffer_pool_size=32M
 set-variable = innodb_additional_mem_pool_size=2M
 # Set .._log_file_size to 25 % of buffer pool size
 set-variable = innodb_log_file_size=5M
 set-variable = innodb_log_buffer_size=8M
 innodb_flush_log_at_trx_commit=1
 set-variable = innodb_lock_wait_timeout=50
 #set-variable = innodb_force_recovery=4

 We are doing an sqldump every hour and before any shutdowns now, because
 we can't guarantee that the database will come back up.

 If anyone can spot the problem or suggest a course of action to debug
 the issue I'll be very happy.

are you changing the InnoDB parameters in my.cnf when mysqld is running

InnoDB problems with 4.0.18-max

2004-04-01 Thread Rick Ellis
Hi Guys,

We are currently using MySQL as the backend to the RT Request Tracker
Ticketing system. The problem is that we are seeing total data loss from
the InnoDB after a proper shutdown of the database using mysqladmin
shutdown.

We have observed this once on a Sparc Enterprise 420R with 4 CPU's and 4
gigs of RAM, using the my-large.cnf as a template and Solaris 9, but we
see this most often on mysql 4.0-18-max running on a Enterprise 220R
with 2 CPU's and 2 gigs of ram, based on my-small.cnf and Solaris 8.

Both setups are using perl 5.8.3 and the latest Apache 3 release.

On restarting the Mysql server, (which serves a number of other
application, not using InnoDB perfectly) we cannot log in. Going into
Mysql itself, and use rt3; it complains that most of the tables are
blank. See extract below from the .err log file:


040310  7:03:37  /usr/local/mysql/bin/mysqld: Normal shutdown

040310  7:03:38  InnoDB: Starting shutdown...
040310  7:03:42  InnoDB: Shutdown completed
040310  7:03:42  /usr/local/mysql/bin/mysqld: Shutdown Complete

040310 07:04:06  mysqld started
040310  7:04:07  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 2488475
InnoDB: Doing recovery: scanned up to log sequence number 0 2488475
040310  7:04:07  InnoDB: Flushing modified pages from the buffer pool...
040310  7:04:07  InnoDB: Started
/export/mysql4/bin/mysqld: ready for connections.
Version: '4.0.18-max'  socket: '/tmp/mysql.sock'  port: 3306
040310  7:05:41  InnoDB error:
Cannot find table rt3/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Look from section 15.1 of http://www.innodb.com/ibman.html
how you can resolve the problem.
040310  7:05:41  InnoDB error:
Cannot find table rt3/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Look from section 15.1 of http://www.innodb.com/ibman.html
how you can resolve the problem.
040310  7:05:41  InnoDB error:
Cannot find table rt3/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Look from section 15.1 of http://www.innodb.com/ibman.html
how you can resolve the problem.
040310  7:05:41  InnoDB error:
Cannot find table rt3/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Look from section 15.1 of http://www.innodb.com/ibman.html
how you can resolve the problem.
040310  7:05:41  InnoDB error:
Cannot find table rt3/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Look from section 15.1 of http://www.innodb.com/ibman.html
how you can resolve the problem.

Settings from the worst affected system' my.cnf file are:

# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /usr/local/mysql/data/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/data/
innodb_log_arch_dir = /usr/local/mysql/data/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
set-variable = innodb_buffer_pool_size=32M
set-variable = innodb_additional_mem_pool_size=2M
# Set .._log_file_size to 25 % of buffer pool size
set-variable = innodb_log_file_size=5M
set-variable = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
set-variable = innodb_lock_wait_timeout=50
#set-variable = innodb_force_recovery=4

We are doing an sqldump every hour and before any shutdowns now, because
we can't guarantee that the database will come back up.

If anyone can spot the problem or suggest a course of action to debug
the issue I'll be very happy.
-- 
Rick Ellis [EMAIL PROTECTED]


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: InnoDb Problems

2003-02-07 Thread Stefan Hinz
Davy,

DO I have been trying to get InnoDb to run on my windows XP machine.
DO (...)
DO #innodb_data_home_dir =
DO #innodb_log_group_home_dir =
DO #innodb_data_file_path = /ibdata/ibdata1:10M:autoextend

The remarks are in German, but I guess you will know what to do if
you look at the following excerpt from my my.ini file on a Win2K
machine:

# InnoDB
# Speicherort fuer Tablespaces (Vorgabe: DATADIR)
innodb_data_home_dir=c:\mysql\innodb
# Vorgabemaessig wird ab MySQL 4.0
#  ein 64 MB grosser Tablespace namens ibdata1
#  (per Vorgabe in DATADIR) angelegt.
#  Folgende Einstellungen ueberschreiben diesen Wert.
innodb_data_file_path = ibdata1:100M;ibdata2:100M
# Speicherort fuer Logdateien
innodb_log_group_home_dir=c:\mysql\innodb
innodb_log_arch_dir = c:\mysql\innodb
# Logarchivierung anschalten (1) oder abschalten (0)
innodb_log_archive=0
# Einstellungen fuer Logdateien
# set-variable = innodb_mirrored_log_groups=1
# set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=5M
set-variable = innodb_log_buffer_size=8M
# Puffer-Poolgroesse auf 50% bis 80%
# des Arbeitsspeichers Ihres Computers setzen
set-variable = innodb_buffer_pool_size=70M
set-variable = innodb_additional_mem_pool_size=10M
# Transaktionen immer sicher (1) oder nicht (0)
innodb_flush_log_at_trx_commit=1
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

Regards,
--
  Stefan Hinz [EMAIL PROTECTED]
  iConnect GmbH http://iConnect.de
  Heesestr. 6, 12169 Berlin (Germany)
  Telefon: +49 30 7970948-0  Fax: +49 30 7970948-3


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: InnoDb Problems

2003-02-06 Thread Natale Babbo
i see that you don't specify any path for
innodb_data_home_dir, innodb_log_group_home_dir and 
innodb_data_file_path  ... write down the correct path
and retry.

regards.



 --- Davy Obdam [EMAIL PROTECTED] ha scritto:  Hi
People,
 
 I have been trying to get InnoDb to run on my
 windows XP machine. I have 
 MySQL 3.23.55 installed and i am running the
 mysqld-max-nt server. I 
 have added the following lines to my my.ini file:
 (note the # because i 
 didnt get it to work, i dissabled it)
 [mysqld]
 
 .
 #innodb_data_home_dir =
 #innodb_log_group_home_dir =
 #innodb_data_file_path =
 /ibdata/ibdata1:10M:autoextend
 
 When i start my MySQL server with this config, i get
 and error and the 
 server wont start. What am i doing wrong here?? Any
 help is appreciated, 
 thanks for your time.
 
 Best regards,
 
 Davy Obdam
 mailto:[EMAIL PROTECTED]
 
 -- 


 Davy Obdam - Obdam webdesign©
 mailto:[EMAIL PROTECTED]   web: www.davyobdam.com


 
 
 
 

-
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list
 archive)
 
 To request this thread, e-mail
 [EMAIL PROTECTED]
 To unsubscribe, e-mail

[EMAIL PROTECTED]
 Trouble unsubscribing? Try:
 http://lists.mysql.com/php/unsubscribe.php
  

__
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




InnoDb Problems

2003-02-05 Thread Davy Obdam
Hi People,

I have been trying to get InnoDb to run on my windows XP machine. I have 
MySQL 3.23.55 installed and i am running the mysqld-max-nt server. I 
have added the following lines to my my.ini file: (note the # because i 
didnt get it to work, i dissabled it)
[mysqld]

.
#innodb_data_home_dir =
#innodb_log_group_home_dir =
#innodb_data_file_path = /ibdata/ibdata1:10M:autoextend

When i start my MySQL server with this config, i get and error and the 
server wont start. What am i doing wrong here?? Any help is appreciated, 
thanks for your time.

Best regards,

Davy Obdam
mailto:[EMAIL PROTECTED]

--

Davy Obdam - Obdam webdesign©
mailto:[EMAIL PROTECTED]   web: www.davyobdam.com





-
Before posting, please check:
  http://www.mysql.com/manual.php   (the manual)
  http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php



Innodb problems

2002-03-06 Thread Wendell Dingus

I've been using MyISAM tables for a long time on a lot of machines and
(knock on wood) have basically never had a problem. Now though on a larger
server I decided we should use INNODB tables and am having problems. I
didn't realize until today that it's been 'crashing' and recovering
repeatedly for the past few weeks. Today it died though and could not repair
itself. Since I'm doing replication to a second server I just copied
databases from the backup server to the primary and got things back going.
Looking at the log files on the second/backup server it has the same type of
errors in the log file though. Not bad hardware unless both (identical)
servers have the same bad hardware.

Here's where it crashed and dumped a heck of a lot of hex data into the log
file:

..;InnoD
B: End of page dump
InnoDB: Page checksum 1558702454 stored checksum 0
InnoDB: Page lsn 4 226263974, low 4 bytes of lsn at page end 0
InnoDB: Page may be an index page where index id is 0 565
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.

Number of processes running now: 0
020306 08:55:21  mysqld restarted
020306  8:55:25  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 4 229089185
InnoDB: Last MySQL binlog file offset 0 465620, file name ./shelby1-bin.001
020306  8:55:26  InnoDB: Flushing modified pages from the buffer pool...
020306  8:55:26  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 8fd30005851f00058


Here's where it gave up the ghost entirely:

..;InnoD
B: End of page dump
InnoDB: Page checksum 1558702454 stored checksum 0
InnoDB: Page lsn 4 226263974, low 4 bytes of lsn at page end 0
InnoDB: Page may be an index page where index id is 0 565
InnoDB: and table registrydb_tn/TBL_AllNames index LastName
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.

Number of processes running now: 0
020306 09:01:16  mysqld restarted
020306  9:01:16  Can't start server: Bind on TCP/IP port: Address already in
use
020306  9:01:16  Do you already have another mysqld server running on port:
3306 ?
020306  9:01:16  Aborting

020306  9:01:16  /usr/sbin/mysqld-max: Shutdown Complete

020306 09:01:16  mysqld ended


Here's the my.cnf file:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-bin
server-id=1

default-table-type=innodb
innodb_data_file_path =
ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M;ibdata5:2000M;ibdata
6:2000M
innodb_data_home_dir = /var/lib/innodb/
set-variable = innodb_mirrored_log_groups=1
innodb_log_group_home_dir = /var/lib/iblogs
set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M
innodb_flush_log_at_trx_commit=1
innodb_log_arch_dir = /var/lib/iblogs
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=800M
set-variable = innodb_additional_mem_pool_size=40M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid



This is on an IBM xSeries 350 server, dual P3 Xeon 700's, 1.5GB RAM, IBM
ServRAID 4LX RAID controller, RedHat 7.2 with all patches (2.4.9-31 RH RPM
kernel). Any ideas on how to prevent this will be greatly appreciated!
Thanks...




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: Innodb problems

2002-03-06 Thread Heikki Tuuri

Wendell,

InnoDB writes a checksum to a database page when it is written to disk. If
the checksum does not correspond to the page contents when the page is read
back in, you get the below error. Below page 36819 in table
registrydb_tn/TBL_AllNames appears to be corrupt, like it says. The checksum
is 0, which does not correspond to page contents.

When you encounter this kind of error, the first thing to try is rebooting
the computer, like it says below. Next you can try dumping, dropping, and
reimporting the corrupt table. The last resort is to recover from a backup.

020306 09:01:16  mysqld restarted
020306  9:01:16  Can't start server: Bind on TCP/IP port: Address already
in
use
020306  9:01:16  Do you already have another mysqld server running on port:
3306 ?

The last error you got was probably that Linux had not killed the entire
mysqld process though mysqld had called exit(1). Then you should look with
ps -A what processes are running, and kill -9 them manually.

Please send me all error messages and hex dumps you have, from both servers.
What version you are running?

Linux kernels 2.2 -2.5 seem to have bugs in the i/o system, especially in
connection with RAID disks. But let us look first at the hex files.

Regards,

Heikki

-Original Message-
From: Wendell Dingus [EMAIL PROTECTED]
Newsgroups: mailing.database.mysql
Date: Thursday, March 07, 2002 6:16 AM
Subject: Innodb problems


I've been using MyISAM tables for a long time on a lot of machines and
(knock on wood) have basically never had a problem. Now though on a larger
server I decided we should use INNODB tables and am having problems. I
didn't realize until today that it's been 'crashing' and recovering
repeatedly for the past few weeks. Today it died though and could not
repair
itself. Since I'm doing replication to a second server I just copied
databases from the backup server to the primary and got things back going.
Looking at the log files on the second/backup server it has the same type
of
errors in the log file though. Not bad hardware unless both (identical)
servers have the same bad hardware.

Here's where it crashed and dumped a heck of a lot of hex data into the log
file:

..;Inno
D
B: End of page dump
InnoDB: Page checksum 1558702454 stored checksum 0
InnoDB: Page lsn 4 226263974, low 4 bytes of lsn at page end 0
InnoDB: Page may be an index page where index id is 0 565
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.

Number of processes running now: 0
020306 08:55:21  mysqld restarted
020306  8:55:25  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 4 229089185
InnoDB: Last MySQL binlog file offset 0 465620, file name ./shelby1-bin.001
020306  8:55:26  InnoDB: Flushing modified pages from the buffer pool...
020306  8:55:26  InnoDB: Started
/usr/sbin/mysqld-max: ready for connections
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 8fd30005851f00058


Here's where it gave up the ghost entirely:

..;Inno
D
B: End of page dump
InnoDB: Page checksum 1558702454 stored checksum 0
InnoDB: Page lsn 4 226263974, low 4 bytes of lsn at page end 0
InnoDB: Page may be an index page where index id is 0 565
InnoDB: and table registrydb_tn/TBL_AllNames index LastName
InnoDB: Database page corruption or a failed
InnoDB: file read of page 36819.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.

Number of processes running now: 0
020306 09:01:16  mysqld restarted
020306  9:01:16  Can't start server: Bind on TCP/IP port: Address already
in
use
020306  9:01:16  Do you already have another mysqld server running on port:
3306 ?
020306  9:01:16  Aborting

020306  9:01:16  /usr/sbin/mysqld-max: Shutdown Complete

020306 09:01:16  mysqld ended


Here's the my.cnf file:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-bin
server-id=1

default-table-type=innodb
innodb_data_file_path =
ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M;ibdata5:2000M;ibdat
a
6:2000M
innodb_data_home_dir = /var/lib/innodb/
set-variable = innodb_mirrored_log_groups=1
innodb_log_group_home_dir = /var/lib/iblogs
set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M

Re: InnoDB problems

2001-09-10 Thread Heikki Tuuri

Nuno,

I noticed a similar unexplained restriction
on our Linux 2.4. We have 512 MB physical memory,
no swap partition, and for some reason I cannot
malloc more than 256 MB. The Unix errno just says
'Cannot allocate memory'.

On our other machine with 900 MB RAM and 512 MB swap
I can malloc 900 MB.

What is your my.cnf like? Is it possible that you
have allocated so much memory to PostgreSQL, MyISAM,
and other programs that the 2 GB or 3 GB you have is
almost totally used?

Regards,

Heikki

At 10:55 AM 9/10/01 +0100, you wrote:
On Fri, Sep 07, 2001 at 08:47:16PM +0300, Heikki Tuuri wrote:
 Nuno,
 
 what does
 
 ulimit -a
 
 say (assuming you are running on Unix)?
 ulimit tells the limits set for the user.
 I think there are also hard limits decided
 at kernel compile time.

core file size (blocks)  0
data seg size (kbytes)   unlimited
file size (blocks)   unlimited
max memory size (kbytes) unlimited
stack size (kbytes)  8192
cpu time (seconds)   unlimited
max user processes   256
pipe size (512 bytes)8
open files   1024
virtual memory (kbytes)  2105343

I'm running Linux.

 
 What does
 
 free
 
 say?
 

 total   used   free sharedbuffers cached
Mem:   20967202094180   2540  01073620 786400
-/+ buffers/cache: 2341601862560
Swap:  1052248   32921048956


But I'm running two SQL servers (MySQL and PostGres) and I'm running some
scripts. Apart from that, the machine is totally dedicated to SQL stuff.
When installing InnoDB I should have most of the memory available.


 Regards,
 
 Heikki
 http://www.innodb.com
 
 Nuno Dias wrote:
  
  I installed mysql with innodb support on a machine with 2G of RAM. 
  The manual recommends that one should set innodb_buffer_pool_size in
 my.cnf to 
 up to 80% of the physical memory available.
  
  However, if I set a value above 50M!!! I get this error:
  
  Innobase: Fatal error: cannot allocate memory!
  Innobase: Cannot continue operation!
  Innobase: Check if you can increase the swap file of your
  Innobase: operating system.
  010906 15:31:27  mysqld ended
  
  Anyone as any clue about this?
   -- Nuno Dias [EMAIL PROTECTED]
  Novis - Dir. Rede - ISP http://www.novis.pt/
  Ed. Atrium Saldanha - Pça. Dq. de Saldanha, 1, 7o / 1050 - 094 Lisboa
  tel: +351 21 0104437 - fax: +351 21 0104301 
  I may not be able to walk, but I drive from a sitting position.
 
 
 
 -
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list archive)
 
 To request this thread, e-mail [EMAIL PROTECTED]
 To unsubscribe, e-mail [EMAIL PROTECTED]
 Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
 

-- 
Nuno Dias [EMAIL PROTECTED]
Novis - Dir. Rede - ISP http://www.novis.pt/ 
Ed. Atrium Saldanha - Pça. Dq. de Saldanha, 1, 7o / 1050 - 094 Lisboa
tel: +351 21 0104437 - fax: +351 21 0104301


Brandy Davis, an outfielder and teammate of mine with the Pittsburgh Pirates,
is my choice for team captain.  Cincinnatti was beating us 3-1, and I led
off the bottom of the eighth with a walk.  The next hitter banged a hard
single to right field.  Feeling the wind at my back, I rounded second and
kept going, sliding safely into third base.
   With runners at first and third, and home-run hitter Ralph Kiner at
bat, our manager put in the fast Brandy Davis to run for the player at first.
Even with Kiner hitting and a change to win the game with a home run, Brandy
took off for second and made it.  Now we had runners at second and third.
   I'm standing at third, knowing I'm not going anywhere, and see Brandy
start to take a lead.  All of a sudden, here he comes.  He makes a great slide
into third, and I scream, Brandy, where are you going?  He looks up, and
shouts, Back to second if I can make it.
   -- Joe Garagiola, It's Anybody's Ball Game




-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: InnoDB problems

2001-09-10 Thread Nuno Dias

On Mon, Sep 10, 2001 at 02:28:05PM +0300, Heikki Tuuri wrote:
 Nuno,
 
 I noticed a similar unexplained restriction
 on our Linux 2.4. We have 512 MB physical memory,
 no swap partition, and for some reason I cannot
 malloc more than 256 MB. The Unix errno just says
 'Cannot allocate memory'.
 
 On our other machine with 900 MB RAM and 512 MB swap
 I can malloc 900 MB.
 
 What is your my.cnf like? Is it possible that you
 have allocated so much memory to PostgreSQL, MyISAM,
 and other programs that the 2 GB or 3 GB you have is
 almost totally used?

Here's my.cnf:

[mysqld]
innodb_data_file_path = data/data1:2000M;data/data2:2000M
innodb_data_home_dir = /servers/mysql/
set-variable = innodb_mirrored_log_groups=1
innodb_log_group_home_dir = /servers/mysql/data/logs/
set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=50M
set-variable = innodb_log_buffer_size=20M 
innodb_flush_log_at_trx_commit=0
innodb_log_arch_dir = /servers/mysql/data/logs/
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=50M 
set-variable = innodb_additional_mem_pool_size=20M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50
innodb_flush_method=O_DSYNC


This problem arose before the installation of PostGres. Even then I could not reserve 
more than 50M for innodb_buffer_pool_size.
The only thing that is also running on the machine is a HTTP server that uses at most 
60M of mem.


 
 At 10:55 AM 9/10/01 +0100, you wrote:
 On Fri, Sep 07, 2001 at 08:47:16PM +0300, Heikki Tuuri wrote:
  Nuno,
  
  what does
  
  ulimit -a
  
  say (assuming you are running on Unix)?
  ulimit tells the limits set for the user.
  I think there are also hard limits decided
  at kernel compile time.
 
 core file size (blocks)  0
 data seg size (kbytes)   unlimited
 file size (blocks)   unlimited
 max memory size (kbytes) unlimited
 stack size (kbytes)  8192
 cpu time (seconds)   unlimited
 max user processes   256
 pipe size (512 bytes)8
 open files   1024
 virtual memory (kbytes)  2105343
 
 I'm running Linux.
 
  
  What does
  
  free
  
  say?
  
 
  total   used   free sharedbuffers cached
 Mem:   20967202094180   2540  01073620 786400
 -/+ buffers/cache: 2341601862560
 Swap:  1052248   32921048956
 
 
 But I'm running two SQL servers (MySQL and PostGres) and I'm running some
 scripts. Apart from that, the machine is totally dedicated to SQL stuff.
 When installing InnoDB I should have most of the memory available.
 
 
  Regards,
  
  Heikki
  http://www.innodb.com
  
  Nuno Dias wrote:
   
   I installed mysql with innodb support on a machine with 2G of RAM. 
   The manual recommends that one should set innodb_buffer_pool_size in
  my.cnf to 
  up to 80% of the physical memory available.
   
   However, if I set a value above 50M!!! I get this error:
   
   Innobase: Fatal error: cannot allocate memory!
   Innobase: Cannot continue operation!
   Innobase: Check if you can increase the swap file of your
   Innobase: operating system.
   010906 15:31:27  mysqld ended
   
   Anyone as any clue about this?
-- Nuno Dias [EMAIL PROTECTED]
   Novis - Dir. Rede - ISP http://www.novis.pt/
   Ed. Atrium Saldanha - Pça. Dq. de Saldanha, 1, 7o / 1050 - 094 Lisboa
   tel: +351 21 0104437 - fax: +351 21 0104301 
   I may not be able to walk, but I drive from a sitting position.
  
  
  
  -
  Before posting, please check:
 http://www.mysql.com/manual.php   (the manual)
 http://lists.mysql.com/   (the list archive)
  
  To request this thread, e-mail [EMAIL PROTECTED]
  To unsubscribe, e-mail [EMAIL PROTECTED]
  Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
  
 
 -- 
 Nuno Dias [EMAIL PROTECTED]
 Novis - Dir. Rede - ISP http://www.novis.pt/ 
 Ed. Atrium Saldanha - Pça. Dq. de Saldanha, 1, 7o / 1050 - 094 Lisboa
 tel: +351 21 0104437 - fax: +351 21 0104301
 
 
 Brandy Davis, an outfielder and teammate of mine with the Pittsburgh Pirates,
 is my choice for team captain.  Cincinnatti was beating us 3-1, and I led
 off the bottom of the eighth with a walk.  The next hitter banged a hard
 single to right field.  Feeling the wind at my back, I rounded second and
 kept going, sliding safely into third base.
  With runners at first and third, and home-run hitter Ralph Kiner at
 bat, our manager put in the fast Brandy Davis to run for the player at first.
 Even with Kiner hitting and a change to win the game with a home run, Brandy
 took off for second and made it.  Now we had runners at second and third.
  I'm standing at third, knowing I'm not going anywhere, and see Brandy
 start to take a lead.  All of a sudden, here he comes.  He makes a great slide
 into third, and I scream, Brandy, where are you going?  He looks up, and
 shouts, Back to second if I can make it.
  

InnoDB problems

2001-09-07 Thread Nuno Dias


I installed mysql with innodb support on a machine with 2G of RAM.

The manual recommends that one should set innodb_buffer_pool_size in my.cnf to up to 
80% of the physical memory available.

However, if I set a value above 50M!!! I get this error:

Innobase: Fatal error: cannot allocate memory!
Innobase: Cannot continue operation!
Innobase: Check if you can increase the swap file of your
Innobase: operating system.
010906 15:31:27  mysqld ended

Anyone as any clue about this?

-- 
Nuno Dias [EMAIL PROTECTED]
Novis - Dir. Rede - ISP http://www.novis.pt/ 
Ed. Atrium Saldanha - Pça. Dq. de Saldanha, 1, 7o / 1050 - 094 Lisboa
tel: +351 21 0104437 - fax: +351 21 0104301



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php