nr
Joined: 21 Jan 2011
Posts: 4
|
 Posted: Sat Jan 22, 2011 4:19 pm Post subject: V5.1.46 AXP Crashes when Innodb Filesize reaches 2GB. |
 |
|
Hello,
I got a server crash when the filesize of ibdata1 reached 2048M.
MY.CNF
| Code: | innodb_data_file_path = ibdata1:100M:autoextend
|
MYSQLD.LOG
| Code: | 110122 11:21:35 InnoDB: Error: Write to file /mysqldat/ibdata1 failed at offset 0 2147483648.
InnoDB: 1048576 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 22.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 22 means 'invalid argument'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
110122 11:21:43 InnoDB: Assertion failure in thread 894923648 in file MYSQL051_ROOT:[storage.innobase.fil]fil0fil.c;1 line 4161
InnoDB: Failing assertion: ret
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/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000727D98, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
MYSQLD fil0fil fil_io 60000 0000000000009528 0000000000727D98
MYSQLD buf0flu buf_flush_buffered_writes
54951 0000000000000B44 0000000000893094
MYSQLD buf0flu buf_flush_batch 55616 000000000000208C 00000000008945DC
MYSQLD srv0srv srv_master_thread 71360 00000000000039A4 00000000008BBE54
PTHREAD$RTL 0 0000000000025D0C 000000007BD33D0C
PTHREAD$RTL ? ?
PTHREAD$RTL 0 0000000000012B80 000000007BD20B80
PTHREAD$RTL ? ?
PTHREAD$RTL 0 FFFFFFFF842F2000 0000000000000000
0 FFFFFFFF8026FE94 FFFFFFFF8026FE94
%CMA-F-EXIT_THREAD, current thread has been requested to exit
MYSQL051_SRV job terminated at 22-JAN-2011 11:21:44.65
Accounting information:
Buffered I/O count: 19021859 Peak working set size: 724288
Direct I/O count: 8166983 Peak virtual size: 2041280
Page faults: 182472 Mounted volumes: 0
Charged CPU time: 0 01:37:45.75 Elapsed time: 3 20:06:53.38
|
Try to start the server again fails:
MYSQLD.LOG
| Code: | $ mysqld --ansi
110122 12:36:13 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: Error: tried to read 16384 bytes at offset 0 0.
InnoDB: Was only able to read -1.
110122 12:36:15 InnoDB: Operating system error number 22 in a file operation.
InnoDB: Error number 22 means 'invalid argument'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
$ if f$search ("mysql051_root:[mysql_server.tmp]*.*;*") .nes. ""
$ then
$ delete mysql051_root:[mysql_server.tmp]*.*;*
$ endif
MYSQL051_SRV job terminated at 22-JAN-2011 12:36:18.09
|
Now I have no idea how to continue.
Update
- OpenVMS Version is V7.3-2
- The MySQL data directory is on a ODS-5 disk with enough free space
- Disk quotas are not enabled on this disk
- Files >> 2GB can be produced on this disk with other programs, so it seems to be a MySQL related problem
----------------------------------------------------------------------------------------------
Update 2
In the meantime I did some further testing:
1.
Modified MY.CNF from
innodb_data_file_path = ibdata1:100M:autoextend
to
innodb_data_file_path = ibdata1:2048M;ibdata2:2048M;ibdata3:100M:autoextend
No success, same result as above.
2.
Modified MY.CNF to
innodb_data_file_path = ibd1:5000M;ibd2:100M:autoextend
No success, ends up in:
| Code: | $ mysqld --ansi
110123 9:06:58 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The first specified data file /mysqldat/ibd1 did not exist:
InnoDB: a new database to be created!
110123 9:07:00 InnoDB: Setting file /mysqldat/ibd1 size to 5000 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000110123 9:28:02 InnoDB: Error: Write to file /mysqldat/ibd1 failed at offset 0 2147483648.
InnoDB: 1048576 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 22.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 22 means 'invalid argument'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: Error in creating /mysqldat/ibd1: probably out of disk space
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
110123 9:28:02 [ERROR] Plugin 'InnoDB' init function returned error.
110123 9:28:02 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
110123 9:28:02 [ERROR] Unknown/unsupported table type: InnoDB
110123 9:28:02 [ERROR] Aborting |
3.
Wrote a small test program which creates a file in the MySQL data directory and writes about 3G to it.
Run this program as detached process under user [MYSQL051,MYSQL051_SRV].
Result: No problem for this process to write more than 2G. So the 2G limit is a MySQL related problem.
4.
Having no idea how to repair the obviously corrupt original InnoDB tablespace i decided to start from scratch with:
innodb_data_file_path = ibd1:2000M;ibd2:2000M;ibd3:2000M;ibd4:2000M;ibd5:100M:autoextend
and restore the databases from the binary logs via mysqlbinlog.exe and mysql.exe.
Restoring about 2G with this method takes several hours on this old machine - but it seems to be working!
Conclusion
Splitting the InnoDB tablespace into multi files can be a workaround for me. Limitations might be:
- the maximum line length in MY.CNF
- the maximum number of files in innodb_data_file_path
For later production use i will need about 100G tablespace.
One thing still makes me serious:
The fact, that MySQL corrupts its InnoDB tablespace when reaching a limit and crashes with an access violation during "InnoDB: about forcing recovery".
Greetings
nr |
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
