PolarDB for MySQL は、高性能パラメータテンプレート機能をサポートしています。この章では、PolarDB for MySQL の高性能パラメータテンプレートにおけるパラメータ設定、有効化の方法、および有効化後のパフォーマンス改善について説明します。
概要
PolarDB の多数のパラメータを特定のシナリオに合わせてチューニングすることは、困難な場合があります。パフォーマンスの最適化を簡素化するために、PolarDB は高性能パラメータテンプレートを提供しています。テンプレートをクラスターに直接適用したり、カスタマイズのベースラインとして使用したりできます。これらのテンプレートは、ほとんどの場合においてデータベースのパフォーマンスを向上させます。
PolarDB for MySQL の高性能パラメータテンプレートは、以下の主要なパラメータを変更します。
|
パラメータ |
説明 |
テンプレート値 |
デフォルト値 |
|
innodb_flush_log_at_trx_commit |
0 に設定すると、ログバッファは 1 秒に 1 回ログファイルに書き込まれ、ディスクにフラッシュされます。これによりパフォーマンスは向上しますが、クラッシュ時に最大 1 秒分のトランザクションが失われる可能性があるため、耐久性は低下します。 |
0 |
1 |
|
query_cache_type |
高速クエリキャッシュ機能を有効にするかどうかを指定します。この機能を有効にすると、クエリのパフォーマンスが大幅に向上します。 |
1 |
0 |
|
パラメータ |
説明 |
テンプレート値 |
デフォルト値 |
|
innodb_flush_log_at_trx_commit |
0 に設定すると、ログバッファは 1 秒に 1 回ログファイルに書き込まれ、ディスクにフラッシュされます。これによりパフォーマンスは向上しますが、クラッシュ時に最大 1 秒分のトランザクションが失われる可能性があるため、耐久性は低下します。 |
0 |
1 |
|
loose_innodb_primary_purge_max_id_lag |
このパラメータを 18446744073709551104 に設定すると、読み取り専用ノードの読み取りビューがプライマリノードを制限しなくなります。 |
18446744073709551104 |
N/A |
|
パラメータ |
説明 |
テンプレート値 |
デフォルト値 |
|
innodb_flush_log_at_trx_commit |
0 に設定すると、ログバッファは 1 秒に 1 回ログファイルに書き込まれ、ディスクにフラッシュされます。これによりパフォーマンスは向上しますが、クラッシュ時に最大 1 秒分のトランザクションが失われる可能性があるため、耐久性は低下します。 |
0 |
1 |
|
loose_innodb_lock_sys_rec_partition |
トランザクションロックシステムのパーティション数を指定します。行ロックとテーブルロックの両方を管理するこのシステムをパーティショニングすると、競合のオーバーヘッドが削減されます。 |
64 |
1 |
|
loose_query_cache_type |
高速クエリキャッシュ機能を有効にするかどうかを指定します。この機能を有効にすると、クエリのパフォーマンスが大幅に向上します。 |
ON |
OFF |
制限事項
高性能パラメータテンプレートは、PolarDB の Standard Edition と Cluster Edition の両方でサポートされています。Cluster Edition の場合、クラスターは次のいずれかのバージョンを実行している必要があります:
-
リビジョンバージョンが 5.6.1.0.30 以降の PolarDB for MySQL 5.6。
-
リビジョンバージョンが 5.7.1.0.11 以降の PolarDB for MySQL 5.7。
-
リビジョンバージョンが 8.0.1.1.21 以降の PolarDB for MySQL 8.0.1。
-
リビジョンバージョンが 8.0.2.2.6.1 以降の PolarDB for MySQL 8.0.2。
クラスターのバージョンを確認するには、「エンジンバージョンの照会」をご参照ください。
ユースケースと潜在的なリスク
高性能パラメータテンプレートは、一般的にデータベースのパフォーマンスを向上させますが、耐久性よりも速度を優先します。テンプレートを適用すると、次のようなリスクがあります:
-
データの耐久性が低下します。innodb_flush_log_at_trx_commit パラメータが
0に設定されているため、データベースがクラッシュした場合、過去 1 秒以内にディスクにフラッシュされていないデータが失われる可能性があります。 -
プライマリ/セカンダリ間のレプリケーション遅延が増加する可能性があります。innodb_flush_log_at_trx_commit パラメータが
0に設定されているため、プライマリノードとセカンダリノード間の物理レプリケーションが約 1 秒遅延する可能性があります。
これらのリスクを回避するには、innodb_flush_log_at_trx_commit を 1 に設定してください。
ワークロードが、より高いパフォーマンスと引き換えに、安定性がわずかに低下することを許容できる場合は、高性能パラメータテンプレートをクラスターに適用できます。
高性能パラメータテンプレートを適用する前に、チケットを起票して、Alibaba Cloud のテクニカルサポートに相談することを推奨します。
高性能パラメータテンプレートの適用
次の 2 つの方法のいずれかを使用して、高性能パラメータテンプレートをクラスターに適用できます。
テンプレートを適用した後、変更を有効にするにはクラスターを再起動する必要があります。この再起動により、一時的な接続中断が発生します。この操作はオフピーク時間帯に実行し、アプリケーションに自動再接続メカニズムがあることを確認することを推奨します。
方法 1:
-
PolarDB コンソールにログインします。
-
コンソールの左上で、クラスターがデプロイされているリージョンを選択します。
-
左側メニューで、 パラメーターテンプレート をクリックします。
-
パラメーターテンプレート ページで、 システムパラメーターテンプレート タブをクリックします。
-
mysql_innodb_5.6_high-performance、 mysql_innodb_5.7_high-performance、または mysql_innodb_8.0_high-performance という名前のテンプレートを見つけ、 操作 > クラスターに適用 をクリックします。
-
インスタンスに適用 パネルで、ターゲットクラスターを選択し、> をクリックして Selected Instances リストに追加します。
パラメーター比較 セクションでパラメータの差分を確認できます。
-
OK をクリックします。
説明テンプレートを適用した後、変更を有効にするにはクラスターを再起動する必要があります。
方法 2:
-
PolarDB コンソールにログインします。
-
コンソールの左上で、クラスターがデプロイされているリージョンを選択します。
-
ターゲットクラスターを見つけて、その ID をクリックします。
-
左側メニューで、 を選択します。
-
テンプレートの適用 をクリックします。
-
テンプレートの適用 ダイアログボックスで、 テンプレート名 ドロップダウンリストから適切な高性能テンプレートを選択します。[パラメータ数]、 [再起動が必要なパラメータを含む]、 [再起動が必要] などの詳細を確認できます。必要に応じて、 [重複するパラメータ値を無視] チェックボックスを選択します。
パラメーター比較 セクションでパラメータの差分を確認できます。
-
OK をクリックします。
説明テンプレートを適用した後、変更を有効にするにはクラスターを再起動する必要があります。
パフォーマンスの比較
このセクションでは、高性能パラメータテンプレートの適用前後で、PolarDB for MySQL 8.0 クラスターのパフォーマンスを比較します。この比較では、Sysbench と TPC-C ベンチマークの結果を使用します。
-
Sysbench は、高負荷のデータベースワークロードにおけるシステムパフォーマンスを評価するために使用される、モジュール式でクロスプラットフォームのマルチスレッドベンチマークツールです。
-
TPC-C は、トランザクション処理性能評議会 (TPC) が策定した業界標準のベンチマークで、データベースシステムのオンラインランザクション処理 (OLTP) パフォーマンスを測定します。
-
ここで使用されている TPC-C の実装は公式ベンチマークに基づいていますが、完全には準拠していません。したがって、これらの結果は、公式の TPC-C ベンチマークの結果とは比較できません。
-
テスト環境
-
PolarDB for MySQL クラスター:
-
仕様:88 コア、720 GB メモリ
-
リビジョンバージョン:8.0.1.1.21 以降
-
-
ストレステストクライアント:
-
ストレステストクライアントとデータベース間の ping 遅延は 約 1 ms です。
-
クライアントには十分なコンピューティングリソースとネットワークリソースがあります。
-
-
-
Sysbench テスト手順
-
テストスイート:read_write、write_only
-
初期データセット:25 テーブル、各テーブル 25,000 行
-
パフォーマンスメトリック: QPS (秒間クエリ数)。同時リクエスト数が 1、8、16、32、64、128、256、512、1024 の各レベルにおいて、1 秒あたりに実行される SQL ステートメント (INSERT、SELECT、UPDATE、DELETE を含む) の数を測定します。
-
-
TPC-C テスト手順
-
ツール: TPCC-MySQL
-
初期データセット:1,000 ウェアハウス
-
パフォーマンスメトリック: tpmC (transactions per minute C)。同時リクエスト数が 1、8、16、32、64、128、256、512、1024 の各レベルにおいて、データベースの最大認定スループット (MQTh) を測定します。
-
-
テスト結果
-
Sysbench テスト

-
TPC-C テスト

-
-
結論:Sysbench と TPC-C のテストに基づくと、256 以上の同時リクエストでは、デフォルト設定と比較してパフォーマンスが 2 倍以上向上します。