免責事項
この記事はMySQL Server Blogの投稿 Plan to improve the out of the Box Experience in MySQL 8.0 をユーザが翻訳したものであり、Oracle公式の文書ではありません。
MySQL 8.0において我々は innodb_dedicated_server=bool と呼ばれる新しいパラメーターを導入するつもりです。
これがONに設定されている時、このオプションはシステムメモリーの量を確認し、以下のルールに従って自動的にパラメーターを決定します。
innodb_buffer_pool_size
server_memory < 1G ? 128M (現在のデフォルトと同じ)
server_memory <= 4G ? server_memory * 0.5
server_memory > 4G ? server_memory * 0.75
innodb_log_file_size
server_memory < 1G ? 48M (現在のデフォルトと同じ)
server_memory <= 4G ? 128M
server_memory <= 8G ? 512M
server_memory <= 16G ? 1024M
server_memory > 16G ? 2048M
innodb_flush_method = O_DIRECT_NO_FSYNC
innodb_dedicated_server がOFFの時、設定は現在の通りとなります。これ(訳注: OFFの時のデフォルト)は最小の構成に合わせたものではありませんし、大きなメモリーに最適化したものでもありません。
背景
innodb dedicated serverのゴールはユーザーがコンフィグに何の変更も加えることなくすぐに使える状態で提供することです。私たちのドキュメント には現在の振る舞いとして以下のように記載されています。
デフォルトの設定はおよそ512MBのメモリーの仮想マシンでMySQLサーバーを起動することができるようにデザインされています
512Mのメモリーとはエントリーレベルのクラウドインスタンスで採用されているサイズで、そのようなインスタンスは数年後には見ることがありません。
たとえばもし、ユーザーが64GBのメモリーを持ったインスタンスでMySQLを起動すれば、同じく小さいフットプリントを使用します。InnoDBバッファプールサイズはシステムメモリーの50%から75%を推奨していますが、この結果(訳注: デフォルトが512MBの仮想マシンを想定している結果、大きなメモリーを搭載したサーバーでもデフォルトでは) 128MBという非常に小さいInnoDBバッファプールサイズとなります。
これは私たちに疑問を呈しました。リソースの消費量をホストにマッチさせられないかどうかという問題です。
問題1: いつ自動調整が必要かの判断
最初の問題は、リソースの消費量をホストにマッチさせることは常に望まれているわけではないということです。MySQLをあなたのデスクトップで起動している時、またはウェブサーバーとともに起動している時など、ユースケースを判断する必要があります。
これらの状況では、システムメモリーの50%から75%のバッファプールは安全な設定ではありません。
問題2: どのように自動調整するかの判断
このシステムメモリーの50%から75%の割り当てが安全でないケースの場合、あなたはMySQLは何%のメモリーを安全に使うことができるかをセットすることができます。
私たちはこのことについて考え、2つの問題に当たりました。
- もしあなたが「MySQLは60%使うことができる」と指定した場合、バッファプールのサイズを決めるためにいくつかの計算をしなければなりません。たとえば、
16GB RAMのマシン
100%をMySQLに使える場合、バッファプールは 16GB * 0.75 = 12GB
60%に補正した場合 = 7.2GB
私たちの懸念は、「75%の60%」というのが混乱のもとになることです(KISSの原則)
- あなたがユーザーに1%から100%の値を問い合わせる場合、あなたは既にコンフィグについてもユーザーに問い合わせているでしょう。ユーザーがコンフィグに何も指定しない場合にどのような値を設定するのが良いかを判断するのがこの機能の目的ですから、これではその目的を果たせていません。
そのため、最も重要な判断はMySQLサーバーがマシンを占有している場合のみとしました。それ以外のケースでは、それぞれのユーザーがそれぞれの環境に合わせてコンフィグを調整してくれることを期待することが合理的です。
問題3: インストーラーの質問
よって、私たちはこのオプションをboolean（占有または占有でない）にするところまできました。ですが私たちはこの質問に適切に答えることができませんでした。Mac OS XやWindowsでは、インストーラーによってMySQLサーバーがマシンを占有するか尋ねることができます。
MySQLにこのマシンの全ての利用可能なメモリーを割り当てますか？ [ はい / いいえ]
"はい" を選択した場合MySQLの全体的なパフォーマンスは向上するでしょう。あなたはこの選択をいつでもコンフィグファイルの innodb_dedicated_server オプションで変更することができます。
問題はLinuxシステムです。私たちはRPMやDEBパッケージがこれを質問できることを 保証できません 。これが次の問題点を運んできます。
問題4: デフォルトの選択
ユーザーへの質問を確実にできないことで、私たちはユーザーが何も選択しなかった時に利用されるデフォルト(訳注: innodb-dedicated-server がデフォルトでONになるかまたはOFFになるか) を必要とします。このデフォルトはユーザーが何もコンフィグを指定しなかった時に利用されるもので、「卵が先か、にわとりが先か」のようになってしまいます。
すなわち、サーバーが占有されているのであればユーザーは設定を変更しなければいけませんし、この時点ではバッファプール、ログファイル、フラッシュメソッドを自動で設定することはできません。
つまり、この新機能が真価を発揮するにはデフォルトでONであることが必要です。OFFである場合、それは質問にたどり着くのを少し簡単にするだけであって、すぐに使えるパッケージと呼ぶことはできません。
注 : 別の方法として、OSごとに違うデフォルトを用意する、または 'mysql-production' (innodb-dedicated-server=ON) と 'mysql-development' (innodb-dedicated-server=OFF) の2つのパッケージを用意することがあります。この方法はこのブログに書かれているよりも長い、新しい問題を引き起こします。短い答えとしては、私たちはこの方法を採用するつもりはありません。
MySQL 8.0.3の状況
今まで説明してきた innodb-dedicated-server の機能がMySQL 8.0.3からリリースされますが、今のところデフォルトはOFFになります。これはとても大きな変更で、いくつか私たちが解決を模索しなくてはならないコーナーケースがあります。たとえば、
インストーラー（ユーザーに対する問い合わせのできないもの）がインストール後にMySQLを自動起動した場合、OOMの状況がMySQLの起動を妨げる可能性があります。私たちはユーザーにMySQLを簡単に使ってもらいたいと考えており、ユーザーが自分たちでログファイルをtailしたり、この問題をユーザー自身で解決したりしてほしくはありません。
innodb-log-file-sizeのデフォルトを2048MBにすることは、MySQL 5.7と比べて20倍以上のサイズアップになります。私たちは確実にクロスプラットフォーム間でのパーティションの空き容量を保証することも、それを計算式に盛り込むこともできないと思っています。占有サーバーにおける
innodb-log-file-sizeは少し恣意的です。これはシステムのメモリー量やバッファプールのサイズに関係しません。例えば、同じページをアップデートし続けるワークロードは、大きなバッファプールよりも大きなREDOログを必要とします。私たちはこの最大値を512MBにすることによって容量不足になるリスクを軽減できるでしょう。innodb-buffer-pool-sizeについても同じことが言えます。システムメモリーの75%の代わりに50%を選ぶべきでしょうか？ これは他のプロセスとの兼ね合いによりますが、デフォルトのままでいるよりはいくらか良いでしょう。この機能はコンフィグレーションを完全に置き換えるつもりのものではなく、保守的な値の方が良いと考えています。
フィードバックをお願いします
私たちは innodb-dedicated-server=ON をデフォルトにすることをMySQL 8.0のGAリリースの前にやろうと考えています。私たちはまだそこには至っていませんが、これはコーナーケースを解決してよりよくするためのフィードバックを集めるチャンスだと思っています。
多くのヘビーユーザーからは、この機能はそんなに大きな影響はないだろう（コンフィグは変えられるのだから）と聞いています。この機能は「すぐに使える」ことにフォーカスした新機能だとおぼえておいてください。
私たちにあなたの考えを教えてください。あなたのMySQLへの貢献に感謝します！
