ライブからステージングまでのibdataファイルの大きなサイズの違い
AWSインスタンスで実行されているmysqlサーバーがあります。サーバーには、メインスキーマである8 GB前後のスキーマがあります。
ステージングとライブの2つの環境があります。ライブには1つのスキーマ、つまりlive_schemaしかありませんが、ステージングデータベースには、ライブのコピーであるlive_copy_03207...のような異なるタイムスタンプを持つ複数のスキーマがあります。したがって、ステージング時のデータベースの合計サイズは約50 GBです。データベースにInnoDBエンジンを使用しています。これが問題です。ライブのibdataファイルは4.2 GBですが、ステージングのibdataファイルは187 MBのみです。
ライブからステージングまでのibdataサイズのこの大きな違いの理由は何でしょうか？私はそれが拡大するだけで縮小がないことを知っています。データベースをバックアップし、すべてを削除してデータベースを復元するために必要なファイルを縮小/クリーンアップすることを知っています。
1つの可能性は、あなたが過去に持っていた、または持っていたということですinnodb_file_per_table=0、そして後の段階でそれらを別々のファイルに分割する（1 +テーブルの再構築に変更する）にもかかわらず、あなたが言ったように、スペースは再利用されていません。
ほとんどの場合、ibdata1が大きくなりすぎるのは、UNDO領域（5.6より前は常にibdata1ファイルの一部でした）に必要な余分な一時スペースが原因です。 。通常の問題は次のように発生します：長いトランザクションが開始されます（長時間実行されるクエリ、誤って閉じられていないトランザクションなど）-後続のすべての編集繰り返し可能な読み取りモードでは、最初の選択後のトランザクションが「スナップショットモード」になるため、古いデータをパージできません。結果として、UNDOスペースはどんどん大きくなり、クエリはどんどん遅くなり始めます。これは、書き込みアクティビティが多いが、データベースを一貫してバックアップするか、統計のようなクエリを実行する必要がある本番ホストでは非常に一般的です。
これが発生する理由は他にもありますが、長時間実行されるトランザクションが最大の原因です（以前の不適切な構成は別として）。長時間実行されているトランザクションがアクティブでなくなった場合は、ファイル内の新しいページでデータが利用可能であり、ファイルシステムに戻されないことを確認してください。したがって、再度発生しない限り、データは再び大きくなることはありません。あなたが言ったように、エクスポートとインポートのどちらかがMySQL5.6より前にそれを縮小する唯一の方法です。
Ibdata1の使用方法と使用目的について詳しくは、次のURLをご覧ください。 https://www.percona.com/blog/2013/08/20/why-is-the-ibdata1-file-continuously-growing- in-mysql / テーブルスペース処理の問題の多くは5.6で修正されました（外部ファイルでのUNDO、.ibdsのインポート/エクスポート、ibdata構造の内容のクエリなど）。 、あなたの場合は価値があるかもしれません。