PolarDB for MySQL マルチマスタークラスター (無制限) エディションは、アーキテクチャを 1 つの書き込みノードと複数の読み取りノードのモデルから、複数の書き込みノードと複数の読み取りノードのモデルにアップグレードします。異なる計算ノード上の異なるデータベースまたはデータオブジェクトへの同時書き込みをサポートします。また、ノード間でのデータベースとデータオブジェクトの動的スケジューリングもサポートしており、切り替えは数秒で完了します。この機能により、クラスターの同時読み取り/書き込み機能が大幅に向上します。サポートされているデータオブジェクトには、テーブル、ビュー、トリガー、イベント、ストアドプロシージャ、ユーザー定義関数が含まれます。このトピックでは、マルチマスタークラスター (無制限) エディションの使用方法について説明します。
前提条件
マルチマスタークラスター (無制限) エディションのクラスターを購入済みであること。 詳細については、「カスタム購入」および「サブスクリプションクラスターの購入」をご参照ください。
特権アカウントを作成済みであること。 詳細については、「特権アカウントの作成」をご参照ください。
データベースクラスターに接続済みであること。 詳細については、「データベースクラスターへの接続」をご参照ください。
マルチマスタークラスター (無制限) エディションは PolarDB for MySQL 8.0 でサポートされています。
制限事項
各データベースまたはデータオブジェクトのデータは、1 つのノードからのみ書き込むことができます。対応するデータベースまたはデータオブジェクトが割り当てられていないノードでは、データの読み取りまたは書き込みはできません。デフォルトでは、操作はデータベースレベルで実行されます。データオブジェクトレベルで操作を実行するには、指定された構文を使用して分離レベルを切り替える必要があります。
RW ノード間のデータクエリはサポートされていません。クエリ SQL 文に複数の RW ノード上のデータベースまたはデータオブジェクトが含まれている場合、システムはエラーを報告します。このようなクエリを実行する前に、関連するすべてのデータベースまたはデータオブジェクトのエンドポイントを単一の RW ノードに移動する必要があります。
クラスターエンドポイント () のみがサポートされ、プライマリエンドポイントはサポートされていません。
エンドポイントの切り替えでは、次のモードがサポートされています:
データベース分離レベルでは、データベースエンドポイントを切り替えることができます。
データオブジェクト分離レベルでは、データオブジェクトのエンドポイントを切り替えることができます。
データベース作成時に RW ノードを指定する
指定した RW ノードにデータベースを作成できます。構文は次のとおりです:
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];データベース分離モードでは、各データベースのデータは 1 つのノードからのみ書き込むことができます。
[POLARDB_WRITE_NODE master_id]を省略した場合、データベースの作成に使用される RW ノードは loose_innodb_mm_default_master_id パラメーターの値によって決まります。loose_innodb_mm_default_master_id パラメーターの値が 0 の場合、システムはデータベースを作成する RW ノードをランダムに選択します。PolarDB コンソールの ページに移動して、クラスターまたはノードのパラメーターを表示および変更できます。ノード間のデータベースの分散を表示するには、「データベースの分散をクエリする」をご参照ください。
例: RW1 に db1 という名前のデータベースを作成します。
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;データベース db1 を RW2 に作成するには、上記の例で 1 を 2 に変更します。
指定した RW ノード上のデータベースを削除する
指定した RW ノード上のデータベースを削除できます。構文は次のとおりです:
DROP DATABASE name;例: RW1 ノードからデータベース db1 を削除します。
DROP DATABASE db1;データベースを削除するときに POLARDB_WRITE_NODE を指定する必要はありません。
データベースエンドポイントの切り替え
データベースのエンドポイントを別の RW ノードに切り替えることができます。構文は次のとおりです:
ALTER DATABASE name POLARDB_WRITE_NODE master_id;例: データベース db1 のエンドポイントを RW2 に切り替えます。
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;エンドポイントの切り替えは、通常、時間のかかる操作です。実行時間は、次の 2 つの要因によって異なります:
データベース内のテーブルの数。データベースに多数のテーブルが含まれている場合、切り替えは遅くなります。
切り替え中のデータベースに対するデータ操作言語 (DML) の負荷。DML の負荷が高い場合、切り替えは遅くなります。
データベース分離レベルからデータオブジェクト分離レベルへの切り替え
デフォルトでは、マルチマスタークラスターの分離レベルはデータベースレベルです。これは、同じデータベース内のすべてのデータオブジェクトが 1 つの RW ノードからのみアクセスできることを意味します。同じデータベース内のデータオブジェクトに複数の RW ノードからアクセスできるようにするには、分離レベルをデータベースレベルからデータオブジェクトレベルに変更します。構文は次のとおりです:
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;この文では、name はデータベースの名前、master_id はデータオブジェクトのエンドポイントです。
例: データベース db1 の分離レベルをデータベースレベルからデータオブジェクトレベルに変更し、エンドポイントを RW2 に設定します。
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;分離レベルの切り替えは、通常、時間のかかる操作です。実行時間は、次の 2 つの要因によって異なります:
データベース内のオブジェクトの数。データベースに多数のオブジェクトが含まれている場合、切り替えは遅くなります。
切り替え中のデータベースに対する DML の負荷。DML の負荷が高い場合、切り替えは遅くなります。
データオブジェクト分離レベルからデータベース分離レベルへの切り替え
データベースの分離の粒度をデータオブジェクトレベルに変更した後、管理を容易にするためにデータベース分離レベルに戻すことができます。これを行うには、次の文を使用します:
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;この文では、name はデータベースの名前、master_id はデータベースのエンドポイントです。
例: データベース db1 の分離レベルをデータオブジェクトレベルからデータベースレベルに変更し、エンドポイントを RW1 に設定します。
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;分離レベルの切り替えは、通常、時間のかかる操作です。実行時間は、次の 2 つの要因によって異なります:
データベース内のオブジェクトの数。データベースに多数のオブジェクトが含まれている場合、切り替えは遅くなります。
切り替え中のデータベースに対する DML の負荷。DML の負荷が高い場合、切り替えは遅くなります。
データオブジェクトのエンドポイントの切り替え
マルチマスタークラスターの分離レベルをデータオブジェクトレベルに変更すると、単一のデータベースに TABLE、VIEW、TRIGGER、FUNCTION、PROCEDURE、EVENT などの複数のオブジェクトタイプを含めることができます。これらのオブジェクトのエンドポイントを切り替えるには、次の文を使用します:
ALTER obj_type name POLARDB_WRITE_NODE master_id;obj_type の有効な値は、TABLE、VIEW、TRIGGER、FUNCTION、PROCEDURE、および EVENT です。name はデータオブジェクトの名前です。
例 1: データベース db1 の t1 テーブルのエンドポイントを RW3 に切り替えます。
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;例 2: 現在のデータベースの t2 VIEW のエンドポイントを RW2 に切り替えます。
ALTER VIEW t2 POLARDB_WRITE_NODE 2;例 3: データベース db2 の関数 f1 と関数 f2 のエンドポイントを RW1 に切り替えます。
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;エンドポイントの切り替えは、通常、時間のかかる操作です。実行時間は、次の要因によって異なります:
切り替え中のデータオブジェクトに対する DML の負荷。DML の負荷が高い場合、切り替えは遅くなります。
オブジェクトは互いに関連付けることができます。関連付けられたオブジェクトのエンドポイントが同じ RW ノード上にない場合、オブジェクトは無効になる可能性があります。
たとえば、VIEW1 という名前のビューが t1 という名前のテーブルに依存しているとします。VIEW1 のエンドポイントが RW1 にあり、t1 のエンドポイントが RW2 にある場合、RW1 で VIEW1 にアクセスしようとするとエラーが発生します。同様に、FUNCTION、PROCEDURE、または EVENT によって参照されるオブジェクトに正しいエンドポイントがない場合、それらの実行は失敗します。TRIGGER とそれに関連付けられた TABLE のエンドポイントが同じノードにない場合、TABLE 内のデータを変更することはできません。
テーブル t1 とテーブル t2 の間に外部キー制約が存在する場合、一方のテーブルのエンドポイントを変更すると、もう一方のテーブルのエンドポイントも自動的に変更されます。
SQL 文の RW ノードを指定する
この機能は、information_schema やステータス変数をクエリする文など、データクエリ以外の文にのみ適用されます。SELECT * FROM table1 などの文を使用してデータをクエリする場合、RW ノードを指定する必要はありません。データベースプロキシは、クエリを実行する正しい RW ノードを自動的に選択します。
SQL 文を特定の RW ノードに送信するには、次の SQL 文を実行して RW ノードをロックします:
ALTER SESSION POLARDB_WRITE_NODE master_id;例: RW1 ノードで innodb_buffer_pool_size 変数の値をクエリします。
ALTER SESSION POLARDB_WRITE_NODE 1; # SQL 文を RW1 ノードに送信します。
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # RW1 ノードで innodb_buffer_pool_size の値をクエリします。SQL 文を実行するときに RW ノードを指定しない場合、データベースプロキシは文を実行する RW ノードをランダムに選択します。
次のコマンドを実行して、SQL 文を実行するために指定された RW ノードのロックを解除できます:
RESET SESSION POLARDB_WRITE_NODE;データベースの分散をクエリする
PolarDB コンソールの ページに移動して、クラスター内のすべてのデータベースの分散を表示できます。

次のコマンドを実行して、特定の RW ノード上のデータベースの分散をクエリできます:
ALTER SESSION POLARDB_WRITE_NODE master_id; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';例: RW1 ノード上のデータベースの分散をクエリします。
ALTER SESSION POLARDB_WRITE_NODE 1; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';クエリ結果は次のとおりです:
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | table_name | table_id | space_id | s_lock_count | lock_mode | object | current_lsn | hold_thread | hold_start_time | hold_total_time | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | test3/f1 | 9149389368458135753 | 0 | 0 | SLS_X | function | 28076635 | 17 | 2024-07-10 21:35:20 | 214 | | test3/e1 | 9149389368458332874 | 0 | 0 | SLS_X | event | 28077248 | 17 | 2024-07-10 21:35:30 | 204 | | test3/v1 | 9149389368457234649 | 0 | 0 | SLS_X | view | 28075972 | 17 | 2024-07-10 21:35:08 | 226 | | sbtest | 2107518311328629409 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-07 23:04:41 | 254053 | | test | 7190879906290573778 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:20:57 | 37077 | | test2 | 3381728963524265351 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:13:09 | 37545 | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ 6 rows in set (0.00 sec)列名は table_name ですが、クエリ結果の各行はデータベースまたはデータオブジェクトに関する情報を提供します。結果では、
sbtest、test、およびtest2はデータベース分離レベルを使用します。関数 test3.f1、イベント test3.e1、およびビュー test3.v1はデータオブジェクト分離レベルを使用します。オブジェクトタイプが Table の mysql/global_ddl_lock という名前のオブジェクトが表示されることもあります。これは無視できる内部情報です。次のコマンドを実行して、クラスター内のすべてのデータベースの分散をクエリできます:
説明このクエリは、特権アカウントを使用してのみ実行できます。新しく作成されたアカウントではこのクエリを実行できません。
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';クエリ結果は次のとおりです:
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | master_id | table_name | table_id | lock_mode | object | current_lsn | hold_start_time | hold_total_time | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | 1 | test3/v1 | 9149389368457234649 | SLS_X | view | 28075972 | 2024-07-10 21:35:08 | 754 | | 2 | test5/t1 | 9149389447232697561 | SLS_X | table | 7256175 | 2024-07-10 21:46:36 | 66 | | 1 | test2 | 3381728963524265351 | SLS_X | db | 28034927 | 2024-07-10 11:13:09 | 38073 | | 2 | test4 | 3381728963524272009 | SLS_X | db | 7255352 | 2024-07-10 21:46:27 | 75 | | 1 | test3/f1 | 9149389368458135753 | SLS_X | function | 28076635 | 2024-07-10 21:35:20 | 742 | | 1 | test3/e1 | 9149389368458332874 | SLS_X | event | 28077248 | 2024-07-10 21:35:30 | 732 | | 1 | test | 7190879906290573778 | SLS_X | db | 28034927 | 2024-07-10 11:20:57 | 37605 | | 2 | test5/p1 | 9149389447233473757 | SLS_X | procedure | 7257051 | 2024-07-10 21:46:45 | 57 | | 1 | sbtest | 2107518311328629409 | SLS_X | db | 28034927 | 2024-07-07 23:04:41 | 254581 | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ 9 rows in set (0.00 sec)列名は table_name ですが、クエリ結果の各行はデータベースまたはデータオブジェクトに関する情報を提供します。結果は、データベースまたはデータオブジェクトが存在する RW ノードを示します。オブジェクトタイプが Table の mysql/global_ddl_lock という名前のオブジェクトが表示されることもあります。これは無視できる内部情報です。
バイナリログの設定方法
マルチマスタークラスター (無制限) エディションは、MySQL バイナリログと完全に互換性があります。クラスター内のすべての RW ノードからの操作ログを統合して、グローバルに統一され、論理的に順序付けられたバイナリログを生成します。
loose_polar_log_bin パラメーターを設定して、マルチマスタークラスター (無制限) エディションのバイナリログ機能を有効にすることができます。また、binlog_expire_logs_seconds パラメーターを設定して、マルチマスタークラスター (無制限) エディションのバイナリログの保持期間を設定することもできます。詳細については、「バイナリログの有効化」をご参照ください。
マルチマスタークラスター (無制限) エディションのクラスターは、Data Transmission Service (DTS) のソースまたは宛先として使用して、一方向または双方向のデータ同期を実行できます。