各務 洋
kagam****@outwa*****
2015年 10月 7日 (水) 20:04:33 JST
お世話になります、各務です。
>>> select --table tbl_test_pat_0005
>> [[0,1444042564.47682,0.042431116104126],[[[2],[["_id","UInt32"],["_key","Int64"],["a_id","Int64"],["id","Int64"],["t1_date","Time"],["t2_date","Time"],["t_text","LongText"]],[248,964278,0,0,0.0,0.0,""],[248,964278,0,0,0.0,0.0,""]]]]
>
> え、あれ。。。重複したレコードがでていますね。。。
> このテーブルは一度問題が発生したテーブルをそのまま使ったもの
> ですか？それとも作りなおしたものですか？
テスト毎にDBそのものを新しく作っていっています。
（修復のテスト用にも多数の壊れた状態が欲しいので）
----------------------------------------------------------------------
CREATE DATABASE db_testa8;
USE db_testa8;
CREATE TABLE `tbl_test_pat_0005` (
`id` BIGINT(20) NOT NULL AUTO_INCREMENT,
`t1_date` TIMESTAMP NOT NULL DEFAULT current_timestamp,
`t2_date` TIMESTAMP NOT NULL DEFAULT '0000-00-00',
`a_id` BIGINT(20) NOT NULL Default 0,
`t_text` LONGTEXT,
PRIMARY KEY (`id`),
UNIQUE KEY `a_id` (`a_id`),
FULLTEXT INDEX `t_text` (`t_text` ) COMMENT 'normalizer "NormalizerMySQLUnicodeCIExceptKanaCIKanaWithVoicedSoundMark"'
) ENGINE=mroonga DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
# 負荷テスト
while true; do mysql -tN db_testa8 <./mixa1.sql 2>&1|tee -a v1.txt; done
while true; do mysql -tN db_testa8 <./mixa1.sql 2>&1|tee -a v2.txt; done
while true; do mysql -tN db_testa8 <./mixa1.sql 2>&1|tee -a v3.txt; done
while true; do mysql -tN db_testa8 <./mixa1.sql 2>&1|tee -a v4.txt; done
# 動作確認用
while true; do mysql -D db_testa8 -e "SELECT (SELECT current_timestamp) AS '', (SELECT id AS '' FROM tbl_test_pat_0005 ORDER BY id DESC LIMIT 1) AS '';";done;
# 頻繁にKillしないようにする。
ALIVETIME=0; while true; do date +'%Y%m%d %H:%M:%S'.$(printf '%03d' $(expr `date +%N` / 1000000)); grndb check /var/lib/mysql/db_testa8.mrn||if [ $ALIVETIME -gt 30 ]; then kill -9 `ps ax|egrep -i "/usr/sbin/mysqld --basedir"|egrep -v "grep"|awk '{print $1}'`; ALIVETIME=0; fi; ((ALIVETIME ++)); echo ${ALIVETIME}; sleep 1s; done;
----------------------------------------------------------------------
上記の「db_testa8」の部分を一括置換して、どんどん行っています。
mixa1.sql の中身は
SELECT current_timestamp; DELETE FROM tbl_test_pat_0005 WHERE a_id = 10001; INSERT INTO tbl_test_pat_0005 (a_id, t_text) VALUES (10001,'t10001');
SELECT current_timestamp; DELETE FROM tbl_test_pat_0005 WHERE a_id = 10002; INSERT INTO tbl_test_pat_0005 (a_id, t_text) VALUES (10002,'t10002');
↑これを500回繰り返しています。
> 一度問題が発生したならすでに壊れていてこうなることはありそう
> ですが、作りなおしてしかもlock_clearを使っていないでこれにな
> るなら、だいぶおかしいですね。。。
lock_clear 無しで、上記の方法で昨日は1回だけ、Killのタイミングと関係な
く破損しました。
Kill 有りでも、概ね1時間弱回すと再現できる事が多いです。
> テーブルをトラバースするとでてこなくて、直接IDを指定すると
> （インデックスで見つけたときは直接IDを指定してレコードをとり
> だします）でてくるということですね。完全に壊れていますね。。。
>
おぉ、よろしくお願いしまーす。
そこで１点、ふと疑問に思ったのですが、Index を修復する際に、既に Unique
違反になっているレコードはどのようにするお考えでしょうか？
というのも、ALTER TABLE にかける際にも、AUTO_INCREMENT 外して、Primary Key
と Unique Key 外して重複分を探して削除して元に戻す必要があったので……。
（ALTER TABLE に失敗して Duplicate と出たら↑をやるようにしてみました）
私は主キーが使えないのはツラいを言い訳に、ガッと削除にしました。
P.S
本日早朝に本番環境での作業があったのですが、やはり日付時刻型の index
不良が発生したとの報告がありました。
----
各務
kagam****@outwa*****