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 を使用して、サーバー パラメーターの完全な一覧を定期的に表示し、値を構成できます。
ポータルを使用して静的サーバー パラメーターを変更する場合、変更を有効にするためにサーバーを再起動する必要があります。 Azure Resource Manager テンプレート、Terraform、Azure CLI などのツールを使用して自動化スクリプトを使用する場合、作成エクスペリエンスの一部として構成を変更する場合でも、設定を有効にするためにサービスを再起動するプロビジョニングをスクリプトに含める必要があります。
お使いの環境に合わせて変更不可のサーバー パラメーターを変更する場合は、コミュニティ フィードバックからアイデアを投稿するか、フィードバックが既に存在する場合は投票してください。これは Microsoft が優先順位を付けるのに役立ちます。
以降のセクションでは、一般的に更新されるサーバー パラメーターの制限について説明します。 制限は、サーバーのコンピューティング レベルとサイズ (仮想コア) によって決まります。
lower_case_table_names
MySQL バージョン 5.7 の場合、Azure Database for MySQL - フレキシブル サーバーでは、lower_case_table_names の既定値は 1 です。 サポートされている値を 2 に変更することはできますが、2 から 1 に戻すことはできません。 既定値の変更については、サポート チケットを作成してください。
MySQL バージョン 8.0 以降では、サーバーを初期化する場合にのみ lower_case_table_names を構成できます。 詳細情報。 サーバーの初期化後に lower_case_table_names 設定を変更することは禁止されています。
Azure Database for MySQL - フレキシブル サーバーでは、MySQL バージョン 8.0 でサポートされている値は 1 と 2 です。 既定値は 1 です。 サーバー作成時の既定値の変更については、サポート チケットを作成してください。
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 に対して提供される情報は、パラメーター innodb_temp_tablespaces_dir、tmpdir、および slave_load_tmpdir に適用できます。
- 既定値
/mnt/tempは共通です。 - 代替ディレクトリ
/app/work/tmpdirは、一時ストレージの増加を構成するために使用でき、特定の運用要件に基づくパフォーマンスのトレードオフがあります。
log_bin_trust_function_creators
Azure Database for MySQL - フレキシブル サーバーの場合、バイナリ ログは常に有効になっています (つまり、log_bin が ON に設定されています)。 log_bin_trust_function_creators パラメーターは、フレキシブル サーバーでは既定で ON に設定されます。
バイナリ ログ形式は常にROW であり、サーバーへの接続では常に行ベースのバイナリ ログが使用されます。 行ベースのバイナリ ログを使用すると、セキュリティ上の問題が存在せず、バイナリ ログを中断できないため、安全に log_bin_trust_function_creators を ON のままにしておくことができます。
log_bin_trust_function_creators が OFF に設定されている場合、トリガーの作成を試みると、"SUPER 特権を持っておらず、バイナリ ログが有効になっています (より安全度の低い log_bin_trust_function_creators 変数を使用することもできます)" のようなエラーが表示されます。
innodb_buffer_pool_size
innodb_buffer_pool_size パラメーターの詳細については、MySQL のドキュメントを参照してください。
次の表の物理メモリ サイズは、Azure Database for MySQL フレキシブル サーバーで使用可能なランダム アクセス メモリ (RAM) をギガバイト (GB) 単位で表したものです。
| 価格レベル | 仮想コア | 物理メモリ サイズ (GB) | 既定値 (バイト) | 最小値 (バイト) | 最大値 (バイト) |
|---|---|---|---|---|---|
| バースト可能 (B1s) | 1 | 1 | 134217728 | 33554432 | 268435456 |
| バースト可能 (B1ms) | 1 | 2 | 536870912 | 134217728 | 1073741824 |
| バースト可能 (B2s) | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| バースト可能 (B2ms) | 2 | 8 | 4294967296 | 134217728 | 5368709120 |
| バースト可能 | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| バースト可能 | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| バースト可能 | 12 | 48 | 51539607552 | 134217728 | 51539607552 |
| バースト可能 | 16 | 64 | 2147483648 | 134217728 | 2147483648 |
| バースト可能 | 20 | 80 | 64424509440 | 134217728 | 64424509440 |
| 汎用 | 2 | 8 | 4294967296 | 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 | 20 | 160 | 128849018880 | 134217728 | 128849018880 |
| 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 つのデータ ファイル内で、最大 8 テラバイト (TB) までをサポートしています。 データベースのサイズが 8 TB を超える場合は、innodb_file_per_table テーブルスペースにテーブルを作成する必要があります。 1 つのテーブル サイズが 8 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_size を 256 メガバイト (MB)、512 MB、1 GB、2 GB のいずれかの値に構成できます。 このパラメーターは静的であり、再起動が必要です。
Note
innodb_log_file_size パラメーターを既定値から変更した場合は、再起動の遅延を回避するために、show global status like 'innodb_buffer_pool_pages_dirty' の値が 30 秒間 0 にとどまっているかどうかを確認します。
max_connections
サーバーのメモリ サイズによって max_connections の値が決まります。 次の表の物理メモリ サイズは、Azure Database for MySQL フレキシブル サーバーで使用可能な RAM をギガバイト単位で表したものです。
| 価格レベル | 仮想コア | 物理メモリ サイズ (GB) | 規定値 | 最小値 | 最大値 |
|---|---|---|---|---|---|
| バースト可能 (B1s) | 1 | 1 | 85 | 10 | 171 |
| バースト可能 (B1ms) | 1 | 2 | 171 | 10 | 341 |
| バースト可能 (B2s) | 2 | 4 | 341 | 10 | 683 |
| バースト可能 (B2ms) | 2 | 4 | 683 | 10 | 1365 |
| バースト可能 | 4 | 16 | 1365 | 10 | 2731 |
| バースト可能 | 8 | 32 | 2731 | 10 | 5461 |
| バースト可能 | 12 | 48 | 4097 | 10 | 8193 |
| バースト可能 | 16 | 64 | 5461 | 10 | 10923 |
| バースト可能 | 20 | 80 | 6827 | 10 | 13653 |
| 汎用 | 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 | 20 | 160 | 13653 | 10 | 27306 |
| Business Critical | 32 | 256 | 21845 | 10 | 43691 |
| Business Critical | 48 | 384 | 32768 | 10 | 65536 |
| Business Critical | 64 | 504 | 43008 | 10 | 86016 |
接続数が制限を超えると、"エラー 1040 (08004): 接続が多すぎます" というエラーが表示される場合があります。
新しいクライアント接続を MySQL に作成すると、時間がかかります。 これらの接続を確立すると、アイドル状態であっても、データベース リソースが占有されます。 ほとんどのアプリケーションでは、短時間の接続を多数要求します。これにより、この状況が悪化します。 結果として、実際のワークロードに使用できるリソースが少なくなるため、パフォーマンスが低下します。
アイドル状態の接続を減らして既存の接続を再利用する接続プーラーは、この問題を回避するのに役立ちます。 最適なエクスペリエンスを得るために、ProxySQL のような接続プーラーを使用して、接続を効率的に管理することをお勧めします。 ProxySQL の設定については、ブログ投稿を参照してください。
Note
ProxySQL はオープンソースのコミュニティ ツールです。 Microsoft は、ベスト エフォート方式でサポートします。 信頼のあるガイダンスでの運用サポートを受けるには、ProxySQL 製品サポートにお問い合わせください。
innodb_strict_mode
"行のサイズが大きすぎます (> 8126)" などのエラーが表示された場合は、innodb_strict_mode サーバー パラメーターをオフにすることができます。 このパラメーターをサーバー レベルでグローバルに変更することはできません。行データのサイズが 8K を超える場合、エラーが表示されずにデータが切り捨てられるためです。 この切り捨てによって、データが失われる可能性があります。 ページ サイズの制限に合うようにスキーマを変更することをお勧めします。
このパラメーターは、init_connect を使用してセッション レベルで設定できます。 詳細については、変更不可のサーバー パラメーターの設定に関する記事を参照してください。
Note
読み取りレプリカ サーバーがある場合、ソース サーバーのセッション レベルで innodb_strict_mode を OFF に設定すると、レプリケーションが中断されます。 読み取りレプリカがある場合、このパラメーターは 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 - フレキシブル サーバーでは、binlog_expire_logs_seconds パラメーターは、サービスがバイナリ ログ ファイルを削除するまでに待機する秒数を指定します。
"バイナリ ログ" には、テーブルの作成操作やテーブル データの変更など、データベースの変更を示すイベントが含まれます。 バイナリ ログには、変更を加えた可能性のあるステートメントのイベントも含まれます。 バイナリ ログは、主にレプリケーション操作とデータの復旧操作の 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_scheduler サーバー パラメーターによって、イベントの作成、スケジュール設定、実行が管理されます。 つまり、パラメーターは、特別な MySQL イベントスケジューラ スレッドによってスケジュールに従って実行されるタスクを管理します。 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>;
イベントの作成の詳細については、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を検索します。 [値] ドロップダウン リストで [ON] を選択し、[保存] を選択します。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ステートメントを実行し、1 時間の間 1 分ごとにテーブルに挿入された値のすべての結果を表示します (この場合、event_schedulerが構成されています)。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 の [サーバー パラメーター] ペインには、変更可能および変更不可のサーバー パラメーターの両方が表示されます。 変更不可のサーバー パラメーターは選択できません。 Azure portal または Azure CLI で init_connect を使用し、セッション レベルで変更不可のサーバー パラメーターを構成できます。