PolarDB for MySQLマルチマスタークラスター (データベース /テーブル) クラスターは、複数のプライマリノードと読み取り専用ノードを含むマルチマスターアーキテクチャに基づいて開発されています。 クラスターの全体的な同時読み取りおよび書き込み機能を向上させるために、このアーキテクチャでは、異なる計算ノードからのデータベースまたはデータオブジェクトへの同時データ書き込みをサポートし、数秒以内にデータベースのプライマリノードを動的に切り替えることができます。 次のタイプのデータオブジェクトがサポートされています: テーブル、ビュー、トリガー、イベント、ストアドプロシージャ、および関数。 このトピックでは、マルチマスタークラスター (データベース /テーブル) クラスターの使用方法について説明します。
前提条件
マルチマスタークラスター (データベース /テーブル) クラスターが購入されました。 詳細については、「Enterprise Editionクラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。
特権アカウントが作成されます。 詳細については、「データベースアカウントの作成と管理」をご参照ください。
クラスターに接続しています。 詳細については、「クラスターへの接続」をご参照ください。
PolarDB for MySQL 8.0は、マルチマスタークラスター (データベース /テーブル) クラスターをサポートしています。
制限事項
各データベースまたはデータオブジェクトのデータは、1つのノードからのみ書き込むことができます。 データベースまたはデータオブジェクトが割り当てられているノードからのみ、データを読み書きできます。 デフォルトでは、操作はデータベースに基づいて実行されます。 データオブジェクトに対して操作を実行するには、対応するステートメントを実行する必要があります。
1つのプライマリノード内のデータのみをクエリできます。 SQL文を実行して、複数のプライマリノード上のデータベースまたはデータオブジェクトからデータを照会すると、システムはエラーを報告します。 データをクエリする前に、すべてのデータベースまたはデータオブジェクトのエンドポイントを1つのプライマリノードのエンドポイントに変更することを推奨します。
。 プライマリエンドポイントはサポートされていません。
分離レベルに基づいてデータベースエンドポイントを切り替えます。
データベース分離を使用する場合は、データベースのエンドポイントを切り替える必要があります。
データオブジェクトの分離を使用する場合は、データオブジェクトのエンドポイントを切り替える必要があります。
データベースを作成するときのプライマリノードの指定
次のステートメントを実行して、指定したプライマリノードにデータベースを作成できます。
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];データベース分離を使用する場合、各データベースのデータは1つのノードからのみ書き込むことができます。
上記のステートメントで
[POLARDB_WRITE_NODE master_id]を省略した場合、loose_innodb_mm_default_master_id値を参照して、データベースを作成できるプライマリノードを指定します。 loose_innodb_mm_default_master_idの値が0の場合、システムはプライマリノードをランダムに指定してデータベースを作成します。
例: RW1ノードにデータベースdb1を作成します。
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;上記のステートメントの1を2に変更して、RW2にデータベースdb1を作成します。
指定したプライマリノードのデータベースを削除する
次のステートメントを実行して、指定したプライマリノードのデータベースを削除できます。
DROP DATABASE name;例: RW1ノードで作成されたデータベースdb1を削除します。
DROP DATABASE db1;データベースを削除するときは、POLARDB_WRITE_NODEパラメーターを指定する必要はありません。
データベースエンドポイントの切り替え
次のステートメントを実行して、データベースのエンドポイントを別のプライマリノードに切り替えることができます。
ALTER DATABASE name POLARDB_WRITE_NODE master_id;例: データベースdb1のエンドポイントをRW2ノードに切り替えます。
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;ほとんどの場合、エンドポイントの切り替えには時間がかかります。 次の要因は、スイッチング操作の実行時間に影響します。
データベース内のテーブルの数。 数値が大きいほど、スイッチング速度は遅くなります。
切り替え中のデータベースのDMLステートメントのワークロード。 ワークロードが重いほど、スイッチング速度は遅くなります。
分離レベルをデータベースからデータオブジェクトに切り替える
デフォルトでは、マルチマスタークラスターではデータベース分離が使用されます。 この分離レベルを使用すると、データベース内のすべてのデータオブジェクトには、1つのプライマリノードでのみアクセスできます。 複数のプライマリノードからデータベース内のデータオブジェクトへのアクセスを許可するには、次のステートメントを実行して、分離レベルをデータベースからデータオブジェクトに変更します。
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;ほとんどの場合、分離レベルの切り替えには時間がかかります。 次の要因は、スイッチング操作の実行時間に影響します。
データベース内のデータオブジェクトの数。 数値が大きいほど、スイッチング速度は遅くなります。
切り替え中のデータベースの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;ほとんどの場合、分離レベルの切り替えには時間がかかります。 次の要因は、スイッチング操作の実行時間に影響します。
データベース内のデータオブジェクトの数。 数値が大きいほど、スイッチング速度は遅くなります。
切り替え中のデータベースのDMLステートメントのワークロード。 ワークロードが重いほど、スイッチング速度は遅くなります。
データオブジェクトのエンドポイントの切り替え
マルチプライマリクラスタの分離レベルがデータオブジェクトに切り替えられた後、データベースは、テーブル、ビュー、トリガ、関数、プロシージャ、およびイベントを含む複数のオブジェクトタイプを含むことができる。 次のステートメントを実行して、オブジェクトのエンドポイントを切り替えることができます。
ALTER obj_type name POLARDB_WRITE_NODE master_id;obj_typeの有効な値: TABLE、VIEW、TRIGGER、FUNCTION、PROCEDURE、およびEVENT。 nameはデータオブジェクトの名前です。
例1: データベースdb1のテーブルt1のendpintをRW3ノードに切り替えます。
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;例2: 現在のデータベースのビューt2のエンドポイントをRW2ノードに切り替えます。
ALTER VIEW t2 POLARDB_WRITE_NODE 2;例3: データベースdb2の関数f1と関数f2のエンドポイントをRW1ノードに切り替えます。
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;ほとんどの場合、エンドポイントの切り替えには時間がかかります。 次の要因は、スイッチング操作の実行時間に影響します。
切り替え中のデータオブジェクトのDMLステートメントのワークロード。 ワークロードが重いほど、スイッチング速度は遅くなります。
データオブジェクトは、互いに関連付けられ得る。 関連付けられたオブジェクトのエンドポイントが同じプライマリノード上にない場合、オブジェクトは無効である可能性があります。
たとえば、ビュー1はテーブルt1に依存しますが、ビュー1のエンドポイントはRW1ノードにあり、テーブルt1のエンドポイントはRW2ノードにあります。 RW1ノードでビュー1にアクセスすると、システムはエラーを報告します。 同様に、関数、プロシージャ、またはイベントタイプのデータオブジェクトによって参照されるオブジェクトのエンドポイントが正しく構成されていない場合、そのようなオブジェクトにアクセスすることはできません。 トリガーオブジェクトのエンドポイントと、トリガーオブジェクトが関連付けられているテーブルのエンドポイントが同じノードにない場合、テーブルオブジェクトをトリガーオブジェクトで更新することはできません。
テーブルt1とテーブルt2の間に外部キー制約が存在する場合、一方のテーブルのエンドポイントが変更されると、他方のテーブルのエンドポイントが自動的に変更されます。
SQL文を実行するプライマリノードを指定する
この機能は、information_schemaやstatus変数のクエリなど、データのクエリではないステートメントにのみ適用できます。 SELECT * FROM table1などのSQL文を使用してデータを照会する場合は、プライマリノードを指定する必要はありません。 データベースプロキシは、必要なプライマリノードを自動的に選択します。
次のステートメントを実行して、指定したプライマリノードにSQLステートメントを送信します。
ALTER SESSION POLARDB_WRITE_NODE master_id;例: RW1ノードのinnodb_buffer_pool_sizeの値を照会します。
ALTER SESSION POLARDB_WRITE_NODE 1; # Send the SQL statement to the RW1 node.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # Query the value of innodb_buffer_pool_size on the RW1 node.
SQL文の実行時にプライマリノードを指定しない場合、データベースプロキシはSQL文を実行するプライマリノードをランダムに選択します。
次の文を実行して, 指定したSQL文を実行するプライマリノードのロックを解除します。
RESET SESSION POLARDB_WRITE_NODE;ノードに関する情報の照会
次のステートメントを実行して、プライマリノードのデータベース分布を照会します。
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、およびview test3.v1は、データオブジェクトの分離を使用します。 さらに、mysql/global_ddl_lockという名前のテーブルオブジェクトが結果に含まれる場合があります。 この情報はMySQLの内部使用のためのものであり、無視することができます。次のステートメントを実行して、クラスター内のすべてのデータベースの分布を照会します。
説明データベース情報は、カスタムアカウントではなく、特権アカウントを使用してのみ照会できます。
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ですが、上記の結果の各行には、データベースまたはデータオブジェクトに関する情報が表示されます。これは、データベースまたはデータオブジェクトが対応するプライマリノードにあることを示しています。 さらに、mysql/global_ddl_lockという名前のテーブルオブジェクトが結果に含まれる場合があります。 この情報はMySQLの内部使用のためのものであり、無視することができます。
バイナリログの設定
マルチマスタークラスタ (データベース /テーブル) は、MySQLのバイナリロギング機能と完全に互換性があります。 このアーキテクチャは、クラスター内のすべてのプライマリノードの操作ログを統合して、グローバルに統合された論理バイナリログを生成します。
loose_polar_log_binパラメーターを設定して、マルチマスタークラスター (データベース /テーブル) のバイナリログ機能を有効にすることができます。 binlog_expire_logs_secondsパラメーターを設定して、マルチマスタークラスター (データベース /テーブル) のバイナリログの保存期間を設定できます。 詳細については、「バイナリログの有効化」をご参照ください。
マルチマスタークラスタ (データベース /テーブル) は、一方向または双方向のデータ同期のためのデータ転送サービス (DTS) のソースおよび宛先として使用できます。