ZFS上のMySQLの概要

ZFSでのMySQLの使用に関するかなり大きな記事の翻訳と、ZFSとUFSの比較テストを公開します。





おそらく最高の翻訳品質ではないことをおadvanceびします-英語を勉強したことがありません。 感謝の気持ちで、私は修正を受け入れます。

ZFSについて

Sun Microsystemsが2004年にZFSファイルシステムを立ち上げたとき、ファイルストレージの実用的な制限をすべて取り除き、ファイルストレージ管理の謎を過去のものにしました。 ZFSは128ビットのファイルシステムであり、いくつかのプロパティに名前を付けましょう-トランザクションコピーオンライトセマンティクス、高速スナップショット、オプションの圧縮。



ZFSを使用する最も重要な利点は、管理の容易さです。 ZFSでは、ディスクのフォーマットや/ etc / fstabの編集などの従来のタスクは完全に排除され、ミラーやRAIDアレイの構築は、覚えやすくインタラクティブなヘルプのある意味のあるコマンドの助けを借りて達成できます。 倉庫管理用のZFSは、MySQLがデータベースに対して行うことを行い、MySQLに加えて、オープンソースコードを備えています。 ZFSはもともとSolarisでリリースされていましたが、Linuxの移植が進行中で、AplpeがOS X 10.5にインストールし、FreeBSD 7に含まれています。詳細については、 opensolaris.orgのZFSコミュニティページを参照してください



ZFS管理は、ストレージプールを管理するためのzpoolとファイルシステム用のzfsの2つのコマンドに大きく依存しています。 ストレージプールは重要な抽象概念です。プールは複数の物理デバイスで構成でき、複数のファイルシステムをホストできます。 ストレージをプールに追加するたびに、それを必要とするすべてのファイルシステムで使用可能になります。 マウントされたドライブ全体をZFSストレージとして使用するには、次のコマンドを実行できます。



＃zpool create zp1 c2t0d0



ここで、zp1はプールの名前を表し、c2t0d0はディスクデバイスです。 Solarisスタイルのデバイスの命名になじみがない場合は、Linuxおよびその他のOSでは元の名前を使用する必要があることに注意してください。



たとえば、あるパーティションでUFSを使用してディスクがすでにフォーマットされている場合、別の空きパーティションにプールを作成できます。



＃zpool create zp1 c2t0d0s2



ファイルをリポジトリとして使用することもできます。



＃zpool create zp1〜/ storage / myzfile



すでにプールがある場合は、その上にファイルシステムを構築できます。



＃zfs create zp1 / data

＃zfs create zp1 / logs



このコマンドを実行した後、ファイルシステムの作成を待つ必要があるとは思わないでください。即座に実行されます。 将来、空き領域が不足した場合は、デバイスをプールに追加するだけで、ファイルシステムが増加します。



＃zpool add zp1 c3t0d0

ZFSとテーブルスペース

このパワーがMySQLにとって何を意味するかを評価するには、InnoDBのストレージ管理の問題を考慮してください



innodb_data_file_path = / disk1 / ibdata1：10G; / disk2 / ibdata2：10G; / disk3 / ibdata3：10G：自動拡張



この例では、InnoDBスペースが3つの物理ディスクに割り当てられています。各ディスクには10 GBしかないためか、負荷をロードしようとしている可能性があります。 3番目のディスクは自動拡張としてマークされているため、必要に応じて増やすことができます。



残念ながら、3つのディスクの負荷を分散しようとしても、実際には機能しません。 InnoDBは、次のディスクを使用する前に最初のディスクをいっぱいにし、3番目のディスクを始める前に2番目のディスクをいっぱいにする必要があります。 別の問題は、オンラインで表スペースを拡張できないことです。 ドライブ＃3のディスク容量が不足して別のドライブからファイルを追加した場合、変更を有効にするにはサーバーを再起動する必要があります。 （この例ではautoextendを使用していくつかのトリッキーなアクションを実行する必要がありますが、これらの詳細はこの説明の範囲外です）。



ストレージ管理がデータベースの影響範囲から完全に削除された場合、状況を修正できます。 これを行うには、innodb_data_file_pathでZFSを使用するだけで十分です。



innodb_data_file_path = / dbzpool / data / ibdatafile：10G：autoextend



このストレージを好きなだけデバイスに分割でき、ZFSは負荷をインテリジェントに分散します。 データベースを再起動せずに、デバイスを組み合わせてミラー化し、必要に応じてスペースを追加し、その場でバックアップディスクを追加し、破損したディスクを除外できます。 データベースをデータベースにすることができます。mysqlのユーザーにとっては、データベースをシンプルで安価で使いやすいものにすることに集中できます。



MySQL Falconエンジンでは、オンラインで表スペースを作成および削除できますが、1つのデータファイルのみを含めることができます。 将来のバージョンでは複数のデータファイルのサポートが約束されていますが、ZFSユーザーはこの機能を必要としません。

ファイルシステム、バッファリング、予測

従来、ファイルシステムレベルには、ほとんどのアプリケーションのパフォーマンスを大幅に向上させることができる小さなプロパティセットが含まれています。 1つ目はバッファリングです -物理ディスクとそれを使用するアプリケーションの間のメモリの中間領域。



以下は先読みです。アプリケーションがファイルの大きなブロックを要求する場合、アプリケーションがさらに読み続けることを期待して、ファイルシステムはさらに大きなブロックを読む必要があります。



この点で、データベースサーバーは一般的な提案ではありません。 したがって、レコードをキャッシュするためにファイルシステムバッファに依存しているデータベースMyISAMは、このセクションで説明する問題の影響を受けませんが、他の多くは独自のバッファ層を使用します。 データベースのパフォーマンスは、このキャッシュの使用効率に依存します。キャッシュミスが発生し、物理ディスクからの読み取りが発生するたびに、効率が低下します。



この問題は、データがデータベースサーバー上で2回、メモリに2回キャッシュされ、ファイルシステムで2回キャッシュされるときに発生します。 データのコピーを2つ保存すると、メモリ使用量が半分になります。 メモリがいっぱいになると、可能なデータの半分しか含まれないため、キャッシュ内のヒット数が減少し、読み取り数が増加して効率が低下します。 これをダブルバッファ問題と呼びます。



次の最適化-プレゼンテーション-も、データベースサーバーに有害な場合があります。 データベースによって行われた読み取り値は予測可能なテンプレートに適合しないため、ファイルシステムは使用されないデータを読み取ります。 Sunのエンジニア兼ブロガーであるRoch Bourbonnaisは、これを調査しました。従来のUFSファイルシステムが「2つの連続したページへのアクセスを見ると、現在は通常1MBのサイズの完全なクラスターを読み取ります」 ディスクヘッドが不要なデータの読み取りに費やす時間は、より生産的に費やす必要があります。



多くのMySQLユーザー、特にSolarisでは、これら2つの問題は単に設定を無効にすることで解決されると答えています。 バッファリングと読み取り値なしのファイルシステムへのアクセスはDirect I / Oに知られており、O_DIRECTでinnodb_flush_methodを設定することでmy.cnfで許可できます。



innodb_flush_method = O_DIRECT



MySQL 5.0.42および5.1.18のリリース前の2007年4月には、このために、Solarisのforcedirectioオプションでデータファイルを含むパーティションをマウントする必要がありました。 幸いなことに、現在はそうではありません。InnoDBは、すべてのアプリケーションにパーティション全体への直接アクセスを強制することなく、直接アクセスを使用できます。

ZFSおよびI / Oスケジューラー

InnoDBをZFSで使用すると、間違いなくダブルバッファーの問題が発生し、その効果は以下のテストで簡単に確認できます。 読み取りに関しては、ZFSの初期リリースは読み取りに悩まされていましたが、現在のリリース（OpenSolaris Nevadaビルド70以降）は免れています。 別のSUNエンジニアおよびブロガーであるNeelakanth Nadgirは、2006年にデータベースでZFSテストをいくつか行い、以前のパフォーマンスの問題は新しいビルドで修正されたと述べました。



ZFSは、I / Oスケジューラに3番目の興味深いパフォーマンスの改善をもたらします。 ZFSスケジューラは、次の計画に従って機能します。



•I / O要求がカーネルに到着すると、キューに入れられ、優先順位と期限（より高い優先順位、むしろ期限）が割り当てられます。

•読み取り要求は、書き込み要求よりも優先されます。 読み取り要求は実際には同期であるため（アプリケーションはブロックされ、応答を待機しています）。 読み取り要求はキューの先頭に落ちます。

•スケジューラーはすべての保留中の要求をスキャンし、次に実行される決定を行います。 これを行うには、最も緊急の要求を「期限グループ」にまとめ、論理ブロックアドレスの順序でディスクに配布します。



SUNの別のブロガーは、ZFS I / Oスケジューラーで少なくとも1つのテストを行います

（およそ。ここで私の脳が壊れた）

さらに別のSunブロガーを導入するために、ZFS I / Oスケジューラがパフォーマンスに大きな違いをもたらすことが示されているベンチマークが少なくとも1つあります。

ZFSにMySQLをデプロイする：詳細

ZFSとMySQLの組み合わせは有望な組み合わせのように見えますが、どのように組み合わせるのでしょうか？ 多くの場合、データベースサーバーとファイルシステムは同じ一連の問題を解決する必要があり、それぞれが解決策を提供します。 2つのソリューションは互いにうまく組み合わされるか、互いに重なり合わないことがあります。 以下は重要なポイントです。

ZFSレコードサイズをブロックサイズに設定する

ZFSは、ファイルのサイズとその使用タイプに基づいて、各ファイルのブロックサイズを発見的に決定しようとします。 小さなファイルは小さな断片で管理され、大きなファイルは大きな断片で管理されます。 ZFS開発者は、このようなスキームが一般的な場合に最適であることを知っていますが、データベースにはまったく適していない可能性があるため、ファイルシステムがデータベースで使用されるときにユーザーが固定レコードサイズを設定できるようにしました。 この記事で後述するいくつかの考慮事項は、データベースのページサイズがZFSレコードのサイズと等しい場合にのみ当てはまります。



InnoDBは、異なるページサイズで再コンパイルするまで、16KBページのデータファイルを処理します。 Falconはデフォルトで4KBページを使用しますが、my.cnfのインストールを許可します。 どちらの場合も、ZFSレコードサイズをページのサイズに設定することが重要です。 これは、セクション内のファイルが作成される前に実行する必要があります。コマンドは次のようになります。



＃zfs set recordsize = 16K zp1 /データ

InnoDBデュアル書き込みバッファーとトランザクションストレージ

一部のトランザクションシステム（InnoDBではない）は、データページ全体をトランザクションログに書き込みます。 ただし、InnoDBはページ番号と変更されたレコードのみを記録します。これはユーザーがトランザクションの完了を待機する重要な瞬間であるため、InnoDBはディスクに送信するデータが少なくなり、パフォーマンスが向上します。



それらの他のデータベースがクラッシュした場合、ログを使用して再起動して復元すると、ログからデータのページ全体を引き出してデータファイルに書き込むことができます。



InnoDBでは、リカバリはそれほど簡単ではありません。 情報のほんの一部のみがログに記録されるため、データページはディスク上で正確でなければなりません。 InnoDBは、最後に記録されたページの2番目のコピーを含む、二重書き込みバッファーと呼ばれるデータファイルの特別な領域を使用して、これを保証しようとしています。 クラッシュ後、変更データのコピーが2つあります。1つは通常のファイルに、2つ目はダブルエントリバッファにあり、これらのコピーの少なくとも1つは無傷でなければなりません。 ダブルライトバッファはZFSでは必要ありません。それを無効にすることで、効率を少し上げることができます。



部分記録中の二重書き込みバッファを主に保護するものから：データベースが16KBページをディスクに送信したが、電源が切れる前に実際に書き込まれたのは4KBまたは8KBだけだった場合。 この場合、トランザクションはデータベースからではなく、ファイルシステムからのものです。ZFSは、部分的なデータ記録が発生しないようにします。



部分的な記録の完全な画像を取得するには、別のディスクブロック、たとえばブロック82を想像してください。これは、電源が切れたときに従来のUnixファイルシステムで上書きされました。 システムがリブートすると、ブロック82の先頭には部分的に記録された新しいデータが含まれ、次のピースにはゴミが含まれ、ブロックの末尾には上書きされない古いデータが含まれます。 ブロックにInnoDBページが含まれている場合、ページの最後にチェックサムが含まれます。チェックサムは、検証中にページのコンテンツの失敗を示します。



ZFSでは、停電前にデータベースがブロック82を上書きすると、まったく異なることが起こります。 ブロック82は実際には上書きされませんが、代わりに、新しいブロック全体が別の場所に書き込まれます。 したがって、記録プロセス中に電力が失われた場合、ブロック82はそのまま残ります。 すべてがうまくいけば、データは別の場所に保存され、古いブロックではなく新しいブロックがファイルに含まれます（少なくとも現在のバージョンのファイルに含まれます）（ファイルの以前のバージョンのスナップショットが存在する場合があります。古いブロック：データベースに近い人は、マルチバージョンを使用した同時アクセスを記憶できますが、ファイルシステムレベルであり、このプロパティはFreeBSD、NetApp、Veritasファイルシステムに長年存在していました）。

MySQL ZFSとパフォーマンスの比較 Open Solaris上のUFS

SolarisでUFSとZFSを比較するために、2つの個別のテストを実施しました。 OpenSolaris Nevada build 74およびMySQL 5.0.50でのx86デスクトップ、2 GB RAMのテストに使用されるマシン。 最初のテストは、一括挿入や「ALTER TABLE」などの一般的な操作を表示するように設計されたシングルスレッドの「ユーティリティ」です。 このテストでは、2つのファイルシステム間に顕著な違いは見られませんでしたが、一部の個々の操作は、UFSよりもZFSで5％遅くなります。



次のテストはより興味深いことが判明しました。 このテストには、INSERTクエリとUPDATEクエリで区切られたSELECTクエリの85％のパターンを使用して、3.2GBデータベースにアクセスする6つのクライアントスレッドが含まれていました。 3.2 GBのデータベースは大きすぎてメモリに収まりません。 テストは入力出力の制限を示し、同じテストはほとんどの実際のアプリケーションの動作をシミュレートします。別のレコードセット（全体の約5％）が他のレコードよりもはるかに頻繁に選択されます。



このテストはキャッシュの動作に特に敏感であり、各テストにはキャッシュを満たすためのウォームアップ時間が含まれており、ウォームアップ時間が異なる場合はテストを正当に比較できません。 ウォームアップ時間をゼロにリセットするには、キャッシュバッファがフラッシュされている間にファイルシステムを再マウントする必要がある場合があります。



ZFSと 5分間のウォームアップ後のUFS。 数値が大きいほどパフォーマンスが向上します。 2 GBのRAMを備えたサーバーあたり3.2 GBのデータベース。

InnoDBバッファープールサイズ	UFSダイレクトI / O	ZFS
100 MB	36.84	96.21
250 MB	45.70	80.69
350 MB	50.68	102.75
500 MB	57.32	94.99
700 MB	61.92	85.95
1000 MB	82.41	98.35
1200 MB	95.01	88.98
1400 MB	101.32	117.83

5分間のウォームアップテストでは、バッファーサイズの増加に伴い、UFSのデータベースパフォーマンスが着実に向上していることが示されています。 ZFSでは、結果は不安定で非線形です。 ウォームアップ時間を10分に増やすと、画像がより鮮明に表示されます。



ZFSと 10分間のウォームアップ後のUFS。

InnoDBバッファープールサイズ	UFSダイレクトI / O	ZFS
100 MB	35.71	179.18
250 MB	44.25	154.26
350 MB	50.60	110.14
500 MB	57.10	93.29
700 MB	66.57	101.35
1000 MB	103.47	114.18
1200 MB	168.66	156.04
1400 MB	325.05	290.14

繰り返しになりますが、UFSのパフォーマンスは、バッファーサイズの増加とともに着実に増加しており、最後に向かって非常に大きくなっています。 1200および1400 MBの最後の2つのポイントは、マシンメモリの60および70％を意味し、これはデータの半分を格納するのに十分です。



バッファサイズが小さい場合、ZFSはUFSよりもはるかに優れています。 ZFSキャッシュは非常に効率的です。 100MBバッファーでのZFSは、1200MBでもUFSよりも効率的です。 ただし、プールサイズが増加すると、ZFSのパフォーマンスは低下します



この動作は、ダブルバッファリングが原因です。 一部のデータは両方のキャッシュに存在するため、メモリに保存されるデータは少なくなり、物理ディスクへのアクセスがより頻繁に必要になります。 この効果は、バッファサイズが500 MBに設定されている場合、最悪の効果があります。



500MBを超えると、2つのファイルシステムはより類似した方法で動作し始めます。 データベースサーバーはほとんどの物理メモリを必要とし、ZFSにほとんど残らないため、パフォーマンスへのZFSの寄与を最小限に抑え、ダブルバッファリングの問題を軽減します。

おわりに

ZFSを使用すると、実際のパフォーマンスを損なうことなく、非常にシンプルで柔軟な管理が可能になります。 最悪の場合のシナリオでは、これらのテストでは、ZFSはDirect I / Oを使用したUFSとほぼ同じように動作します。 InnoDBの場合、パフォーマンスグラフは、「inndbバッファーを少なく設定し、ZFSにバッファリングを管理させる」という新しい戦略を使用するよう指示します。テストを実行したとき、まだFFSをテストしていません。行および減少するページキャッシュ。 ダブルバッファリングの問題はZFSのパフォーマンスグラフにはっきりと表れていますが、最悪の場合、ZFSはUFSよりも生産的です。



（約。最後の段落で、私は脳を壊した）



このベンチマークで優れたパフォーマンスが得られる本当の理由は明確ではありません-実際、すべてのワークロードは異なります-しかし、ZFS I / Oスケジューラ、データベースパフォーマンスに注意を払っているSunのエンジニア、および最近（2007年後半に貢献したZFSバグ修正）Open Solarisのリリースは、何か良いものを追加しているようです。



ps：繰り返しますが、品質に謝罪します。テキストはボリュームがあり、なめる方法がありません。それなしでは、これに許容できない時間を既に費やしています。 翻訳は、出版のためではなく、トピックに対するより完全な洞察のために行われました。 私自身もインスピレーションを受けているように見えましたが、他の誰かに役立つことを願っています。 近い将来、テストを実施する予定です。コミュニティが興味を持っている場合は、それらを公開します。