プライマリノードとレプリカノードでデータベースの役割を入れ替える

Role reversalを使用することで、ユーザーは1つまたは複数のデータベースのレプリカとプライマリの役割を入れ替えることができる。

NPS がサポートする Role Reversal の基本バージョンは 11.2.1.11 です。

制限事項：Role Reversalは、NPSバージョン 11.2.1.12 より前のバージョンではRST（行保護テーブル）をサポートしていません。

役割の逆転が可能にすること

データベースのノードの役割反転を行う：
- いつでも
- 新しいプライマリでフルバックアップを取り、新しいレプリカにリストアする必要はない。
- レプリケーションのためにデータベースを再設定する必要はない。
読み取り/書き込みアプリケーションを、DR機能を維持したまま、以前レプリカの役割を担っていたシステムに移行する。
定期的にレプリカシステムのDR準備状況をテストする。

始める前に

ユーザーが役割の反転を開始する前に、プライマリ・レプリケーション・ノードとデータベースのレプリカ・レプリケーション・ノードの間で以下の条件が満たされていることを確認してください。

指定されたデータベースのすべてのメンバーノードは、アクティブな状態にあり、健全な状態で稼動していなければならない。
データベースのレプリカ・ノードにおける現在の適用シーケンスは、そのプライマリ・ノードにおける現在のキャプチャ・シーケンスと同じでなければならない。
注： apply seqが同じでない場合は、次のようにしてください：
1. 指定されたDBのレプリケーションを停止することで、ソースシステムでそのデータベースの新しいバックアップの生成を停止します。詳細については、指定したデータベースのレプリケーションの開始と停止を参照してください。
2. このデータベースのレプリケーション間隔を一時的に大幅に延長して、新しいバックアップの頻度を減らし、ターゲット・システムがバックログを処理するのに十分な時間を確保できるようにします。詳細については、 nzdrコマンドの nzdr update db 。
3. レプリカがプライマリーに追いつくのを待つ。
ユーザーは、レプリケーション・ノード間のデータ整合性を維持するために、現在のプライマリ・ノード上のデータベースに対してアクティブなトランザクションを中止する必要があります。役割の反転後、古いプライマリ上の読み取り/書き込みアプリケーションは、新しいプライマリノードに対して実行するように移動する必要がある。
役割を逆転させる前に、両方のシステムのセキュリティレベルが一致していることを確認してください。ソースシステム上のすべてのセキュリティ記述子が、ターゲットシステム上に存在しなければならない。 nzbackup -globals -dir コマンドを使用してグローバルのバックアップを取り、 nzrestore -globals -dir コマンドを使用してレプリカ・システムにリストアすることで、プライマリ・システムとレプリカ・システム間でセキュリティ情報やユーザ定義などのグローバルの同期を確実に取ることができます。
プライマリ Netezza Performance Server 管理ユーザーとしてプライマリ・システムに接続し、以下のクエリーを実行する：
```
update _t_backup_history set BATCHID=TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) where BATCHID='';
```
注：このクエリは、役割の逆転ごとに必ず実行してください。
いずれかのレプリケーション・ノード上の指定されたデータベースで初めてロール反転を実行する場合は、以下のクエリを実行してください：
- プライマリ・システムで、 _t_restore_history テーブルに対して select クエリを実行し、 0 を返すかどうかをチェックする。
```
$ nzsql <dbname> -c "select count(*) from _t_restore_history where TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) = <backupset> and type=6 and status =1"
```
- レプリカ・システム上で、 _t_backup_history テーブルに対して select クエリを実行し、 0 を返すかどうかをチェックする。
```
$ nzsql <dbname> -c "select count(*) from _t_backup_history where TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) = <backupset> and type=6 and status =1"
```
- プライマリ・システムで、 _t_object table を実行し、ゼロ以外を返すかどうかをチェックする。
```
$nzsql <dbname> -c "select count(*) from _t_object where objdb=current_db and RESTOREDOID != 0;"
```
  すべての条件が満たされている場合は、役割の反転を進める前に IBM サポートに連絡してください。
重要:
- これらのクエリは、NRSバージョン 3.0.4.0 未満の場合のみ適用されます。
- ロールリバーサルが実行されたら、データの破損を引き起こす可能性があるため、 backupsetid を使用して手動で増分バックアップを行わないようにしてください。
- nzbackup 、 nzrestore 、それぞれのデータベースの履歴に NRSREPL OpType 。
注： BACKUPSET の詳細を得るには、 nzdr list db を実行する。詳細については、レプリケーション・データベースの一覧を参照してください

手順

ノードのロールリバースが必要な各データベースについて、以下の手順を実行します。

注意: すべてのレプリケートされたデータベースが同じレプリケート・ノードを共有している場合、 nzdr change role コマンドで名前のリストを指定する代わりに、 --db-name オプションでキーワード ALL を使用することで、役割の反転プロセスを簡略化できます。

すべてのメンバーノードからデータベースのステータスを取得し、役割の逆転の前提条件を満たしていることを確認する。

nzdr status node
nzdr status db --db-name <DB1>,<DB2> --details

例:

[root@rajnrs11 ~]# nzdr status node 
+-------------+-------------+-------------+----------+
|   serial-no | node-name   | reachable   | health   |
+=============+=============+=============+==========+
|           1 | CPDS-A      | Yes         | Healthy  |
+-------------+-------------+-------------+----------+
|           2 | CPDS-B      | Yes         | Healthy  |
+-------------+-------------+-------------+----------+ 


[root@rajnrs11 ~]# nzdr status db --db-name UDB50,UDB49 --details
Databases -
1. UDB50
   Primary:
      Node: CPDS-B
      Last capture timestamp: Tue 03 Jun 2025 03:40 AM PDT
      Last capture seq no: 11
      Last pruned capture seq no: 10
      Last reported capture error: None
      Replication status: Active
   Replicas:
      Node: CPDS-A
      Last apply timestamp: Tue 03 Jun 2025 04:25 AM PDT
      Last apply seq no: 11
      Last pruned apply seq no: 11
      Last reported apply error: None
      Replication status: Active

2. UDB49
   Primary:
      Node: CPDS-B
      Last capture timestamp: Tue 03 Jun 2025 03:40 AM PDT
      Last capture seq no: 11
      Last pruned capture seq no: 10
      Last reported capture error: None
      Replication status: Active
   Replicas:
      Node: CPDS-A
      Last apply timestamp: Tue 03 Jun 2025 04:25 AM PDT
      Last apply seq no: 11
      Last pruned apply seq no: 11
      Last reported apply error: None
      Replication status: Active


Note: If node replication status is suspended then node replication status takes precedence over database replication status.

データベースの必要なレプリカ・ノード名を使用して、役割反転コマンドを開始します。

nzdr change role --db-name <DB1>,<DB2> --node-name <REPLICA NODE NAME> --role-type primary  --begin

すべての条件が満たされた場合、このコマンドは現在のプライマリでオンデマンドキャプチャジョブを開始する。

例:

[root@rajnrs11 ~]# nzdr change role --node-name CPDS-A --db-name UDB49,UDB50 --role-type  primary --begin 
Successfully started begin role reversal job with id 19 for the following databases: UDB49, UDB50.
You can monitor the status of this job via 
'nzdr job --node-name CPDS-B --job-id 19'
Monitor the status of these databases via command below.
'nzdr status db --details' command.
Once the Replication Status of these databases changes to 'Role Reversal (Pending)' on the Primary and Replica nodes,
you can then proceed with 'nzdr change role' command using the '--end' option to complete the change role process

プライマリのジョブステータスやデータベースのステータスをチェックすることで、役割逆転の開始フェーズの進捗状況を監視する。

nzdr job --node-name <PRIMARY NODE> --job-id <JOB ID>
nzdr status db --db-name <DB1>,<DB2> --details

ジョブ・ステータスが Completed 、データベースのレプリケーション・ステータスがすべてのノードで Active から Role Reversal (Pending) に変わるのを待つ。

例:

[root@rajnrs11 ~]# nzdr job --node-name CPDS-B --job-id 19
Job Id   : 19
Job Type : ROLE_BEGIN_JOB 

+-----------+------------------+--------------+-------------+
| db-name   |   capture-seq-no | job-status   | job-error   |
+===========+==================+==============+=============+
| UDB49     |               -1 | Running      |             |
+-----------+------------------+--------------+-------------+
| UDB50     |               -1 | Running      |             |
+-----------+------------------+--------------+-------------+ 

[root@rajnrs11 ~]# nzdr job --node-name CPDS-B --job-id 19
Job Id   : 19
Job Type : ROLE_BEGIN_JOB 

+-----------+------------------+--------------+-------------+
| db-name   |   capture-seq-no | job-status   | job-error   |
+===========+==================+==============+=============+
| UDB49     |               12 | Completed    |             |
+-----------+------------------+--------------+-------------+
| UDB50     |               12 | Completed    |             |
+-----------+------------------+--------------+-------------+

[root@rajnrs11 ~]# nzdr status db --db-name UDB50,UDB49 --details
Databases -
1. UDB50
   Primary:
      Node: CPDS-B
      Last capture timestamp: Tue 03 Jun 2025 05:43 AM PDT
      Last capture seq no: 12
      Last pruned capture seq no: 10
      Last reported capture error: None
      Replication status: Role Reversal (Pending)
   Replicas:
      Node: CPDS-A
      Last apply timestamp: Tue 03 Jun 2025 05:57 AM PDT
      Last apply seq no: 12
      Last pruned apply seq no: 11
      Last reported apply error: None
      Replication status: Role Reversal (Pending)

2. UDB49
   Primary:
      Node: CPDS-B
      Last capture timestamp: Tue 03 Jun 2025 05:43 AM PDT
      Last capture seq no: 12
      Last pruned capture seq no: 10
      Last reported capture error: None
      Replication status: Role Reversal (Pending)
   Replicas:
      Node: CPDS-A
      Last apply timestamp: Tue 03 Jun 2025 05:57 AM PDT
      Last apply seq no: 12
      Last pruned apply seq no: 11
      Last reported apply error: None
      Replication status: Role Reversal (Pending)


Note: If node replication status is suspended then node replication status takes precedence over database replication status.

必要なデータベースのロールリバーサルプロセスを完了する。すべてのノードのデータベースのレプリケーション・ステータスが Role Reversal (Pending) に変更されたら、以下のコマンドを実行して役割の反転処理を完了します。

nzdr change role --db-name <DB1>,<DB2> --node-name <REPLICA NODE NAME> --role-type primary  --end

例:


[root@rajnrs11 ~]# nzdr change role --node-name CPDS-A --db-name UDB49,UDB50 --role-type primary --end

Successfully started end role reversal job with id 50 for the following databases: 
UDB49, UDB50.

You can monitor the status of this job via the command below:
'nzdr job --node-name CPDS-A --job-id 50'

プライマリまたはデータベースのステータスでジョブのステータスをチェックすることにより、役割の逆転の最終段階の進捗状況を監視する。

nzdr job --node-name <PRIMARY NODE> --job-id <JOB ID>
nzdr status db --db-name <DB1>,<DB2> --details

を確認してください

Completed の状態。
プライマリとレプリカのセクションは、役割の変更を反映している。
データベースのレプリカのステータスが Active に変更されていることを確認してください。

例:


[root@rajnrs11 ~]# nzdr job --node-name CPDS-A --job-id 50
Job Id   : 50
Job Type : ROLE_END_JOB 

+---------+------------------+--------------+-----------+
| db-name | capture-seq-no   | job-status   | job-error|
+=========+==================+==============+===========+
| UDB49   | -1               | Completed    |           |
+---------+------------------+--------------+-----------+
| UDB50   | -1               | Completed    |           |
+---------+------------------+--------------+-----------+

[root@rajnrs11 ~]# nzdr status db --db-name UDB50,UDB49 --details
Databases -
1. UDB50
   Primary:
      Node: CPDS-A
      Last capture timestamp: Tue 03 Jun 2025 05:57 AM PDT
      Last capture seq no: 12
      Last pruned capture seq no: -1
      Last reported capture error: None
      Replication status: Active
   Replicas:
      Node: CPDS-B
      Last apply timestamp: Tue 03 Jun 2025 05:43 AM PDT
      Last apply seq no: 12
      Last pruned apply seq no: -1
      Last reported apply error: None
      Replication status: Active

2. UDB49
   Primary:
      Node: CPDS-A
      Last capture timestamp: Tue 03 Jun 2025 05:57 AM PDT
      Last capture seq no: 12
      Last pruned capture seq no: -1
      Last reported capture error: None
      Replication status: Active
   Replicas:
      Node: CPDS-B
      Last apply timestamp: Tue 03 Jun 2025 05:43 AM PDT
      Last apply seq no: 12
      Last pruned apply seq no: -1
      Last reported apply error: None
      Replication status: Active
Note: If node replication status is suspended then node replication status takes precedence over database replication status.