Auditのログローテーションについての追加の手法。合わせて、NFS上に監査ログを設定していて、万が一NFSが一時的に切れてしまった場合の挙動の確認。mysqlutilitiesを利用したローテーションmysqlauditadmin.exe上記は、前回のブログ記事で紹介。Logのローテーション今回は、CRON等で定期的に実行して、自分のカスタマイズしたいようにログをシェルでローテーションする方法です。概要はこちらのマニュアルページで紹介しています。実際に、以下の様にSHELLを作成してログのローテーション確認してみました。audit.logがリネームされて、新しいaudit.logファイルが再作成されています。user_tablespace02_8k.ibd簡易版なので、適宜用途によって加工して利用して下さい。NFS上にaudit.logを配置して、運用中にNFSが切れてしまった場合の挙動の確認。ログのローテションを確認する為に、一時的にaudit_log_rotate_on_sizeに最小限のサイズを設定しています。ログをリネームして一時的にMySQLからファイルを見えなくしています。この間にAudit対象のQueryを実行して、ローテーションサイズを超えてもadit.logが無いので監査ログは書き込まれません。user_tablespace02_8k.ibdNFSの接続が戻ったと仮定して、ログを元の名前に戻す。21:56の段階でaudit.logが無かった時のデータがaudit.log.14745489750144595.xmlに書き込まれている。ログローテーションのサイズ(4096)をオーバーしているがデータがロストしていない事が確認出来る。新規でaudit.logが作成されている。ローテーションも設定サイズできちんと行われている。audit.logに書き込めない間は、audit_log_bufferに蓄積されているようです。補足:ログに書けない間も、MySQLのステータス変数はカウントアップされている事がaudit_log_current_sizeから確認する事が出来ます。ファイルを戻したタイミングで、ログがファイルに書き込まれ、audit_log_current_sizeは値が小さくなっている事が確認出来ます。定期的にローテーション出来るかどうか確認してみました。Logのローテーションとしては、以下の2パターンがあります。古いファイルがaudit.log.xxxxx.xmlというファイル名になっています。data]#追加で、負荷をかけた状態でローテーションしてみました。こちらがWorkbenchで確認したログです。Workbenchでログも確認してみました。mysqlslapからアクセスがある事が確認出来ます。mysqlauditadminについては此方を参照下さいhttp://dev.mysql.com/doc/mysql-utilities/1.3/en/mysqlauditadmin.htmlhttps://docs.oracle.com/cd/E17952_01/mysql-utilities-1.3-en/mysqlauditadmin.html補足;此方は、コマンドでログの中身をフィルターするUTILITYになります。Auditはこちらから30日間トライアルがダウンロード可能です。rdbmsTweetexpire_logs_dayによるログの自動削除MYSQLのバイナリーログファイルがディスク容量を圧縮してきているので、バックアップのタイミングと調整してログの定期削除を実施する設定を投入。設定投入後my.cnfに設定を入れて再起動すると既に設定が反映されている。sec)mysql>その他、SQLコマンドでマニュアル削除する方法。バックアップ対象データが取られていれば、古いバイナリーログは不要。指定したバイナリーログ以前のファイルが削除されている事を確認。rdbmsTweetMYSQLは他のDBと同じようにI/O分散する事でパフォーマンスを大きく向上させることが出来ます。基本的には、物理的に別のディスク(ディスクヘッドが別)を準備する事でI/O待ちを減らすことが可能です。ファイルをそれぞれの場所に分割する事で、I/O分散だけではなくオリジナルディスク領域のディスク容量を空ける事も可能です。サーバーをSTARTさせる。サーバーをSTARTさせる。rdbmsTweetINNODBのログファイルを大きくするとパフォーマンスが向上する場合がある、ためしにサイズを変更してみました。