web-dev-qa-db-ja.com

ibdataファイルのすでに削除されたレコードにある機密データの削除/上書き

私の知る限り、innodb_file_per_table = offでInnoDBテーブルを使用しても、削除されたデータがibdata1ファイルに表示されるのを防ぐことはできません。

これは設計によるものであり、innodb_file_per_table = onを使用するようにシステム設定を切り替えることができます。これにより、システムは機密情報を含むibdata*ファイルを細断処理できますが、「サーバーのダウンタイムはありません。許可されました」

ibdata1ファイル内の機密情報をなんらかの方法で上書きして、後で誤ったthis is sensitiveがthis is xxxxxxxxxを読み取るようにできますか。

私はDBAではなく、これがまったくうまくいくのか、チェックサムを破壊したり、サーバーをクラッシュさせたりするのかどうかもわかりません。

だから私の質問は、実行中のサーバーの安定性に影響を与えることなく、その間にリークを防ぐために何ができるかということです。

mysqlinnodbibdata
1
Jürgen Thelen

innodb_file_per_table に切り替えるだけでは、ibdata1のサイズは同じであるため十分ではありません。

Ibdatat1内にあり、OPTIMIZE TABLEを実行したテーブルは、テーブルとそのインデックスを.ibdファイルに明示するだけです。 ibdata1内のテーブルのフットプリントは引き続き存在します。 ibdata1にデータとインデックスページが存在しないようにInnoDBを再構築する方がはるかに優れています

考えてみてください。innodb_file_per_tableをオフにすると、データとインデックス以外にibdata1の内部に何が入りますか？

  • データディクショナリ
  • ダブルライトバッファ（OSキャッシュへの依存を防ぐためのバックグラウンド書き込み）
  • バッファの挿入（一意でないセカンダリインデックスへの変更の管理）
  • ロールバックセグメント
  • スペースを元に戻す
  • 絵画的表現

これらのいくつかは最終的に古いデータとインデックスページを上書きする可能性がありますが、最終的にどのくらいの時間がかかりますか？ ibdata1を完全に圧縮する方が良いのではないでしょうか。基本的に、それは以下を伴います：

  • すべてのデータベースのmysqldumpを実行する
  • ibdata1の削除
  • /etc/my.cnfでinnodb_data_file_pathがデフォルト（ibdata1：10M：autoextend）であることを確認します
  • mysqldを起動してibdata1を再作成できるようにする
  • mysqldumpをリロードします。

その方法については、過去のリンクをご覧ください...

2
RolandoMySQLDBA