Vertauschen der Rolle von Datenbanken zwischen dem primären und dem Replikationsknoten

Durch die Verwendung der Rollenumkehr kann der Benutzer die Rolle eines Replikats und des Primärspeichers für eine oder mehrere Datenbanken tauschen.

Die von NPS unterstützte Basisversion für Role Reversal ist 11.2.1.11.
Einschränkung : Role Reversal unterstützt keine RST (Row secure table) für NPS-Versionen unter 11.2.1.12
Hinweis: Stellen Sie sicher, dass die NRS-Version auf beiden Systemen (Primär- und Replikatsystem) identisch ist, bevor Sie eine Rollenumkehr durchführen.
Der Rollentausch ermöglicht es:
  • Tauschen Sie die Rollen der Knoten von Datenbanken:
    • senden.
    • ohne dass eine vollständige Sicherung auf dem neuen primären Rechner und eine Wiederherstellung auf einem neuen Replikat erforderlich ist.
    • ohne die Notwendigkeit, die Datenbanken für die Replikation neu zu konfigurieren.
  • Migrieren Sie ihre Lese-/Schreibanwendungen auf die Systeme, die zuvor in der Replikationsrolle waren, wobei die DR-Fähigkeit erhalten bleibt.
  • Testen Sie regelmäßig die Bereitschaft der Replikationssysteme auf ihre DR-Fähigkeit.

Vorbereitende Schritte

Bevor der Benutzer den Rollentausch initiieren kann, stellen Sie sicher, dass die folgenden Bedingungen zwischen dem primären Replikationsknoten und den Replikationsknoten der Datenbanken erfüllt sind.

  1. Alle Mitgliedsknoten der gegebenen Datenbanken sollten sich im aktiven Zustand befinden und in einem gesunden Zustand laufen.
  2. Die aktuelle Anwendungsreihenfolge auf dem Replikationsknoten der Datenbanken sollte mit der aktuellen Erfassungsreihenfolge auf dem Primärknoten übereinstimmen.
    Hinweis: Wenn die Anwendungsreihenfolge nicht gleich ist, gehen Sie wie folgt vor:
    1. Stoppen Sie die Erstellung neuer Backups für diese Datenbank im Quellsystem, indem Sie die Replikation für die gegebene DB stoppen. Weitere Informationen finden Sie unter Starten und Beenden der Replikation für eine bestimmte Datenbank.
    2. Verlängern Sie das Replikationsintervall für diese Datenbank vorübergehend erheblich, um die Häufigkeit neuer Sicherungen zu verringern und dem Zielsystem ausreichend Zeit zu geben, den Rückstand abzuarbeiten. Weitere Informationen finden Sie nzdr update db unter im Befehl nzdr.
    3. Warten Sie darauf, dass die Replik die Primärdaten einholt.
  3. Der Benutzer muss aktive Transaktionen gegen die Datenbanken auf dem aktuellen primären Knoten abbrechen, um die Datenintegrität zwischen den Replikationsknoten zu wahren. Nach dem Rollentausch müssen alle Lese-/Schreibanwendungen auf dem alten primären Knoten verschoben werden, um auf dem neuen primären Knoten ausgeführt zu werden.
  4. Stellen Sie vor dem Rollentausch sicher, dass die Sicherheitsstufen auf beiden Systemen übereinstimmen. Alle Sicherheitsdeskriptoren auf dem Quellsystem müssen auf dem Zielsystem vorhanden sein. Sie können mit dem Befehl nzbackup -globals -dir ein globales Backup erstellen und es mit dem Befehl nzrestore -globals -dir auf den Replikationssystemen wiederherstellen, um sicherzustellen, dass globale Daten wie Sicherheitsinformationen und Benutzerdefinitionen zwischen Primär- und Replikationssystemen synchronisiert werden.
  5. Verbinden Sie sich mit dem primären Netezza Performance Server system als Admin-Benutzer und führen Sie die folgende Abfrage aus:
    update _t_backup_history set BATCHID=TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) where BATCHID='';
    Hinweis: Stellen Sie sicher, dass Sie diese Abfrage für jeden Rollentausch ausführen.
  6. Wenn Sie die Rollenumkehr zum ersten Mal für eine bestimmte Datenbank auf einem der Replikationsknoten durchführen, führen Sie die folgenden Abfragen aus:
    • Führen Sie auf dem Primärsystem die Abfrage select für die Tabelle _t_restore_history aus und prüfen Sie, ob sie 0 zurückgibt.
      $ nzsql <dbname> -c "select count(*) from _t_restore_history where TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) = <backupset> and type=6 and status =1"
    • Führen Sie auf dem Replikatsystem die Abfrage select für die Tabelle _t_backup_history aus und prüfen Sie, ob sie 0 zurückgibt.
      $ nzsql <dbname> -c "select count(*) from _t_backup_history where TO_CHAR(TIMESTAMP(BACKUPSET), 'YYYYMMDDHH24MISS' :: VARCHAR(16)) = <backupset> and type=6 and status =1"
    • Führen Sie auf dem Primärsystem _t_object table aus und prüfen Sie, ob der Wert ungleich Null ist.
      $nzsql <dbname> -c "select count(*) from _t_object where objdb=current_db and RESTOREDOID != 0;"

      Wenn alle Bedingungen erfüllt sind, wenden Sie sich an den IBM, bevor Sie mit dem Rollentausch fortfahren.

    WICHTIG:
    • Diese Abfragen gelten nur für NRS-Versionen unter 3.0.4.0
    • Sobald die Rollenumkehrung durchgeführt wurde, stellen Sie sicher, dass Sie die backupsetid nicht für manuelle inkrementelle Sicherungen verwenden, da dies zu Datenbeschädigungen führen kann.
    • Sie können NRSREPL OpType in der nzbackup und nzrestore Historie für die jeweilige Datenbank sehen, sobald der Rollentausch durchgeführt wurde.
    Hinweis: Um Details zu BACKUPSET zu erhalten, führen Sie nzdr list db aus. Weitere Informationen finden Sie unter Auflistung von Replikationsdatenbanken

Vorgehensweise

Führen Sie die folgenden Schritte für jede Datenbank aus, deren Knoten einen Rollentausch benötigen.
Hinweis: Wenn sich alle replizierten Datenbanken denselben Replikationsknoten teilen, können Sie den Prozess der Rollenumkehr vereinfachen, indem Sie das Schlüsselwort ALL mit der Option --db-name verwenden, anstatt die Liste der Namen im Befehl nzdr change role anzugeben.
  1. Holen Sie den Status der Datenbanken von allen Mitgliedsknoten und vergewissern Sie sich, dass sie die Voraussetzungen für die Rollenumkehr erfüllen.
    nzdr status node
nzdr status db --db-name <DB1>,<DB2> --details
    Beispiel:
    [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.
  2. Starten Sie den Befehl zur Rollenumkehr, indem Sie den gewünschten Replikationsknotennamen der Datenbanken verwenden.
    nzdr change role --db-name <DB1>,<DB2> --node-name <REPLICA NODE NAME> --role-type primary  --begin

    Wenn alle Bedingungen erfüllt sind, startet dieser Befehl einen On-Demand-Erfassungsauftrag auf der aktuellen Primärdatei.

    Beispiel:
    [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
  3. Überwachen Sie den Fortschritt der Anfangsphase des Rollentauschs, indem Sie den Auftragsstatus an der Primärstelle sowie den Status der Datenbanken überprüfen.
    nzdr job --node-name <PRIMARY NODE> --job-id <JOB ID>
nzdr status db --db-name <DB1>,<DB2> --details

    Warten Sie, bis der Status des Auftrags auf Completed und der Replikationsstatus der Datenbank auf allen Knoten von Active auf Role Reversal (Pending) wechselt.

    Beispiel:
    [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.
  4. Schließen Sie den Prozess der Rollenumkehr für die erforderlichen Datenbanken ab. Wenn sich der Replikationsstatus der Datenbanken auf allen Knoten zu Role Reversal (Pending) ändert, geben Sie den folgenden Befehl ein, um den Rollentauschvorgang abzuschließen.
    nzdr change role --db-name <DB1>,<DB2> --node-name <REPLICA NODE NAME> --role-type primary  --end
    Beispiel:
    
[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'
  5. Überwachen Sie den Fortschritt der Endphase des Rollentauschs, indem Sie den Jobstatus in der Primärdatenbank oder den Status der Datenbanken überprüfen.
    nzdr job --node-name <PRIMARY NODE> --job-id <JOB ID>
nzdr status db --db-name <DB1>,<DB2> --details
    Stellen Sie sicher, dass die
    • Status der Stelle in Completed state.
    • Der Abschnitt Primäre und Replik spiegelt den Rollenwechsel wider.
    • Stellen Sie sicher, dass der Replikationsstatus der Datenbank auf Active geändert wird.
    Beispiel:
    
[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.