日々の覚書

MySQL公式のrpmバイナリをインストールする手順。
今回入れたのはMySQL-5.5.24-1.el6.x86_64。

glibcを入れ直す。
# rpm -i --force glibc-2.12-1.47.el6_2.12.x86_64.rpm glibc-common-2.12-1.47.el6_2.12.x86_64.rpm
　⇒要らなかった。。ごめんなさい。

perlモジュールを入れる。/usr/bin/perlがある場合には不要。
perl本体以外はperlの依存関係で入れてるだけ。

# rpm -i perl-libs-5.10.1-119.el6_1.1.x86_64.rpm perl-5.10.1-119.el6_1.1.x86_64.rpm perl-Module-Pluggable-3.90-119.el6_1.1.x86_64.rpm perl-Pod-Simple-3.13-119.el6_1.1.x86_64.rpm perl-version-0.77-119.el6_1.1.x86_64.rpm perl-Pod-Escapes-1.04-119.el6_1.1.x86_64.rpm

ほどいたtarボールの中身を入れる。
# rpm -i MySQL-*.rpm

これでOK。
前のコンパイルに必要なパッケージも加筆しておこうかな。。


おまけにinnotopも入れた。
perl-DBD-MySQLを入れる時に、libmysqlclient.so.16が無いって怒られたのでシンボリックリンク作る。
　⇒perl-DBD-MySQLを入れる前にCentOSリポジトリのmysql-libsを入れていたので、
　　perl-DBD-MySQLがそっちのlibmysqlclient.so.16を掴んでいたから。
　　さらからMySQL-shared-compatを入れていればこんなことにはならない。
　　ごめんなさい。。

# cd /usr/lib64 ; ln -s libmysqlclient.so.18.0.0 libmysqlclient.so.16 ; cd -


innotopはmakeせずに、ほどいたのをそのまま./innotopで使う暴挙。


この一連、スクリプトにでもしようかな。


【2012/07/28】
盛大に間違い修正。。

InnoDBでPrimary Keyを設定していないテーブルを作ると
おそろしくレスポンスが悪くなるという話だったので、試してみる。

CREATE TABLE t1 (num int not null,val varchar(50) not null);


用意したINSERT文。

INSERT INTO t1 VALUES (1,'1');
INSERT INTO t1 VALUES (2,'2');
...
INSERT INTO t1 VALUES (65535,'65535');


UPDATE文。
UPDATE t1 SET val = '....' WHERE num = 1;

...



DELETE文。
DELETE FROM t1 WHERE num = 1;
...


key全くなし。
INSERT 8sec、UPDATE 1hour34min17sec、DELETE 31min46sec。

PRIMARY KEY(num)
INSERT 9sec、UPDATE 15sec、DELETE 12sec。

UNIQUE KEY(num)
INSERT 9sec、UPDATE 11sec、DELETE 11sec。

KEY(num)
INSERT 9sec、UPDATE 12sec、DELETE 11sec。


ただのKEYとPRIMARY KEYで多少差が出てくれるかと思ってたけど、そうでもなかった。
件数増やしたら多少出るかしら。

あと、レプリケーション環境でPrimary Keyがないと悲惨なことになったりする場合もあるので、
やっぱりセオリー通りSERIALでも良いからPrimary Keyは付けましょうって感じで。
　⇒Primary Keyがないテーブル その２

・mysqldを再起動してすぐにtpcc-mysqlでI/Oバウンドする負荷を1時間与える

リリースノートから抜粋。

・4.0（2003/3/15 4.0.12から正式版）
InnoDB導入
クエリキャッシュ導入
MERGEエンジンがINSERTとAUTO_INCREMENTをサポート
UNIONクエリ導入
複数テーブルのDELETE導入


・4.1（2004/10/23 4.1.7から正式版）
SUBSTRING関数がposに負の引数を取れる様になった
サブクエリ導入
INSERT ... ON DUPLICATE KEY UPDATE導入
GROUP_CONCAT導入
UTF8サポート
カラム、テーブル、スキーマ単位で文字コードを設定できるように
HEAPエンジンでBTREEインデックスを使えるように
SHOW WARNINGS実装
CREATE TABLE ... LIKE ...構文追加
HELP構文はこのバージョンから
以前はTIMESTAMP型の戻り値は`yyyymmddhhnnss'と整数値で戻っていたが、`yyyy-mm-dd hh:nn:ss'の文字列値で戻る様になった
0xで始まる値はバイナリ値として評価されるようになった（てことは、前は暗黙に変換してたのか）
AUTO_INCREMENT属性のカラムにDEFAULTを設定しようとするとエラーになるようになった（前は設定できるけど無視される）
LIMITが負の引数を受け付けなくなった
これ以前のバージョンではsql_mode='SERIALZIE'が出来たらしいが、このバージョンからSET TRANSACTION ISOLATION LEVEL SERIALIZE; で設定する
.frmファイルのフォーマットが変わったので、過去のバージョンとのデータ互換性がない
権限テーブルのパスワードハッシュが変更されている


・5.0（2005/10/19 5.0.15から正式版）

information_schemaの導入
ARCHIVEエンジンとFEDERATEDエンジンの導入
ストアドプロシージャ実装
トリガー実装
ビュー実装
VARCHAR型の最大データ長が2^16-1bytesへ


・5.1（2008/11/14 5.1.30から正式版）パーティショニング
RBR
イベントスケジューラ
ログをTable上に吐ける
NDBクラスタ間レプリケーション
NDBクラスタのDISK使用可


・5.5（2010/12/3 5.5.8から正式版）
InnoDBがデフォルトストレージエンジンに
準同期レプリケーション
DATE,DATETIME型がそのままPARTITION RANGEに使えるように
ALTER TABLE ... TRUNCATE PARTITIONの実装
結構システム変数名が変わってる（というか互換用だった古いのが消えた）


・5.6(2012/8/7 5.6.6現在でまだ開発版）
information_schemaにInnoDBバッファ関連のテーブルが増えた
ALTER TABLE ... EXCHANGE PARTITIONの実装
performance_schemaに項目が結構増えた
Delayed Replicationの実装
slave-parallel-workersの実装
EXPLAINがINSERT,UPDATE,DELETEでも使えるように
CREATE TABLE .. DATA DIRECTORYが.ibdファイルに対しても有効に
InnoDB memcached Pluginが追加
InnoDBのデッドロック情報をエラーログに出せるように
InnoDB Undo Logスペースをibdata1から独立させられる
mysqld正常停止時にバッファプールの中身をダンプし、起動時にそれを読み込む機能。バッファプールのウォームアップが出来る。
パスワードのexpire_dateが設定可能に
InnoDBがFullText INDEXをサポート
SELECT文でパーティションを指定して取り出せるように
派生テーブルが実体化されてINDEXとか使えるように

まず、日本標準時プロジェクトの`Perl版SNTPサーバ　うるう秒テスト用バージョン'をコピペ。
現在時刻でLIを01にしてくれる様にパラメータをちょこちょこ書き換える。


…なんかLI以外もいじっている気がして自分で書きたかったんだけど、本業（？）で時間を食われたのでパス。
車輪の再発明大好きだけど。




で、隣のホストから（ポート入れ替えるの面倒）ntpdateでアクセス。
tcpdumpで見る限り、LIは01でちゃんと返っている。
ここからadjtimexを見てStatusが16(=inserting leap second)になっていれば大満足なんだけど、
Statusは64(=clock unsynchronized)。


なんかadjtimexのステータスを勘違いしてるのかな。。


kernel-2.6.18のSRPMを落としてきて、timer.cをいじって再コンパイル。
LI無視して、毎00秒に閏秒を無理矢理挿入するロジックに変更する。
　⇒と思ったら、一度00秒を迎えると毎秒閏秒扱いにしていつまでも59秒から時間が進まないカーネルが出来上がった。
　　printkで毎秒、leap secondをINSERTしたよって言っててかなりコンソールがうるさい。

再現させて気付いたんだけど、閏秒は00:00:00 UTCかつLI=1のときにタイマーをデクリメントしてるから、
23:59:59 UTCが2秒続いて次は00:00:00って動きになるのね。
（だから59秒から時が進まなくなったのだ、私のカーネル）


今のところCPU振り回して(cat /dev/urandom > /dev/null &でCPU数の倍タスクを回す）もハングしないなぁ。。
printkはちゃんと利いてるから、想定どおりに動いてはいるはずだけど。
VirtualBoxだからいけないのかしらん。
時間があればPCサーバでコンパイルしなおそう。。

VirtualBoxゲストOSのI/O速度に関係するもの。

閏秒関連でちょろちょろ見て回っていて思ったこと。
00秒が連続で来て、crondは誤動作しないのか。
聞いたことないからしないんだろうけど、ちょっと気になる。

あと、crondに何か軽いことをやらせると、決まってログが01秒あたりに出るので、
time_t % 60 == 1の時に処理をするのかなという感もある。

straceでcrondにattachした。
-tオプションでシステムコール発行時刻が、
-ttオプションでマイクロ秒まで出してくれる。

13:25:01.783074 gettimeofday({1337228701, 783236}, NULL) = 0
13:26:01.796409 gettimeofday({1337228761, 796515}, NULL) = 0
13:27:01.809964 gettimeofday({1337228821, 810089}, NULL) = 0

大体、毎分こんな感じで処理が始まっているので、概ね外れていなさそう。


13:33:01.994653 nanosleep({60, 0}, 0x7fff1cf6ba10) = 0
13:34:02.004750 nanosleep({59, 0}, 0x7fff1cf6ba10) = 0
13:35:01.022515 nanosleep({60, 0},

毎分の処理の終わりはこんな。
うん、01秒を狙って動いてる。


crondのソース読みたくなってきた。

SHOW STATUSのInnodb_buffer_pool_pages_flushedの値が、
実際の値の2倍に表示されるらしい。

5.5.25(未リリース)でFIXされるらしい。

http://bugs.mysql.com/bug.php?id=65030

スロウクエリの時間計算にバグがあり、クエリの完了時間 - クエリの開始時間が負数になると、
負数として扱われずにそのまま符号なしで計算される。

http://bugs.mysql.com/bug.php?id=35396

たとえば7/1 08:59:60.53(システム上の扱いは09:00:00.53)～7/1 09:00:00.13にかけて実行されたクエリは、
-0.40秒の実行となり…浮動小数点演算の補数計算できないけど、とにかく最上位のビットが立つので馬鹿みたいな大きな数になる。
⇒スロウログに、馬鹿でっかいQuery_timeのエントリがずらずら並びそう。

5.1系は5.1.63で修正されている。
5.5.0-m2でも再現したけれど、5.5.20-ndb-7.2.5では再現しなかった。
5.5系はどこで修正されたんだろ。


# Time: 120516  0:00:09
# User@Host: root[root] @ localhost []
# Query_time: 18446744062814.714844  Lock_time: 0.053146 Rows_sent: 1  Rows_examined: 5760001
SET timestamp=1337094009;
select 1 from settlement order by rand() limit 1;


Slow_queriesの回数グラフにしてたりする場合は注意。
いやQuery_timeが明らかにおかしいから大丈夫だと思うけれど。


あと、逆に7/1 08:59:60.53(システム上の扱いは09:00:00.53)～7/1 09:00:01.00にかけて実行されたクエリは、
1.47秒かかってるけど時間の差分が0.47秒になっちゃうのでスロウログには載らない。
こっちはどうでも良いかな。

SLEEP関数と時刻の巻き戻り で、ついでに/bin/sleepの動作も気になったのでやってみた。

 # date ; sleep 10 ; date
Wed May 16 00:40:44 JST 2012
Wed May 16 00:00:09 JST 2012

うむ。

閏秒関連でテストしてみたら、面白い事に気付いた。


+----------+
| SLEEP(5) |
+----------+
|        0 |
+----------+
1 row in set (1 min 12.84 sec)

作業環境はVirtualBoxをずっと愛用している訳だけれども、最近ようやく知った罠。

VBoxServiceが提供している機能は今知っている限り2つ。
（あ、X11は使ってない）

1) 共有フォルダの自動マウント
2) 時刻を一定周期（？）でホストOSのものと合わせる

2)のおかげで閏秒のテストするのにすごく疲れた。。
気付くの遅すぎた(´･ω･｀)

ファイル名にホスト名が入るの嫌いなので。。

log-bin=bin
binlog-format=mixed
skip-general-log
general-log-file=general.log
log-error=error.log
slow-query-log
slow-query-log-file=slow.log
long-query-time = 1
log-output=FILE

本当に調べるかどうかは判らない。。
分岐パッチが判ったので、もうこれ以上調べない。。


1) Red Hat5.2 kernel2.6.29で見付かった閏秒のタイミングでkernel hangする問題。
https://bugzilla.redhat.com/show_bug.cgi?id=479765

RHEL5.4でFIX。パッチもあり。
http://rhn.redhat.com/errata/RHSA-2009-1243.html

CentOSだけど、kernel-2.6.18-164.el5.src.rpmを調べたら
linux-2.6-misc-fix-leap-second-hang.patch ってパッチが入ってた。
Red Hat系の分岐点はここかな？ CentOSとRed Hatってやっぱり多少違うのか？
http://vault.centos.org/5.4/os/SRPMS/

Debianを追ってたら2.6.26-20でFIXされたとか書いてある。
-の後ろはDebian独自の番号なのかな？
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510478

Debianはもう調べる気力がない。。


2009/1/1以降にリリースされたやつから実物当たるしかないかなぁ。。
http://www.kernel.org/pub/linux/kernel/v2.6/
⇒2009/1/14リリースの2.6.27.11では未FIXだった。

ここで見つけた。

http://github.com/mirrors/linux-2.6/commit/bd3312681f69207a40431981c1bce1afdc9b7975#kernel/time/ntp.c
⇒2012/1/26の更新…って今年か。。


見つけたけど、関数ごと置き換わってて、詳しくない俺には直ってるのか判らない。。
⇒write_seqlock_irq/write_sequnlock_irqって関数がspin_lock_irq/spin_unlock_irq関数に変わってて、
　xtime_lockがntp_lockに変わってる。ロックの構造体は見てない。


http://lkml.org/lkml/2009/1/2/373
⇒CPUをぶん回すと再現する、って書いてあるし、自前でカーネルコンパイルして試すか…。
⇒コンパイルしてCPUぶん回してみたけどハングしない。
VirtualBoxだからだろうか。。PCサーバでやりたいけど、7/1までに間に合うかな。。


2) MySQL 5.1.63で修正されたらしい、slow-query-logのquery timeが負数になるとunsignedで解釈しちゃうやつ。
以前のバージョンだと閏秒のタイミングで起こりそうで、slow-query-logを食わせているスクリプトがあると問題になりそう。

http://bugs.mysql.com/bug.php?id=35396
⇒こっちに動作確認した分だけメモ。


3) 前のWindowsは23:59:60を挿入しない動作っぽかったけど、今も？

http://support.microsoft.com/kb/909614/


4) そういやJavaScriptやPerlとか、23:59:60を許容するんだろうか？
ログを食わせて内部処理しているプログラムはどうなるか。。
（2008/12/31以降に台頭してきたものだけ考慮すれば良いか）
⇒なんかとんでも勘違いで、システム的には23:59:60は存在せずに、00:00:00が2秒間続くのね。。
恥ずかし。
⇒無理矢理再現させて初めて気付いたんだけど、システム的には23:59:59が2秒続いて00:00:00みたい。なんかもうね_|￣|○


5) このテクニックで、23:59:60を１時間くらい作れないもんだろうか。
そしたら色々検証はかどりそう（やるかどうかは別として）

http://elinux.org/images/4/46/Long-termTestingOnAcceleratedLinuxKernel-yoshi.pdf

Virtualboxで動かしている仮想マシンに、FIXEDのHDDをつなげたいとき。
（オンデマンドで自動拡張じゃなくて、その大きさのファイルを先に作る）

vdiファイルを作ってる間にわざわざ仮想マシン止めて待ちたくないのでコマンドラインから。


$ VBoxManage createhd --filename test.vdi --size 10240 --variant Fixed
⇒sizeはMB単位。

VBoxManageで作ったファイルはGUIで引っ付けても良いし、CUIならこう。
$ VBoxManage storageattach cent01 --storagectl SCSI --port 3 --type
hdd --medium test.vd
⇒コントローラ名に日本語が入っていると幸せになれない。
⇒ポート番号調べる必要がある。

ホットプラグに対応したコントローラならオンラインでも付けられる。
というか、オフラインでやるならGUIの方が判りやすい。

何度か転けたのでメモ。

1) datadirのib_logfile*は消しておく
⇒同時に作らないとダメ。全部初期化してから怒られると再作成がかなり切ない。

2) ボリュームサイズギリギリだと容量超過することがあるのでちょっとだけ減らす。
⇒これが、指定したinnodb_data_file_pathの容量分初期化してから「足りない」と言い始めるから困る。。

3) mysqldの実行ユーザーをdiskグループに追加しておく。
⇒でないとデバイスが開けないと怒られる。

4) エラーログの監視を絶対に怠らない。
⇒これが何よりか。。。

CentOS-6.2-i386-minimal.iso を入れた後に、Percona-Toolkitをコンパイルするのに必要なパッケージ。

Perl＆CPANだけyumで入れて、他はCPANから入れる。
yumもCPANも依存関係で入るパッケージは突っ込む前提。

perl(yumから)
perl-CPAN(yumから)
DBI(CPANから)
DBD::mysql(CPANから)



コンパイルできてもランタイムでモジュールが無いとかエラー言われるのがあった様な無かった様な。。
というかリストにして初めて気付いたけど、基本的にDBD::mysql以外はほぼ標準のパッケージしか使ってないのか。。

mysqldの状況をなんとなく眺めるのに使うtopの設定

top起動する
d … 表示間隔を5～10秒に変える
i … アイドルしてるプロセスを非表示にする
H … スレッド単位で表示させる
t … 表示項目設定画面開く
⇒t … SHARED MEMORYのカラム消す
⇒p … SWAP量表示させる
⇒j … 最後に使ったCPU番号表示させる
⇒Enterたたいて抜ける
O … ソート設定画面開く
⇒j … 最後に使ったCPU番号でソート
⇒Enterたたいて抜ける
R … ソートを逆順にする

コアが均等に使われてなければI/Oバウンドを疑う。


全部設定したら、
W … 設定を~/.toprcに書き込む。次回からこれが読み込まれる。

tpcc-mysql同梱のload.shは色々問題があったのでメモ。

CentOS-6.2-i386-minimal.iso を入れた後に、MySQLをコンパイルするのに必要なパッケージ。
yum解決してくれる依存パッケージは割愛。

gcc
make
gcc-c++

cmake
ncurses-devel

cmakeした時にbisonがどうこうwarningが出るけど、取り敢えずコンパイルは可能。

o conf build_requires_install_policy yes
o conf prerequisites_policy follow
o conf commit

性格がバレるｗ