トラフィックの多いデータベースサーバーに非常にフルのハードドライブを搭載するのは悪いことですか？

トラフィックの多い実稼働データベースサーバー用にMySQLを使用してUbuntuサーバーを実行する。MySQLインスタンス以外のマシンでは、他に何も実行されていません。

毎日のデータベースバックアップをDBサーバーに保存しますが、パフォーマンスを低下させたり、ハードディスクを比較的空にしておく理由がありますか？ディスクがデータベースとすべてのバックアップで最大86％以上満たされている場合、パフォーマンスが低下しますか？

86-90％+のフルキャパシティで実行されているDBサーバーは、10％のフルディスクのみで実行されているサーバーよりもパフォーマンスが低下しますか？

サーバーの合計ディスクサイズは1 TBを超えているため、ディスクの10％でも基本的なO / Sスワッピングなどに十分です。

まず、データベースと同じ物理ドライブまたはRAIDグループにデータベースのバックアップを保持したくない。これは、ディスク障害（RAID保護なしで実行している場合）または致命的なRAID障害（RAID-1またはRAID-5を使用している場合）により、データベースとデータベースバックアップが失われるためです。

ディスクのパフォーマンスに関する質問は、ディスク上のデータがどのようにアクセスされるかに応じて、ディスクドライブの空き容量がどのようになるかということです。回転ディスクの場合、I / Oパフォーマンスに影響する2つの物理的要因があります。彼らです：

• シーク時間-ディスクドライブが現在のトラック位置から要求されたデータを含むトラックにディスクヘッドを移動するのにかかる時間

• 回転レイテンシ-ドライブのスピン時に目的のデータが読み取りヘッドに到達するのにかかる平均時間-15K RPMドライブの場合、これは2ミリ秒（ミリ秒）

ドライブの空き容量は、サーバーのI / Oで発生する平均シーク時間に影響する可能性があります。たとえば、ドライブがいっぱいで、ディスクのプラッタの両端のドライブに物理的に配置されたデータベーステーブルがある場合、I / Oを実行すると、これらの各テーブルのデータにアクセスしてI / Oが発生しますドライブの最大シーク時間。

ただし、ドライブがいっぱいで、アプリケーションがドライブに保存されているデータのごく一部にしかアクセスせず、このデータがすべてドライブに連続して配置されている場合、これらのI / Oはシーク時間による影響を最小限に抑えられます。

残念ながら、この質問に対する答えは「マイレージは異なります」ということです。つまり、アプリケーションがデータにアクセスする方法とそのデータの場所によって、I / Oパフォーマンスが決まります。

また、@ gravyfaceで述べたように、データベースからオペレーティングシステムのストレージ要件を分離することは「ベストプラクティス」です。繰り返しになりますが、これは、同じドライブに両方があると、オペレーティングシステムとデータベースソフトウェアの両方がI / O要求を行うため、ドライブのオペレーティングシステムとデータベース領域間で絶えずシークが発生する可能性があるため、ディスク表面のヘッドの動きを最小限に抑えるのに役立ちます。

ここで考慮すべき2つの角度があります。パフォーマンスと堅牢性です。

パフォーマンスに関しては、一般的に、次の目的で個別のディスクスピンドル（またはRAIDグループ/ドライブセット）を使用することをお勧めします。

1. OSのもの（バイナリ、ログ、ホームディレクトリなど）
2. スワップスペース（スワップを使用しない場合は、（1）と組み合わせることができます）
3. 本番データベース
4. 本番DBのトランザクションログ（使用されている場合）
5. データベースダンプ/バックアップ

この背後にある理由は非常に簡単です：ディスクを要求する「他のもの」によってDBのパフォーマンスが影響を受けないようにします（たとえば、マシンが頻繁にスワップを開始し、スワップパーティションがDBデータからディスクの反対側にある場合）長いディスクシークに対処する必要があります）。

堅牢性の観点から、同じ種類の内訳が必要ですが、別の理由があります：他の人が指摘したように、障害のあるディスクにDBとそのバックアップの両方を持ち出してほしくありません（ただし、実際にはバックアップをコピーする必要があります）とにかく壊滅的な障害が発生した場合のサーバー）。

また、/すべてを含むモノリシックパーティションを使用した構成を回避する必要があります。これは、他のUnixライクシステムでは共有されない、Linuxの世界で行われる不幸で悲劇的で驚くほどよくある間違いです。
Gravyfaceが彼のコメントで言及したように、どうにかし/てシステムを使い果たした場合、ほぼ確実にクラッシュします。また、システム/にマウントポイントの適切に構造化された階層ではなく単一のパーティションがある場合、クリーンアップ/回復は時間がかかり、コストがかかる可能性があります。

データベースと一時（下記参照）バックアップをルート（/）とは異なるパーティションに移動することをお勧めします。

また、（想定される）圧縮されたデータベースダンプバックアップ用の賢明なローテーション/保持スキームを考え出します。（通常）バックアップのコピーをローカルディスクに保持する理由はありません。災害復旧には何もしません。オフサイトに移動した場合は、ディスクから削除する必要があります。

それはほとんど標準的な操作手順です。

これは、ほぼ満杯のファイルシステムのパフォーマンスが大幅に（半分に）低下したNetAppのバグを思い出しました。（確かにそれは数年前でした）。

誰もが言った答えはそれによって異なりますが、考え抜く価値があります。

完全なファイルシステムの主な欠点は、空きiノードのリストが断片化され、至る所に存在する可能性があることです。

データベースのハードディスクに保存されるデータには3つのタイプがあります。

1. 実際のデータベースファイル。これは、事前に割り当てられた大きなファイルであり、通常は大きなチャンク（たとえば10％）で成長します。
2. ログ、継続的に書き込み、削除、書き込みなどが行われているトランザクションログ
3. メモリで実行できない大規模なクエリの一時ファイル。

（1）ファイルセット用により多くのスペースを割り当てる場合にのみ空きスペースが必要です。データベースが成長していない場合は、ディスク容量の少ないファイルシステムの影響を受けません。ただし、割り当てている場合は、データベースをすぐに断片化している空きリストに収まらない非常に大きなチャンクを要求し、メモリにデータを準備する必要があるときにシークを引き起こす可能性があります。

（2）OSを使用してスペースの割り当てと削除を管理するログの単純な機能不全。データベースが読み取り専用ではない場合、ログの一定のストリームがあり、頻繁に断片化されますが、それらは低いハードディスク領域に断片化されます。最終的に、これは書き込みパフォーマンスを低下させます。

（3）tempDB、見苦しい記述されたクエリのためにDBが必要な場合、または十分なRAMがない場合、読み取りパフォーマンスでさえディスクバウンドになる可能性があるため、ディスク領域が少ないよりも大きな問題が発生してパフォーマンスの問題が発生します。また、MySQLがtempDBにディスク領域を割り当てる必要があり、ハードディスクが不足した場合も、停止のリスクがあります。

バックアップについて...

1. 私が働いたすべての企業は、同じマシンにバックアップを保持しています。復元に関しては（バックアップを気にする人は、復元が重要です）。同じディスク上にあるdbファイルの速度に勝るものはありません。
2. うまくいけば、バックアップがローカルだけではないことを確認してください。

要するに、DBの書き込みが重くならない限り、生き残ることができると思います。そうである場合、ディスク容量の不足が問題です。しかし、もし私があなただったら、私は次のことに取り組むのではなく、より早く。

1. 十分なRAMがあることを確認する
2. DBからのログとすべての一時データの分離。
3. OSを分離し、MySqlを残りからインストールします。

可能な場合は、個別のスピンドルとコントローラーを使用します1。

別々のスピンドルが続きます

貧乏人の別のパーティションが続きます。

最近、レプリケーションサーバーの1つですべてのディスク領域を使い果たしたときに、同様の問題が発生しました。即時の影響はレプリケーションがクラッシュし、mysqld.sockファイルを開けなかったためにMySQLにログインできなかったことです。