サーバーメーカーとクラウドプロバイダーは、データベースのニーズに対応するためにさまざまな種類のストレージソリューションを提供しています。新しいサーバーを購入したり、データベースを実行するクラウドインスタンスを選択したりするとき、私たちはよく自問します-どのくらいのディスクスペースを割り当てる必要がありますか？後でわかるように、考慮すべき側面がいくつかあるため、答えは簡単ではありません。ディスク領域の縮小と拡張は、ディスクベースのデータベースにとって危険な操作になる可能性があるため、ディスク領域は事前に検討する必要があります。
このブログ投稿では、最初にストレージスペースのサイズを決定し、次にMySQLまたはMariaDBデータベースの拡張をサポートする容量を計画する方法を検討します。
MySQLがディスクスペースを利用する方法
MySQLは、システム変数「datadir」を持つ特定のディレクトリの下のハードディスク上のファイルにデータを保存します。 datadirの内容 MySQLサーバーのバージョン、およびロードされた構成パラメーターとサーバー変数（general_log、slow_query_log、binary logなど）によって異なります。
実際のストレージおよび取得情報は、ストレージエンジンによって異なります。 MyISAMエンジンの場合、テーブルのインデックスは、テーブルの.MYDファイルおよび.frmファイルとともに、データディレクトリの.MYIファイルに保存されます。 InnoDBエンジンの場合、インデックスはテーブルとともにテーブルスペースに格納されます。 innodb_file_per_tableの場合 オプションが設定されている場合、インデックスは.frmファイルとともにテーブルの.ibdファイルに含まれます。メモリエンジンの場合、データはメモリ（ヒープ）に保存され、構造はディスク上の.frmファイルに保存されます。今後のMySQL8.0では、新しいデータディクショナリスキーマの導入により、メタデータファイル（.frm、.par、dp.opt）が削除されます。
テーブルデータの保存にInnoDB共有テーブルスペースを使用している場合（ innodb_file_per_table =OFF ）、MySQLの物理データサイズは、大量のデータ行を切り捨てたり削除したりした後でも、継続的に増加すると予想されます。この構成で空き領域を再利用する唯一の方法は、現在のデータベースをエクスポートして削除し、mysqldumpを介してそれらを再インポートすることです。したがって、 innodb_file_per_table =ONを設定することが重要です。 ディスクスペースが気になる場合は、テーブルを切り捨てるときに、スペースを再利用できます。また、この構成では、後でOPTIMIZE TABLEを実行しない限り、巨大なDELETE操作でディスク領域が解放されることはありません。
MySQLは、各データベースを「datadir」パスの下の独自のディレクトリに保存します。さらに、ログファイルおよびソケットやPIDファイルなどの他の関連するMySQLファイルも、デフォルトでdatadirの下に作成されます。パフォーマンスと信頼性の理由から、MySQLログファイルを別のディスクまたはパーティション（特にMySQLエラーログとバイナリログ）に保存することをお勧めします。
データベースサイズの見積もり
サイズを見積もる基本的な方法は、2つの異なる時点間の成長率を見つけ、それを現在のデータベースサイズで乗算することです。この目的でピーク時のデータベーストラフィックを測定することはベストプラクティスではなく、データベースの使用状況全体を表すものでもありません。深夜、または週に1回実行されるバッチ操作またはストアドプロシージャについて考えてみてください。データベースは、深夜のハウスキーピング操作によって縮小される前に、午前中に大幅に増大する可能性があります。
考えられる1つの方法は、この測定の基本要素としてバックアップを使用することです。 Percona Xtrabackup、MariaDB Backup、ファイルシステムスナップショットなどの物理バックアップには、データベースとインデックスのバイナリコピーが含まれているため、論理バックアップと比較して、データベースサイズをより正確に表すことができます。 mysqldumpのような論理バックアップは、元のデータベースオブジェクト定義とテーブルデータを再現するために実行できるSQLステートメントのみを格納します。それでも、mysqldumpバックアップを比較することで、良好な成長率を得ることができます。
次の式を使用して、データベースのサイズを見積もることができます。
どこで、
- B -今週のフルバックアップサイズ
- B -先週の完全バックアップサイズ
- Dbデータ -データベースの合計データサイズ
- Dbインデックス -データベースインデックスの合計サイズ
- 52 -1年の週数
- Y -年。
MB単位のデータベースの合計サイズ（データとインデックス）は、次のステートメントを使用して計算できます。
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+代わりに月次バックアップを使用する場合は、上記の式を変更できます。 52から12（1年で12か月）の定数値を変更すると、準備が整います。
また、 innodb_log_file_sizeを考慮することを忘れないでください x 2、 innodb_data_file_path Galera Clusterの場合は、 gcache.sizeを追加します 値。
バイナリログサイズの見積もり
バイナリログは、レプリケーションとポイントインタイムリカバリの目的でMySQLマスターによって生成されます。これは、MySQLサーバーで行われたデータ変更に関する情報を含むログファイルのセットです。バイナリログのサイズは、書き込み操作の数とバイナリログ形式（STATEMENT、ROW、またはMIXED）によって異なります。ステートメントベースのバイナリログは、通常、行ベースのバイナリログと比較してはるかに小さくなります。これは、行ベースが変更された行情報で構成されているのに対し、書き込みステートメントのみで構成されているためです。
バイナリログの最大ディスク使用量を見積もる最良の方法は、1日のバイナリログサイズを測定し、それを expire_logs_daysで乗算することです。 値（デフォルトは0-自動削除なし）。 expire_logs_daysを設定することが重要です サイズを正しく見積もることができます。デフォルトでは、MySQLがバイナリログファイルをローテーションする前に、各バイナリログの上限は約1GBです。 MySQLイベントを使用して、この見積もりの目的でバイナリログを単純にフラッシュできます。
まず、event_scheduler変数が有効になっていることを確認します：
mysql> SET GLOBAL event_scheduler = ON;次に、特権ユーザー（EVENTおよびRELOAD特権を持つ）として、次のイベントを作成します。
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;書き込みが集中するワークロードの場合、バイナリログが最大サイズの1GBに達する前に、間隔を30分または10分に短縮してから、出力を1時間に切り上げる必要があります。次に、次のステートメントを使用してイベントのステータスを確認し、LAST_EXECUTED列を確認します。
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...次に、現在のバイナリログを見てください：
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+次に、バイナリログの増加の平均を計算できます。これは約〜562MB/時間です。 ピーク時。この値に24時間とexpire_logs_daysを掛けます 値：
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+約〜95 GBの94416MBを取得します バイナリログ用のディスク容量。スレーブのリレーログは、スレーブ側に保存されることを除いて、基本的にマスターのバイナリログと同じです。したがって、この計算はスレーブリレーログにも適用されます。
スピンドルディスクまたはソリッドステート？
MySQLファイルに対するI/O操作には2つのタイプがあります。
- シーケンシャルI/O指向ファイル：
- InnoDBシステムテーブルスペース（ibdata）
- MySQLログファイル：
- バイナリログ（binlog.xxxx）
- REDOログ（ib_logfile *）
- 一般的なログ
- クエリログが遅い
- エラーログ
- ランダムI/O指向ファイル：
- InnoDB file-per-tableデータファイル（* .ibd）、 innodb_file_per_table =ON （デフォルト）。
最高のパフォーマンスを得るには、ランダムなI/O指向のファイルを高スループットのディスクサブシステムに配置することを検討してください。これは、フラッシュドライブ（SSDまたはNVRAMカード）、またはハードウェアRAIDコントローラーとバッテリーバックアップユニットを備えたSAS15Kまたは10Kなどの高RPMスピンドルディスクである可能性があります。シーケンシャルI/O指向のファイルの場合、MySQLには、バッテリーでバックアップされた書き込みキャッシュを使用してHDDに保存するだけで十分です。バッテリーが切れていると、パフォーマンスが低下する可能性があることに注意してください。
この領域（ディスクスループットとファイル割り当ての見積もり）については、別の投稿で説明します。
キャパシティプランニングとディメンション化
キャパシティプランニングは、日常業務に耐えるのに十分なリソースを備えた本番データベースサーバーを構築するのに役立ちます。また、予期しないニーズに備え、将来のストレージとディスクスループットのニーズを考慮する必要があります。したがって、容量計画は、データベースに次のハードウェア更新サイクルまで十分な余裕があることを確認するために重要です。
これを例で説明するのが最善です。次のシナリオを検討します。
- 次のハードウェアサイクル：3年
- 現在のデータベースサイズ：2013 MB
- 現在の完全バックアップサイズ（N週目）：1177 MB
- 以前の完全バックアップサイズ（N-1週目）：936 MB
- デルタサイズ：1週間あたり241MB
- デルタ比率：1週間あたり25.7％の増分
- 3年間の合計週数：156週
- データベースの合計サイズの見積もり：（（1177-936）x 2013 x 156）/ 936 = 80856 MB〜3年後の81 GB
バイナリログを使用している場合は、前のセクションで取得した値から合計します。
- 81 +95=データベースおよびバイナリログ用の176GBのストレージ。
運用および保守タスク（ローカルバックアップ、データステージング、エラーログ、オペレーティングシステムファイルなど）のために、少なくとも100％多くのスペースを追加します。
- 176 + 176 =352GBの合計ディスク容量。
この見積もりに基づいて、データベースに3年間で少なくとも352GBのディスク容量が必要であると結論付けることができます。この値を使用して、新しいハードウェアの購入を正当化できます。たとえば、新しい専用サーバーを購入する場合は、バッテリーでバックアップされたRAIDコントローラーを備えた6 x 128 SSD RAID 10を選択できます。これにより、合計ディスク容量が約384GBになります。または、クラウドをご希望の場合は、81GBのデータベース使用にプロビジョニングされたIOPSを備えた100GBのブロックストレージを取得し、95GBのバイナリログやその他の運用上の使用に標準の永続ブロックストレージを使用できます。
ハッピーディメンション！