Azure Database for MySQL - フレキシブル サーバーのサーバー パラメーター
適用対象:
Azure Database for MySQL - フレキシブル サーバー
この記事では、Azure Database for MySQL フレキシブル サーバーでサーバー パラメーターを構成するための考慮事項とガイドラインを示します。
Note
この記事には、Microsoft が使用しなくなった "スレーブ" という用語への言及が含まれています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。
サーバー変数とは
MySQL エンジンには、エンジンの動作を構成および調整するために使用できるさまざまなサーバー変数やパラメーターが用意されています。 実行時に動的に設定できるパラメーターもあれば、適用するためにサーバーを再起動する必要がある "静的" なものもあります。
Azure Database for MySQL フレキシブル サーバーでは、さまざまな MySQL サーバー パラメーターの値を、Azure portal および Azure CLI を使ってワークロードのニーズに合わせて変更できる機能が公開されています。
構成可能なサーバー パラメーター
サーバー パラメーターを使用して Azure Database for MySQL フレキシブル サーバー構成を管理できます。 このサーバー パラメーターは、サーバーの作成時に既定値と推奨値を使用して構成されます。 Azure portal の [サーバー パラメーター] ブレードには、変更可能および変更不可のサーバー パラメーターの両方が表示されます。 変更不可のサーバー パラメーターはグレーで表示されます。
サポートされるサーバー パラメーターの一覧は、拡大を続けています。 Azure portal の [サーバー パラメーター] タブを使用して完全な一覧を表示し、サーバー パラメーターの値を構成できます。
よく更新されるいくつかのサーバー パラメーターの制限について詳しくは、次のセクションを参照してください。 制限は、サーバーのコンピューティング レベルとサイズ (仮想コア) によって決まります。
Note
- ポータルを使用して静的サーバー パラメーターを変更する場合、変更を有効にするためにサーバーを再起動する必要があります。 (ARM テンプレート、Terraform、Azure CLI などのツールを使用して) 自動化スクリプトを利用しようとしている場合は、作成エクスペリエンスの一部として構成を変更する場合でも、スクリプトに、設定を有効にするためにサービスを再起動するプロビジョニングを含める必要があります。
- お使いの環境に合わせて、変更不可のサーバー パラメーターの変更する場合は、UserVoice 項目を開くか、フィードバックが既に存在する場合は投票してください。これは Microsoft が優先順位を付けるのに役立ちます。
lower_case_table_names
Azure Database for MySQL フレキシブル サーバーでは、MySQL バージョン 5.7 の既定値は 1 です。 サポートされている値を 2 に変更することは可能ですが、2 から 1 に戻すことはできないことに注意してください。 既定値の変更については、サポート チームにお問い合わせください。 MySQL バージョン 8.0 以降の場合、lower_case_table_names は、サーバーの初期化時にのみ構成できます。 詳細情報。 サーバーの初期化後に lower_case_table_names 設定を変更することは禁止されています。 Azure Database for MySQL フレキシブル サーバーでは、MySQL バージョン 8.0 の既定値は 1 です。 Azure Database for MySQL フレキシブル サーバーでは、MySQL バージョン 8.0 でサポートされている値は 1 と 2 です。 サーバー作成時の既定値の変更については、サポート チームにお問い合わせください。
innodb_tmpdir
Azure Database for MySQL フレキシブル サーバーの innodb_tmpdir パラメーターは、再構築するオンライン ALTER TABLE 操作中に作成された一時的な並べ替えファイルのディレクトリを定義するために使用されます。 innodb_tmpdir の既定値は /mnt/temp です。 この場所は一時ストレージ SSD に対応し、各サーバーのコンピューティング サイズで GiB 単位で使用できます。 この場所は、大量の領域を必要としない操作に最適です。
必要な領域が増えた場合は、innodb_tmpdir を /app/work/tmpdir に設定できます。 これは、お使いのストレージ、すなわち Azure Database for MySQL フレキシブル サーバーで使用可能な容量を利用します。 これは、より多くの一時ストレージを必要とする大規模な操作に役立ちます。
/app/work/tmpdir を使用すると、既定の一時ストレージ (SSD)/mnt/temp と比較してパフォーマンスが低下することに注意してください。 操作の特定の要件に基づいて選択する必要があります。
innodb_tmpdir に指定される情報は、既定値 /mnt/temp が一般的であるパラメーター innodb_temp_tablespaces_dir、tmpdir、および slave_load_tmpdir に適用できます。代替ディレクトリ /app/work/tmpdir は、一時ストレージの増加を構成するのに使用でき、特定の運用要件に基づくパフォーマンスのトレードオフを伴います。
log_bin_trust_function_creators
Azure Database for MySQL フレキシブル サーバーの場合、バイナリ ログは常に有効になっています (つまり、log_bin が ON に設定されています)。 フレキシブル サーバーでは、log_bin_trust_function_creators は既定で ON に設定されています。
バイナリ ログ形式は常に行であり、サーバーへのすべての接続では常に行ベースのバイナリ ログが使用されます。 行ベースのバイナリ ログを使用すると、セキュリティ上の問題が存在せず、バイナリ ログを中断できないため、安全に log_bin_trust_function_creators をオンのままにしておくことができます。
[log_bin_trust_function_creators] がオフに設定されている場合、トリガーの作成を試みると、"SUPER 特権を持っておらず、バイナリ ログが有効になっています (より安全度の低い log_bin_trust_function_creators 変数を使用することもできます)" のようなエラーが表示されます。
innodb_buffer_pool_size
このパラメーターの詳細については、MySQL のドキュメントを確認してください。
| 価格レベル | 仮想コア数 | メモリ サイズ (GiB) | 既定値 (バイト) | 最小値 (バイト) | 最大値 (バイト) |
|---|---|---|---|---|---|
| バースト可能 (B1s) | 1 | 1 | 134217728 | 33554432 | 134217728 |
| バースト可能 (B1ms) | 1 | 2 | 536870912 | 134217728 | 536870912 |
| バースト可能 | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| General Purpose | 2 | 8 | 5368709120 | 134217728 | 5368709120 |
| General Purpose | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| General Purpose | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| General Purpose | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| General Purpose | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| General Purpose | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| General Purpose | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| Business Critical | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| Business Critical | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| Business Critical | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| Business Critical | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| Business Critical | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| Business Critical | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| Business Critical | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
innodb_file_per_table
MySQL では、テーブルの作成時に指定した構成に基づいて、InnoDB テーブルが異なるテーブルスペースに格納されます。 システム テーブルスペースは、InnoDB データ辞書のストレージ領域です。 file-per-table テーブルスペースは、1 つの InnoDB テーブルに対するデータとインデックスを含み、固有のデータ ファイル内のファイル システムに格納されています。 この動作は、innodb_file_per_table サーバー パラメーターによって制御されています。 innodb_file_per_table を OFF に設定すると、InnoDB ではシステム テーブルスペースにテーブルが作成されます。 それ以外の場合、InnoDB では file-per-table テーブルスペースにテーブルが作成されます。
Azure Database for MySQL フレキシブル サーバーは、1 つのデータ ファイル内で、最大 4 TB までをサポートしています。 データベースのサイズが 4 TB を超える場合は、innodb_file_per_table テーブルスペースにテーブルを作成する必要があります。 1 つのテーブル サイズが 4 TB を超える場合は、パーティション テーブルを使用する必要があります。
innodb_log_file_size
innodb_log_file_size は、ログ グループ内の各ログ ファイルのサイズ (バイト単位) です。 ログ ファイルの合計サイズ (innodb_log_file_size * innodb_log_files_in_group) は、最大値 (512 GB 弱) を超えることはできません。 ログ ファイルのサイズを大きくすると、パフォーマンスが向上しますが、クラッシュ後の復旧時間が長くなるという欠点があります。 まれに発生するクラッシュ後の復旧の復旧時間と、ピーク操作中のスループットの最大化との間でバランスを取る必要があります。 これにより、再起動時間が長くなることもあります。 Azure Database for MySQL フレキシブル サーバーでは、innodb_log_file_size を 256 MB、512 MB、1 GB、2 GB のいずれかの値に構成できます。 このパラメーターは静的であり、再起動が必要です。
注意
innodb_log_file_size パラメーターを既定値から変更した場合は、再起動の遅延を回避するため、"show global status like 'innodb_buffer_pool_pages_dirty'" の値が 30 秒間 0 のままであるかどうかを確認してください。
max_connections
max_connection の値は、サーバーのメモリ サイズによって決まります。
| 価格レベル | 仮想コア数 | メモリ サイズ (GiB) | 既定値 | 最小値 | 最大値 |
|---|---|---|---|---|---|
| バースト可能 (B1s) | 1 | 1 | 85 | 10 | 171 |
| バースト可能 (B1ms) | 1 | 2 | 171 | 10 | 341 |
| バースト可能 | 2 | 4 | 341 | 10 | 683 |
| General Purpose | 2 | 8 | 683 | 10 | 1365 |
| General Purpose | 4 | 16 | 1365 | 10 | 2731 |
| General Purpose | 8 | 32 | 2731 | 10 | 5461 |
| General Purpose | 16 | 64 | 5461 | 10 | 10923 |
| General Purpose | 32 | 128 | 10923 | 10 | 21845 |
| General Purpose | 48 | 192 | 16384 | 10 | 32768 |
| General Purpose | 64 | 256 | 21845 | 10 | 43691 |
| Business Critical | 2 | 16 | 1365 | 10 | 2731 |
| Business Critical | 4 | 32 | 2731 | 10 | 5461 |
| Business Critical | 8 | 64 | 5461 | 10 | 10923 |
| Business Critical | 16 | 128 | 10923 | 10 | 21845 |
| Business Critical | 32 | 256 | 21845 | 10 | 43691 |
| Business Critical | 48 | 384 | 32768 | 10 | 65536 |
| Business Critical | 64 | 504 | 43008 | 10 | 86016 |
接続数が制限を超えると、次のエラーが表示される場合があります。
ERROR 1040 (08004):Too many connections (接続が多すぎます)
重要
最適なエクスペリエンスを得るために、ProxySQL のような接続プーラーを使用して、接続を効率的に管理することをお勧めします。
MySQL への新しいクライアント接続を作成するには時間がかかり、一度確立されると、アイドル状態のときでも、これらの接続によってデータベース リソースが消費されます。 ほとんどのアプリケーションでは、短時間の接続を多数要求します。これにより、この状況が悪化します。 結果として、実際のワークロードに使用できるリソースが少なくなるため、パフォーマンスが低下します。 アイドル状態の接続を減らして既存の接続を再利用する接続プーラーは、これを回避するのに役立ちます。 ProxySQL の設定については、ブログ投稿を参照してください。
Note
ProxySQL はオープンソースのコミュニティ ツールです。 Microsoft によってベスト エフォート方式でサポートされています。 信頼のあるガイダンスでの運用サポートを受けるには、ProxySQL 製品サポートを確認して問い合わせることができます。
innodb_strict_mode
"Row size too large (> 8126) (行のサイズが大きすぎます (> 8126))" などのエラーが表示された場合は、innodb_strict_mode パラメーターをオフにすることができます。 サーバー パラメーター innodb_strict_mode をサーバー レベルでグローバルに変更することはできません。行データのサイズが 8 kb を超える場合、エラーが表示されずにデータが切り捨てられ、データが失われる可能性があるためです。 ページ サイズの制限に合うようにスキーマを変更することをお勧めします。
このパラメーターは、init_connect を使用してセッション レベルで設定できます。 セッション レベルで innodb_strict_mode を設定するには、「設定パラメーターが一覧に含まれていない」を参照してください。
注意
読み取りレプリカ サーバーがある場合は、ソース サーバーのセッション レベルで innodb_strict_mode をオフに設定すると、レプリケーションが中断されます。 読み取りレプリカがある場合、このパラメーターは ON に設定したままにすることをお勧めします。
time_zone
初期デプロイの時点で、Azure Database for MySQL フレキシブル サーバー インスタンスにはタイム ゾーン情報のシステム テーブルが含まれていますが、これらのテーブルには値が設定されていません。 タイム ゾーン テーブルには、MySQL コマンド ラインや MySQL Workbench などのツールから mysql.az_load_timezone ストアド プロシージャを呼び出すことでデータを入力できます。 ストアド プロシージャを呼び出す方法とグローバル レベルまたはセッション レベルのタイム ゾーンを設定する方法については、Azure portal または Azure CLI の記事を参照してください。
binlog_expire_logs_seconds
Azure Database for MySQL フレキシブル サーバーでは、このパラメーターは、サービスがバイナリ ログ ファイルを消去するまでに待機する秒数を指定します。
バイナリ ログには、テーブルの作成操作やテーブル データの変更などのデータベースの変更を記述する "イベント" が含まれます。 また、変更を加えた可能性のあるステートメントのイベントも含まれます。 バイナリ ログは、主にレプリケーション操作とデータの復旧操作の 2 つの目的で使用されます。 通常、バイナリ ログは、ハンドルがサービス、バックアップ、またはレプリカ セットから解放されるとすぐに消去されます。 レプリカが複数存在する場合、バイナリ ログは、最も遅いレプリカが変更を読み取るまで待機してから消去されます。 バイナリ ログをより長期間保持するには、binlog_expire_logs_seconds パラメーターを構成します。 binlog_expire_logs_seconds が既定値の 0 に設定されている場合、バイナリ ログは、ハンドルが解放されるとすぐに消去されます。 binlog_expire_logs_seconds が 0 を超える場合、設定された秒数待機してから消去されます。 Azure Database for MySQL フレキシブル サーバーの場合、バックアップおよび読み取りレプリカでのバイナリ ファイルの消去などのマネージド機能は内部で処理されます。 Azure Database for MySQL フレキシブル サーバーからデータ出力をレプリケートする場合は、レプリカによってプライマリから変更が読み取られる前にバイナリ ログが消去されるのを回避するために、プライマリでこのパラメーターを設定する必要があります。 binlog_expire_logs_seconds に大きな値を設定すると、バイナリ ログがすぐに消去されず、ストレージの課金が増加する可能性があります。
event_scheduler
Azure Database for MySQL フレキシブル サーバーでは、event_schedule サーバー パラメーターは、イベント (つまり、スケジュールに従って実行されるタスク) の作成、スケジュール設定、および実行を管理します。これらは、特別なイベント スケジューラ スレッドによって実行されます。 event_scheduler パラメーターが ON に設定されている場合、イベント スケジューラ スレッドは SHOW PROCESSLIST の出力にデーモン プロセスとして一覧表示されます。 次の SQL 構文を使用して、イベントを作成およびスケジュールできます。
CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;
Note
イベントの作成の詳細については、以下の MySQL イベント スケジューラのドキュメントを参照してください。
event_scheduler サーバー パラメーターの構成
次のシナリオは、Azure Database for MySQL フレキシブル サーバーで event_scheduler パラメーターを使用する 1 つの方法を示しています。 シナリオを説明するために、次の単純なテーブルの例を考えてみましょう。
mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)
Azure Database for MySQL フレキシブル サーバーで event_scheduler サーバー パラメーターを構成するには、次の手順に従います。
Azure portal で、Azure Database for MySQL フレキシブル サーバー インスタンスに移動し、[設定] で [サーバー パラメーター] を選択します。
[サーバー パラメーター] ブレードで、[値] ドロップダウン リストで
event_schedulerを検索し、[オン] を選択し、[保存] を選択します。Note
動的なサーバー パラメーター構成の変更は、再起動なしでデプロイされます。
次に、イベントを作成するために、Azure Database for MySQL フレキシブル サーバー インスタンスに接続し、次の SQL コマンドを実行します。
CREATE EVENT test_event_01 ON SCHEDULE EVERY 1 MINUTE STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR COMMENT ‘Inserting record into the table tab1 with current timestamp’ DO INSERT INTO tab1(id,createdAt,createdBy) VALUES('',NOW(),CURRENT_USER());イベント スケジューラの詳細を表示するには、次の SQL ステートメントを実行します。
SHOW EVENTS;次のような出力が表示されます。
mysql> show events; +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ 1 row in set (0.23 sec)数分たったら、テーブルの行に対してクエリを実行し、構成した
event_schedulerパラメーターに従って、1 分ごとに挿入される行の表示を開始します。mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | +----+---------------------+-------------+ 4 rows in set (0.23 sec)1 時間たったら、テーブルで Select ステートメントを実行し、この例での
event_schedulerの構成どおり、1 時間の間 1 分ごとにテーブルに挿入された値のすべての結果を表示します。mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | | 5 | 2023-04-05 14:51:04 | azureuser@% | | 6 | 2023-04-05 14:52:04 | azureuser@% | ..< 50 lines trimmed to compact output >.. | 56 | 2023-04-05 15:42:04 | azureuser@% | | 57 | 2023-04-05 15:43:04 | azureuser@% | | 58 | 2023-04-05 15:44:04 | azureuser@% | | 59 | 2023-04-05 15:45:04 | azureuser@% | | 60 | 2023-04-05 15:46:04 | azureuser@% | | 61 | 2023-04-05 15:47:04 | azureuser@% | +----+---------------------+-------------+ 61 rows in set (0.23 sec)
その他のシナリオ
イベントは、ご自身の具体的なシナリオの要件に基づいて設定できます。 以下に、SQL ステートメントを異なる時間間隔で実行するようにスケジュールする、いくつかの類似する例を示します。
SQL ステートメントを今すぐ実行し、1 日に 1 回繰り返し、終了時間は設定しない
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;
1 時間ごとに SQL ステートメントを実行し、終了時間は設定しない
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
1 日ごとに SQL ステートメントを実行し、終了時間は設定しない
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;
制限事項
高可用性が構成されているサーバーの場合、フェールオーバーが発生すると、event_scheduler サーバー パラメーターが 'OFF' に設定される可能性があります。 これが発生した場合は、フェールオーバーが完了したら、パラメーターを構成して値を 'ON' に設定します。
変更不可のサーバー パラメーター
Azure portal の [サーバー パラメーター] ブレードには、変更可能および変更不可のサーバー パラメーターの両方が表示されます。 変更不可のサーバー パラメーターはグレーで表示されます。セッション レベルで変更不可のサーバー パラメーターを構成する場合、init_connect を使用して接続レベルでパラメーターを設定する方法については、Azure portal または Azure CLI の記事を参照してください。
次のステップ
- Azure ポータルでサーバー パラメーターを構成する方法
- Azure CLI でサーバー パラメーターを構成する方法