:使用方法

前提条件

• Multi-master Cluster (Limitless) クラスターを購入済みです。詳細については、「カスタム購入」および「サブスクリプションクラスターの購入」をご参照ください。

• 特権アカウントを作成済みである必要があります。詳細については、「特権アカウントの作成」をご参照ください。

• データベースクラスターに接続済みである必要があります。詳細については、「データベースクラスターへの接続」をご参照ください。

• PolarDB for MySQL のカーネルバージョン 8.0 以降は、Multi-master Cluster (Limitless) をサポートしています。

制限事項

• 各データベースまたはデータオブジェクトのデータは、単一のプライマリノードを介してのみ書き込むことができます。そのオブジェクトが割り当てられていないノードでは、書き込み操作を実行できません。デフォルトでは、操作はデータベースレベルで実行されます。データオブジェクトレベルで操作を実行するには、特定の構文を使用してモードを切り替える必要があります。

• プライマリノードをまたいだクエリはサポートされていません。クエリに異なるプライマリノード上にあるデータベースまたはデータオブジェクトが含まれる場合、システムはエラーを返します。クエリを実行する前に、関連するすべてのデータベースまたはデータオブジェクトのエンドポイントを単一のプライマリノードに移動することを推奨します。

• 提供されるのは、クラスターエンドポイントのみです。プライマリエンドポイントはサポートされていません。

• エンドポイントの切り替えは、次の条件に従います。

  • データベース分離レベルを使用する場合、データベースエンドポイントを切り替える必要があります。

  • データオブジェクト分離レベルを使用する場合、データオブジェクトのエンドポイントを切り替える必要があります。

• プライマリノードをまたいだ DDL 操作はサポートされていません。現在の接続が、データベースまたはデータオブジェクトの所有者ではないプライマリノード上にあるときに DDL ステートメントを実行すると、システムは Failed to get global lock for table 'xxx' on master N というエラーを返します。この問題を解決するには、次の手順を実行します。

  1. 次のコマンドを実行して、ターゲットテーブルを所有するプライマリノードを照会します。

     SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';

     クエリ結果で、ターゲットテーブルに対応する master_id を見つけます。

  2. 次のコマンドを実行して、現在のセッションをターゲットテーブルを所有するプライマリノードに切り替えます。

     ALTER SESSION POLARDB_WRITE_NODE <master_id>;

     <master_id> を、前の手順で取得した実際のプライマリノード番号に置き換えます。

  3. 切り替えが完了した後、DDL ステートメントを再実行します。

データベースのプライマリノードの指定

CREATE DATABASE name [POLARDB_WRITE_NODE master_id];

CREATE DATABASE db1 POLARDB_WRITE_NODE 1;

データベースの削除

DROP DATABASE name;

DROP DATABASE db1;

データベースエンドポイントの切り替え

ALTER DATABASE name POLARDB_WRITE_NODE master_id;

ALTER DATABASE db1 POLARDB_WRITE_NODE 2;

データオブジェクト分離への切り替え

ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;

ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;

データベース分離への切り替え

ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;

ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;

データオブジェクトエンドポイントの切り替え

ALTER obj_type name POLARDB_WRITE_NODE master_id;

ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;

ALTER VIEW t2 POLARDB_WRITE_NODE 2;

ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;

SQL のプライマリノードの指定

ALTER SESSION POLARDB_WRITE_NODE master_id;

ALTER SESSION POLARDB_WRITE_NODE 1;   # SQL ステートメントをプライマリノード 1 に送信します。
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';  # プライマリノード 1 の innodb_buffer_pool_size の値を照会します。

RESET SESSION POLARDB_WRITE_NODE;

データベースの分散の照会

• PolarDB コンソールで、設定と管理 > データベース管理 ページに移動して、クラスター全体でのすべてのデータベースの分散状況を確認できます。[MasterID] 列には、各データベースが属する RW ノード番号が表示されます (たとえば、MasterID 1 はデータベースが RW1 ノード上にあることを示し、MasterID 2 は RW2 ノード上にあることを示します)。

• 次のコマンドを実行して、特定のプライマリノード上のデータベースの分散を照会します。

  ALTER SESSION POLARDB_WRITE_NODE master_id;
  SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';

  例：プライマリノード 1 のデータベースの分散を照会します。

  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 (ビュー) はデータオブジェクト分離レベルを使用します。また、結果にはオブジェクトタイプがテーブルの 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 ですが、結果の各行にはデータベースまたはデータオブジェクトと、それに対応するプライマリノードに関する情報が含まれています。 結果には、オブジェクトタイプが table の mysql/global_ddl_lock という名前のオブジェクトが含まれる場合もあります。 これは内部で使用されるため、無視できます。

バイナリログの設定

マルチマスタークラスター (Limitless) は、MySQL バイナリログと完全に互換性があります。クラスター内のすべてのプライマリーノードから操作ログを統合し、グローバルに統一され、論理的に順序付けられたバイナリログを生成します。

loose_polar_log_bin を使用して マルチマスタークラスター (リミットレス)のバイナリログ機能を有効にし、binlog_expire_logs_seconds を使用して マルチマスタークラスター (リミットレス)のバイナリログの保持期間を設定できます。 詳細については、「バイナリログを有効にする」をご参照ください。