Percona ServerのAudit Pluginの性能についてメモ

yoku0825 @yoku0825

@i_rethi general_logはsyncせずにwriteですからねー。たぶん、全出力じゃなくてテーブルを絞ってやるのがSEMISYNC以上のレベルを選ぶ時の定石なんじゃないかなあと。

yoku0825 @yoku0825

@i_rethi まとめてみますた。 togetter.com/li/875125

ITOH Hiroyuki @i_rethi

@yoku0825 どこまで重要かによるでしょうけど、qps高い環境で取りたいならならasync(ロスト許容)、ほどほどのqpsの環境でOSクラッシュによる一部ロストを許容するならsemisyncって感じですかねー。syncは性能は二の次な重要なデータがある環境？

ITOH Hiroyuki @i_rethi

@yoku0825 まとめるんかいw

yoku0825 @yoku0825

@i_rethi asyncはロスト不許可でPERFORMANCEのみロスト許可ですね（OSクラッシュは別として） mutexの粒度的にはgeneral_logとそんなに変わらない気がするので、全出力ならSEMISYNC == general_logと同じくらいになるかなあと予想

yoku0825 @yoku0825

@i_rethi 知見なので :)

ITOH Hiroyuki @i_rethi

@yoku0825 asyncはaudit_log_buffer_size使うからMySQLクラッシュしたらロストなので。innodb_flush_log_at_trx_commit的に (0, 1, 2) = (async, sync, semisync) みたいな感じかなと

yoku0825 @yoku0825

@i_rethi MySQL単体で落ちること滅多にないから気にしてなかったです。。InnoDBは常にバッファ使いますけど、書き込みオペレーションだけ比較すると (0, 1, 2)= (semisync, sync, 該当なし) ですね

ITOH Hiroyuki @i_rethi

@yoku0825 あまり落ちないけどそこまで気にする環境もあるかなと。semi sync、do not flush and sync every event、の理解が怪しかったり。と思ったけどdo notがflushとsyncの両方にかかってる？

yoku0825 @yoku0825

@i_rethi 両方だと思います。ここ見るとたぶんわかりやすいです。 github.com/percona/percon…

ITOH Hiroyuki @i_rethi

@yoku0825 ふふふ、Cのenumの扱いどういうのか忘れてて理解するのに時間かかった。。。