MySQL - 新しくインストールされた MySQL に合わせて調整する必要がある 10 の構成の詳細な紹介

新しくインストールされた mysql サービスについてまだ心配していて、どのデフォルト設定を変更すればよいかわかりませんか? mysql には 100 以上の調整可能なパラメータがあります。すぐに調整する必要があるパラメータはどれですか?私たちは、MySQL の最適化のために調整する必要がある 10 の構成を学習しました。これらの方法を使用すると、必要な場合は次の情報を参照して、堅牢な MySQL 構成を取得できます。 MySQL の構成を確認して、改善のための提案をいくつか挙げてみましょう。何百もの構成オプションがあるにもかかわらず、少数の設定だけを変更することを提案すると、多くの人が驚きます。この記事の目的は、構成項目の非常に重要なリストを提供することです。数年前にこのような提案をブログで行いましたが、MySQL の世界の変化は速すぎます

...

経験豊富な人でも間違いを犯すことがあります。多くの人が発生し、多くの迷惑がかかることになります。したがって、これらの推奨事項を盲目的に適用する前に、次の点に注意してください:

一度に 1 つの設定のみを変更してください。これが、変更が有益かどうかをテストする唯一の方法です。

ほとんどの構成は、SET GLOBAL を使用して実行時に変更できます。これは、何か問題が発生した場合に変更をすぐに元に戻すのに非常に便利な方法です。ただし、これを永続的にするには、構成ファイルを変更する必要があります。

MySQL を再起動しても効果のない変更を加えましたか?設定を正しい領域に配置していることを確認してください (この記事で説明されているすべての設定は [MySQLD] に属します)

設定を変更した後はサーバーを開くことができません: 正しいユニットを使用していることを確認してください。

innodb_buffer_pool_size の単位は MB で、max_connection にはユニット。

構成ファイル内に重複した構成項目を含めないでください。変更を追跡したい場合は、バージョン管理を使用してください。

「サーバーのメモリが以前の 2 倍になったので、すべての値を前の値の 2 倍に変更する必要がある」などの単純な計算方法は使用しないでください。

1.基本設定

以下の3つの設定項目を頻繁に確認する必要があります。そうしないと、すぐに問題が発生する可能性があります。

innodb_buffer_pool_size:

これは、InnoDB のインストール後に設定する必要がある最初のオプションです。

バッファ プールはデータとインデックスがキャッシュされる場所です。値が大きいほど、ほとんどの読み取り操作でハードディスクの代わりにメモリが使用されます。一般的な値は 5 ～ 6GB (8GB メモリ)、20 ～ 25GB (32GB メモリ)、100 ～ 120GB (128GB メモリ) です。

innodb_log_file_size:

これは REDO ログのサイズです。 REDO ログは、書き込み操作が高速かつ信頼性が高く、クラッシュから回復できることを保証するために使用されます。

MySQL 5.1 までは、パフォーマンスを向上させるためにサイズを大きくしたい一方で、クラッシュ後の回復を早めるためにサイズを小さくしたいと考えていたため、チューニングが困難でした。幸いなことに、MySQL 5.5 以降、クラッシュ リカバリのパフォーマンスが大幅に向上したため、高い書き込みパフォーマンスとクラッシュ リカバリのパフォーマンスを同時に実現できます。 MySQL 5.5 までは、REDO ログの合計サイズは 4 GB に制限されていました (デフォルトでは 2 つのログ ファイルが存在できます)。これは MySQL 5.6 で改善されました。

innodb_log_file_size を最初から 512M に設定します (つまり、1GB の REDO ログが存在します)。これにより、書き込み操作に十分なスペースが確保されます。アプリケーションで頻繁にデータを書き込む必要があり、MySQL 5.6 を使用している場合は、最初から 4G に設定できます。

max_connections:

「接続が多すぎます」エラーが頻繁に表示される場合は、max_connections の値が低すぎることが原因です。これは、アプリケーションがデータベース接続を適切に閉じず、デフォルトの 151 接続よりも高い値が必要なため、非常に一般的です。 max_connection 値が高く設定されている場合 (1000 以上など) の主な欠点は、1000 以上のアクティブなトランザクションを実行するとサーバーが応答しなくなることです。アプリケーションで接続プーリングを使用するか、MySQL でプロセス プーリングを使用すると、この問題の解決に役立ちます。

2. InnoDB 構成

MySQL 5.5 バージョン以降、InnoDB はデフォルトのストレージ エンジンであり、他のストレージ エンジンよりもはるかに多く使用されます。そのため、慎重に構成する必要があります。

innodb_file_per_table:

この設定は、すべてのテーブルのデータとインデックスを共有テーブルスペースに保存する必要があるか (innodb_file_per_table = OFF)、各テーブルのデータを個別の .ibd ファイルに配置する必要があるか (innodb_file_per_table =の上）。テーブルごとに 1 つのファイルを使用すると、テーブルの削除、切り捨て、または再構築時にディスク領域を再利用できます。これは、データ圧縮などの一部の高度な機能にも必要です。しかし、それによってパフォーマンスが向上することはありません。テーブルごとに 1 つのファイルを必要としない主なシナリオは、非常に多数のテーブル (10k 以上など) がある場合です。 🎜

MySQL 5.6 では、このプロパティのデフォルト値は ON なので、ほとんどの場合、何もする必要はありません。以前のバージョンでは、新しく作成されたテーブルのみに影響するため、データをロードする前にこのプロパティを ON に設定する必要がありました。

innodb_flush_log_at_trx_commit:

デフォルト値は 1 で、InnoDB が ACID 機能を完全にサポートしていることを示します。この値は、マスター ノードなどのデータ セキュリティが主な関心事である場合に最も適切です。ただし、ディスク (読み取りおよび書き込み) 速度が遅いシステムの場合、REDO ログへの変更をフラッシュするたびに追加の fsync が必要になるため、大きなオーバーヘッドが発生します。この値を 2 に設定すると、送信されたトランザクションは 1 秒に 1 回だけ REDO ログにフラッシュされるため、信頼性が低くなりますが、プライマリ ノードのバックアップ ノードなど、一部のシナリオでは許容されます。 。 の。値 0 は高速ですが、システムクラッシュが発生した場合にデータが失われる可能性があります。バックアップ ノードにのみ適用されます。

innodb_flush_method:

この構成は、データとログがハードディスクに書き込まれる方法を決定します。一般に、ハードウェア RAID コントローラがあり、その独立したキャッシュがライトバック メカニズムを使用し、バッテリ電源障害保護機能を備えている場合は、O_DIRECT として設定する必要があります。そうでない場合は、ほとんどの場合、fdatasync (デフォルト値) に設定する必要があります。 sysbench は、こ​​のオプションを決定するのに役立つ優れたツールです。

innodb_log_buffer_size:

この設定は、まだ実行されていないトランザクションに割り当てられるバッファを決定します。通常はデフォルト値 (1MB) で十分ですが、トランザクションに大きなバイナリ オブジェクトまたは大きなテキスト フィールドが含まれている場合、このキャッシュはすぐにいっぱいになり、追加の I/O 操作がトリガーされます。 Innodb_log_waits ステータス変数を確認し、0 でない場合は、innodb_log_buffer_size を増やします。

3. その他の設定

query_cache_size:

クエリ キャッシュ (クエリ キャッシュ) は、同時実行性がそれほど高くない場合でもよく知られているボトルネックです。

最良のオプションは、最初からこれを無効にし、query_cache_size = 0 (MySQL 5.6 のデフォルト) に設定し、他の方法を使用してクエリを高速化することです: インデックスを最適化する、負荷を分散するためにコピーを追加する、または追加のキャッシュを有効にする (たとえば、 memcache または redis として)。アプリケーションのクエリ キャッシュを有効にしていて、何も問題が発生していない場合は、クエリ キャッシュが役立つ可能性があります。無効にしたい場合は注意が必要です。

log_bin:

データベースサーバーをマスターノードのバックアップノードとして機能させたい場合は、バイナリログを有効にすることが必須です。これを行う場合は、server_id を一意の値に設定することを忘れないでください。サーバーが 1 台だけの場合でも、これ (バイナリ ログを有効にする) は、ポイントインタイム データのリカバリを実行する場合に役立ちます。最新のバックアップ (完全バックアップ) から復元し、バイナリ ログの変更を適用します (増分バックアップ)。 。バイナリ ログは作成されると永久に保存されます。したがって、ディスク容量を使い果たしたくない場合は、PURGE BINARY LOGS を使用して古いファイルを削除するか、expire_logs_days を設定してログが自動的に削除されるまでの日数を指定できます。

バイナリ ログのログ作成にはオーバーヘッドが発生するため、プライマリ ノードではないレプリカ ノードで必要ない場合は、このオプションをオフにすることをお勧めします。

skip_name_resolve:

クライアントがデータベースサーバーに接続すると、サーバーはホスト名解決を行います。DNS が遅い場合、接続の確立も遅くなります。したがって、DNS ルックアップを行わずにサーバーを起動する場合は、skip_name_resolve オプションをオフにすることをお勧めします。唯一の制限は、後で GRANT ステートメントで使用できるのは IP アドレスのみであるため、この設定を既存のシステムに追加する場合は注意が必要です。

概要

もちろん、負荷やハードウェアに応じて、他の設定も影響する可能性があります。遅いメモリと速いディスク、高い同時実行性、および書き込み集中型の負荷の場合には、特別なチューニングが必要になります。ただし、ここでの目標は、重要でない MySQL 設定を調整したり、ドキュメントを読んでどの設定が重要であるかを調べることにあまり時間を費やすことなく、堅牢な MySQL 構成を迅速に取得できるようにすることです。

以上がMySQL - 新しくインストールされた MySQL に合わせて調整する必要がある 10 の構成の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。