web-dev-qa-db-ja.com

Ibdataの使用法と推奨事項？

本番サーバーがあります

2011年11月5日のibdataのサイズは100Gでした。約3か月で200Gに増加します。サイズが2倍になっただけなので、巨大なデータです。現在、lvmは251Gです。

Innodbでほぼすべてのテーブルがあります。テーブルごとにinnodbを使用していません。私はlvmにidbataを持っています。今後の使用のためにどれだけ増やす必要がありますか？

または、シナリオを処理するための他の最良の方法。

mysqlinnodbibdata
5
Abdul Manaf

InnoDB（ innodb_file_per_table off）とLVMスナップショットの使用をできるだけ早く停止する必要があります。理由は次のとおりです。

データベースとしてMySQLを使用する監視システムがあります。 innodb_file_per_tableもオフになっています。 6か月の間に、1.3 TBに増加しました。

私の雇用主の会社では、この監視システムのダウンタイムは許されません。

このモンスターデータベースのスレーブを作成しようとしました。/var/lib/mysqlのrsyncをスレーブサーバーに対して実行しました。最初のパスには42時間かかりました（これはタイプミスではなく、1日18時間です）。 2番目のパスは84時間（3日12時間）かかり、15％しか完了しませんでした（220GBコピー）。ご覧のとおり、2番目のrsyncを放棄しました。

この問題は、ibdata1が1.3TBであることから生じました。

Innodb_file_per_tableがOFFの場合、ibdata1の内部は何ですか？

  • テーブルデータページ
  • テーブルインデックスページ
  • テーブルメタデータ（テーブルスペースID管理）
  • MVCCデータ（トランザクション分離、ACIDコンプライアンス用）

書き込みが多い環境では、これら4つのタイプのすべてのレコードが読み取りまたは書き込みされます。 rsyncは、ibdata1を結合してスレーブサーバーに変更を書き込むのに十分な悪夢を経験しました。私の上級Linuxエンジニアの対応者によると、LVMスナップショットはこれ以上うまくいきません。

唯一の手段は、innodb_file_per_tableの使用を開始することです。

この必要性をさらに確認するには、このクエリを実行してください（5〜10分かかります）

SELECT IFNULL(B.engine,'Total') "Storage Engine",
CONCAT(LPAD(REPLACE(FORMAT(B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size", CONCAT(LPAD(REPLACE(
FORMAT(B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size", CONCAT(LPAD(REPLACE(
FORMAT(B.TSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Table Size" FROM
(SELECT engine,SUM(data_length) DSize,SUM(index_length) ISize,
SUM(data_length+index_length) TSize FROM
information_schema.tables WHERE table_schema NOT IN
('mysql','information_schema','performance_schema') AND
engine IS NOT NULL GROUP BY engine WITH ROLLUP) B,
(SELECT 3 pw) A ORDER BY TSize;

InnoDBの合計を使用して、それをibdata1のサイズと比較します。 30GB未満の違いがある場合があります。私の監視システムではibdata1に対してクエリを実行しましたが、テーブルメタデータと新しいMVCC情報用に27GBしかありませんでした。このファイルでは常に安定した成長が見られます。

これができることです：すべてのInnoDBを変換してinnodb_file_per_tableを使用します。 その方法についてStackOverflowに投稿しました 。 easchテーブルを別のファイルに存在させることができるだけでなく、ibdata1の成長率を最小限に抑えることができます。

UPDATE 2012-02-22 13:00 EST

InnoDBのCleanUpを実行するときは、複数のibdataファイルの作成を排除してください。あなたの設定はデフォルトでなければなりません：

[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
6
RolandoMySQLDBA

Rolandoの発言に加えて、ファイルごとの設定に切り替えると、定期的なメンテナンスによってディスク領域を回復できる場合があります。

最適化テーブルは、単一のibdataファイル内のすべてを使用して多くのことを行うわけではありません。ただし、ファイルごとの設定では、これを行うことにより、ディスク領域のスペースを取り戻すことができます。テーブルを最適化すると、テーブル全体が効率的に再構築され、削除中の断片化によって残った未使用のスペースがなくなります。

Show table statusを実行すると、どのテーブルがこれから利益を得るかを確認できます。あるいは実行

select table_name, data_length, data_free from information_schema.tables
where engine='innodb' order by 3

Data_freeが最も多いテーブルを最適化すると、ディスク領域を最大限に節約できます。

ただし、いくつかの注意事項があります。

  • 各テーブルは、最適化中に完全にロックされます。個々のテーブルが数十から数百のギグである場合、これは速くありません
  • 最適化後、data_freeが完全に0になると期待すべきではありません。 innodbが16kページにスペースを割り当てる方法により、未使用のスペースがまだ残っています。
2
atxdba