投稿者: nakahira

MySQLのテーブルが壊れた。Incorrect keyとかCorruptとかエラーメッセージが出たのでrepairテーブルとかmyisamchkとか色々修復するべく試したがどうやっても直ってくれない。直ることは直るがデータをinsertしようとしたらまたエラーが出てその繰り返し。インデックスのキー位置と実際にテーブルに存在しているレコード数が一致していないのが原因の模様。実際にselect count(*) とかやって見た件数と修復時に表示される件数との間に差が生じているのを確認した。最後の手段として、

1. show create table targetTable でテーブル定義をメモ
2. 対象のテーブルデータを select * into outfile ‘/tmp/data.txt’ from targetTable として出力する。
3. drop table targetTable としてテーブル削除
4. create table targetTable (略　としてテーブルを再作成
5. load data infile ‘/tmp/data.txt’ into table targetTable としてデータを流し込む

という手順でやってみて、流石にこれでもエラーが出るようならお手上げだと思っていたがなんとか復旧した。

MySQL5.087をインストールしてデーモン起動してログインしようとしたら

# ./bin/mysql -u mysql
./bin/mysql: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

という風に出てログインできない。libncursesw.so.5が見つからないというわけでlibncursesをaptでインストールするも

# apt install libncurses5
パッケージリストを読み込んでいます… 完了
依存関係ツリーを作成しています
状態情報を読み取っています… 完了
libncurses5 はすでに最新バージョン (6.1+20181013-2+deb10u2) です。
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 0 個。

libncurses6がインストールされている。だがlibncurses5がこのアプリは必要らしいのでlibncursesをダウングレードできないものか調べてみたがなんか面倒くさそうなためlibncurses6にシンボリックリンクを張ってlibncurses5にみせかけることにする。（そんなことしていいのか？）

libncurses6がインストールしている場所はというと”/lib/x86_64-linux-gnu/”というわけのわからんディレクトリにインストールされているみたいのなので

ln -s /lib/x86_64-linux-gnu/libncursesw.so.6 /lib/x86_64-linux-gnu/libncursesw.so.5

でリンクを張る。どういうわけかこれでMySQLにログインできるようになった。

DBのレコード件数１８００～２０００万件程度のテーブルで全文検索した場合に、mroongaを使って検索した時にやたら時間がかかった。大体３秒～１０秒ほどselect count(*)を実行するのにかかっていて、レコード件数多いから仕方ないのかな？と思っていたらsennaで運用していたDBの方は１秒もかからずに結果が返ってくる。

マシンのスペックでいうと

mroongaDB CPU:XEON-3430 Storage:NVME SSD READ 3.5GB/s

sennaDB CPU:XEON-3430 Storage:SATA SSD READ 450MB/s

といった具合でmroongaで運用しているマシンの方が読み書き性能は圧倒的に上。DBの検索スピードに影響するのはCPUよりもストレージの読み込み速度だと思うのでこの結果はちょっと悩ましい。

explainで調べてみたところ、

explain select count(*) from table where match(column) against(‘D+ 1s103 ‘ IN BOOLEAN MODE);

+—-+————-+——-+——+—————+——+———+——+——+——————————+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——+—————+——+———+——+——+——————————+
| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Select tables optimized away |
+—-+————-+——-+——+—————+——+———+——+——+——————————+
1 row in set (2.32 sec)

これがmroongaDBで検索した結果。次にsennaDBで検索すると

explain select count(*) from table_name where match(column) against(‘D+1s103′ IN BOOLEAN MODE);
+—-+————-+——————-+———-+—————+———-+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——————-+———-+—————+———-+———+——+——+————-+
| 1 | SIMPLE | table_name | fulltext | column | column | 0 | | 1 | Using where |
+—-+————-+——————-+———-+—————+———-+———+——+——+————-+
1 row in set (0.00 sec)

という違いがある。mroongaの方は「
Select tables optimized away 」とあるので一応インデックスは働いているようだが、検索の遅さには納得できない。検索に使ったキーワードは
「1s103 」という特に変わっているワードでもないがやたら時間がかかった。他の「alaedad」とか「akaweea」とかは結果がないならないで高速に検索を終えるのに「adk323」とか「132334323」みたいな数字が多い検索だとやたら時間がかかる。mroongaは数字の検索が苦手とかそういうことがあるんだろうか。sennaだと別にそういうようなことはなく割と速く0.1秒以内に結果を返してくれる。

sennaは検索をしている間はテーブルロックがかかってしまうという弱点があり、mroongaはそれがないらしい。あとsennaは割とメモリを喰うんでテーブルロックの件もあってmysqlデーモンが落ちることが結構あるがmroongaは私の経験上では不思議とメモリ不足で落ちたことがほとんどない。検索の速度でいうと後継だからmroongaが速いのだろうと勝手に思っていたが大差ないのかもしれない。私の参照オンリーな使い方だとむしろsennaの方が速い。デーモン落ちるのは怖いがcronで見張って自動復帰設定とかやりようはあるので今更ながらsennaに戻そうかと思案中。