| Bug #32499 | BACKUP DATABASE crashes server if database has 600 tables (any engine) | ||
|---|---|---|---|
| Submitted: | 19 Nov 2007 19:02 | Modified: | 18 Aug 21:22 |
| Reporter: | Guilhem Bichot | ||
| Status: | Can't repeat | ||
| Category: | Server: Backup | Severity: | S3 (Non-critical) |
| Version: | 5.2-bk | OS: | Linux |
| Assigned to: | Chuck Bell | Target Version: | |
| Triage: | Triaged: D1 (Critical) | ||
[24 Jun 15:06]
Rafal Somla
In the current tree I can get default driver errors already for 65 tables with this test
script:
------------------------------------------------------------------------------
CREATE DATABASE db1;
USE db1;
let $engine=archive;
let $tcount=65;
while ($tcount)
{
eval CREATE TABLE t$tcount (a int) ENGINE=$engine;
dec $tcount;
}
BACKUP DATABASE db1 TO 'db1.bkp';
RESTORE FROM 'db1.bkp' OVERWRITE;
SHOW TABLES IN db1;
DROP DATABASE db1;
--exit
------------------------------------------------------------------------------
However, the server does not crash now.
[24 Jun 15:23]
Rafal Somla
With the above script I got server crash for 500 myisam tables.
#4 <signal handler called>
#5 0x0873da42 in _db_enter_ (_func_=0x88e879f "sql_print_error", _file_=0x88e84ce
"log.cc", _line_=6804,
_stack_frame_=0xb7352094) at dbug.c:1165
#6 0x083c37fb in sql_print_error (format=0x8997d34 "%s") at log.cc:6804
#7 0x0882bfa0 in backup::Logger::write_message (this=0xb7352ef8,
level=backup::log_level::ERROR, error_code=1685,
msg=0xb7352324 "Error when sending data (for table #7) to MyISAM restore driver") at
logger.cc:63
#8 0x0882c246 in backup::Logger::v_write_message (this=0xb7352ef8,
level=backup::log_level::ERROR, error_code=1685,
format=0x994e1d3 "Error when sending data (for table #%d) to %-.64s restore driver",
args=0xb7352598 "\a") at logger.cc:148
#9 0x0882c2c1 in backup::Logger::v_report_error (this=0xb7352ef8,
level=backup::log_level::ERROR, error_code=1685,
args=0xb7352598 "\a") at logger.cc:132
#10 0x0881d919 in backup::Logger::report_error (this=0xb7352ef8, error_code=1685) at
../../sql/backup/logger.h:148
#11 0x0882005b in backup::restore_table_data (thd=0x9ac0390, info=@0x9b07900,
s=@0xa10a470) at data_backup.cc:1674
#12 0x08818fb4 in Backup_restore_ctx::do_restore (this=0xb7352ef8, overwrite=true) at
kernel.cc:1483
This looks wierd because crash is inside DBUG_ENTER. To many levels of DBUG nesting?
Note that the backup related problem is that MyISAM restore driver reports error in
send_data() method.
[14 Aug 3:22]
Chuck Bell
It appears this problem has been solved. I have successfully created 32,000 tables and executed a backup and restore. Creating a formal test to prove/disprove the premise.
[18 Aug 21:22]
Chuck Bell
Ranger's performance testing routinely test 15000 tables. Clearly, this demonstrates this bug is not repeatable.
Description: I'm using the 5.2-backup tree which is now dead since 2 weeks, but 6.0-backup probably has the same issue. Build is BUILD/compile-pentium-valgrind-max. If I create 300 ARCHIVE tables in database "test2", "BACKUP DATABASE test2 TO some_file" works ok. If I create 300 more tables in "test2" (so, 600 in total), it crashes. The places of crash are not constant; here's one: mysqld: sql_base.cc:1264: bool close_thread_table(THD*, TABLE**): Assertion `!table->file || table->file->inited == handler::NONE' failed. Using MyISAM tables gives same problem. Probably engine-independent. How to repeat: Write a simple script to create 600 ARCHIVE tables. Possible with a stored procedure (I don't remember how but PeterG is good at this); I used python: import sys assert (len(sys.argv) == 5), "need 4 args: engine, db, low, high" eng=sys.argv[1] db=sys.argv[2] L=int(sys.argv[3]) H=int(sys.argv[4]) for i in range(L,H): print "create table "+ db +".t" + repr(i) + " (a int) engine=" + eng + ";" then run it as "python the_prog_above.py archive test2 1 601" Then start a mysqld (no particular option), and do "BACKUP DATABASE test2". It crashes for me. Note that: "lock tables test2.t1 read , test2.t2 read, <all tables> ..., test2.t600 read;" works ok.