質問: MySQLのデータベースログを常時解析してデータの更新を検知する手法を学びました。データベースのログといってもファイルなのですから工夫しない限り常時監視という手法はかなり高いI/Oコストや解析コストがかかると思います。 さらに実際のプロダクトではデータベースの吐き出すログは非常にデータサイズが大きいと思います。 ここで質問なのですが例えばマルチスレッディングのプログラムでいくつものスレッドでファイルを読み通り専門にして参照し、異なるファイルのインデックス地点(例えばログファイルのうち何行目か、など)を参照させてファイル解析のスループットをあげるといったことは可能なのでしょうか? その手法では、データベースログの読み取り始める箇所をばらばらにしておいて(なんらかの並列処理で)一気に読み始めていち早くアップデートに関するログを解析する。。。といったものでしたがデータベースログの知識に乏しいため実際にどのように実装しているのか想像できませんでした。そもそも一つのファイルなのだから単一スレッドで読んでいくスピードが実質最速なのかなとも思いますので学んだ手法がどのようなことをいっているのかわかりません。。。。 どなたかアドバイスをよろしくお願いいたします。
回答: 独自でログを分析するとデータベース・サーバは性能劣化すると思われますが、それは許容されるということでしょうか? 通常はデータベース・サーバの性能劣化を避けるために、アプリケーション・サーバ側に追跡の仕組みを入れるものですが、コードの修正が困難でRDBMS側で対応させたい時は「監査」と呼ばれる機構を使って、ユーザの操作を追跡したりします。MySQLにもその手のプラグインはあるようですよ。 6.3.12.1 監査ログプラグインのインストール - MySQL5.6リファレンスマニュアル McAfee MySQL Audit Plugin で MySQL の監査ログを採取する