Description:
copying a table with a fulltext index via
insert into ft1 select * from ft2;
into a identical table sometimes leads to select error 1191
when concurrent select's are running.
this happens in an enviroment where the searched table is
periodically created as a temporary table and finally
copied into the searched table.
so the locking time is restricted to copying and the
searches running parallel are not locked while creating
the new search table.
the error 1191 occurs to the search selects after copying, but
only sometimes not always.
without running concurrent selects while copying,
the error seems not to happen.
the mysql database version is fresh fetched from the server:
mysql-5.0.51a-linux-i686-glibc23.tar.gz
but this error could be reproduced with v5.0.45 too.
How to repeat:
script 1:
create a table with a fulltext indexed column,
fill with some data and run selects on this
table in a loop.
in this test the select result is not of interest,
only if there is a problem flagged, or a success exit code.
script t1.sh:
---------------------------------------------------------------
#!/bin/bash
##
## create table ft1 with one fulltext column:
##
mysql -B test <<EOF
drop table if exists ft1;
CREATE TABLE ft1 (
data text NOT NULL,
FULLTEXT KEY data (data)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
EOF
max=1000
##
## fill table with data:
##
i=0
while [ $i -lt $max ] ; do
i=$(($i + 1))
echo "insert into ft1 values ('textstring');"
done | mysql -B test
##
## loop endless selecting data.
##
## on success (regardless if there is a match) print a . on success
## or print the mysql error message.
##
while true ; do
mysql -B test -e "select match (data) against ('something'), data \
from ft1 where match (data) against ('something')" > /dev/null
if [ $? = 0 ] ; then
echo -n .
fi
done
exit 0
---------------------------------------------------------------
script 2:
the second script does the copying forth and back:
- drop the temp table, create and fill it.
- lock
- empty search table and fill from temp table
- unlock
running the second script with a parameter sets the count how
many times this copying should be done.
script t2.sh:
---------------------------------------------------------------
#!/bin/bash
if [ "$1" != "" ] ; then
loop=$1
else
loop=99999
fi
i=0
while [ $i -lt $loop ] ; do
i=$(($i + 1))
mysql -B test <<EOF
drop table if exists ft2;
create table ft2 like ft1;
insert into ft2 select * from ft1;
lock table ft1 write, ft2 read;
delete from ft1;
insert into ft1 select * from ft2;
unlock tables;
select count(*) from ft1;
EOF
done
---------------------------------------------------------------
testing:
- run t1.sh
should start printing dots for every select:
.............................
[...]
- run t2.sh
t2 should print the select count(*) output for every loop run:
count(*)
1000
[...]
- as t2.sh starts, the first script starts to output errors between
the successful dots:
ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
.......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
.......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
[...]
the spurious behavior can be observed by running the t2.sh copy script
manyally one copy after an other:
t2.sh 1
t2.sh 1
[...]
somtimes the output of the t1.sh looping script changes to only
errors, flagging a broken table:
ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
[...]
and then continuing with the copies:
t2.sh 1
t2.sh 1
[...]
the output of the t1.sh looping script changes
back to dots, showing the table is usable.
Suggested fix:
a fix is not known.
a usable workaround seems to be adding a repair table quick:
insert into ft1 select * from ft2;
+ repair table ft1 quick;
unlock tables;
Description: copying a table with a fulltext index via insert into ft1 select * from ft2; into a identical table sometimes leads to select error 1191 when concurrent select's are running. this happens in an enviroment where the searched table is periodically created as a temporary table and finally copied into the searched table. so the locking time is restricted to copying and the searches running parallel are not locked while creating the new search table. the error 1191 occurs to the search selects after copying, but only sometimes not always. without running concurrent selects while copying, the error seems not to happen. the mysql database version is fresh fetched from the server: mysql-5.0.51a-linux-i686-glibc23.tar.gz but this error could be reproduced with v5.0.45 too. How to repeat: script 1: create a table with a fulltext indexed column, fill with some data and run selects on this table in a loop. in this test the select result is not of interest, only if there is a problem flagged, or a success exit code. script t1.sh: --------------------------------------------------------------- #!/bin/bash ## ## create table ft1 with one fulltext column: ## mysql -B test <<EOF drop table if exists ft1; CREATE TABLE ft1 ( data text NOT NULL, FULLTEXT KEY data (data) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; EOF max=1000 ## ## fill table with data: ## i=0 while [ $i -lt $max ] ; do i=$(($i + 1)) echo "insert into ft1 values ('textstring');" done | mysql -B test ## ## loop endless selecting data. ## ## on success (regardless if there is a match) print a . on success ## or print the mysql error message. ## while true ; do mysql -B test -e "select match (data) against ('something'), data \ from ft1 where match (data) against ('something')" > /dev/null if [ $? = 0 ] ; then echo -n . fi done exit 0 --------------------------------------------------------------- script 2: the second script does the copying forth and back: - drop the temp table, create and fill it. - lock - empty search table and fill from temp table - unlock running the second script with a parameter sets the count how many times this copying should be done. script t2.sh: --------------------------------------------------------------- #!/bin/bash if [ "$1" != "" ] ; then loop=$1 else loop=99999 fi i=0 while [ $i -lt $loop ] ; do i=$(($i + 1)) mysql -B test <<EOF drop table if exists ft2; create table ft2 like ft1; insert into ft2 select * from ft1; lock table ft1 write, ft2 read; delete from ft1; insert into ft1 select * from ft2; unlock tables; select count(*) from ft1; EOF done --------------------------------------------------------------- testing: - run t1.sh should start printing dots for every select: ............................. [...] - run t2.sh t2 should print the select count(*) output for every loop run: count(*) 1000 [...] - as t2.sh starts, the first script starts to output errors between the successful dots: ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list .......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list .......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list [...] the spurious behavior can be observed by running the t2.sh copy script manyally one copy after an other: t2.sh 1 t2.sh 1 [...] somtimes the output of the t1.sh looping script changes to only errors, flagging a broken table: ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list [...] and then continuing with the copies: t2.sh 1 t2.sh 1 [...] the output of the t1.sh looping script changes back to dots, showing the table is usable. Suggested fix: a fix is not known. a usable workaround seems to be adding a repair table quick: insert into ft1 select * from ft2; + repair table ft1 quick; unlock tables;