Mit dem Migrationsutility von einer klassischen zu einer Microservices-Architektur migrieren

Mit dem Migrationsutility von Oracle GoldenGate Classic zu Microservices wird eine Migration von einer Oracle GoldenGate Classic-Architekturinstallation zu einem Microservices-Deployment durchgeführt. Dieses Utility ist ein interaktives Utility, mit dem Extracts, Replicats von einer Classic Architecture-Installation in das Microservices-Deployment migriert und Pump Extracts in einen Verteilungspfad konvertiert werden. Außerdem werden Traildateien, Checkpoints und andere zugehörige Artefakte migriert.

Das Migrationsutility ist im My Oracle Support-(MOS-)Portal als Patch 37274898 verfügbar.

Updates für den Patch werden bei Bedarf freigegeben. Die Patchbeschreibung enthält Details mit der neuesten Build-Nummer.

Voraussetzungen für die Verwendung des Migrationsutilitys

Folgende Voraussetzungen sind für die Verwendung des Migrationsutilitys erforderlich:

Einschränkungen des Migrationsutilitys

Das Migrationsutility kann keine Prozesse mit den folgenden Einstellungen migrieren:

Migrationsutility ausführen

Stellen Sie sicher, dass Sie die unter Voraussetzungen für die Verwendung des Migrationsutilitys genannten Schritte ausgeführt haben, bevor Sie mit den Aufgaben in diesem Abschnitt beginnen.

Führen Sie in der Eingabeaufforderung die folgenden Schritte aus, um das Migrationsutility auszuführen:

  1. Führen Sie den folgenden Befehl zum Starten des Migrations-Utilitys aus:

    java -jar ogg-migration-package-23.4.0.0.0.jar -classicHome /scratch/ogg/home -dryrun
    java -jar ogg-migration-package-23.4.0.0.0.jar -debug
    java -jar ogg-migration-package-23.4.0.0.0.jar -help

    Folgende Optionen stehen mit diesem Befehl zur Verfügung:

    • -classicHome path: (Erforderlich) Muss auf den Speicherort des Oracle GoldenGate Classic-Softwareverzeichnisses verweisen.

    • -dryrun: (Optional) Gibt an, dass die Migration simuliert wird (Probelauf ausführen), um mögliche Probleme zu prüfen.

    • -debug: Diese Option ist optional, es wird jedoch empfohlen, diese Option mit dem Utility zu verwenden. Aktiviert Logging und Diagnose auf Debug-Ebene. Es stellt detailliertere Logdaten bereit und erstellt eine ZIP-Datei mit Artefakten aus dem Klassiker und MA, wenn eine Migration fehlschlägt.

    • -skipPumpURI: Gibt die Standard-URI bei Pumpmigration akzeptieren an

    • -dbtype: Gibt den Datenbanknamen an. Gültige Werte sind 'ORACLE', 'MYSQL', 'MSSQL', 'POSTGRESQL', 'SYBASE', 'DB2400', 'DB2ZOS', 'DB2LUW', 'TERADATA', 'TIMESTEN'

    • -help: Zeigt die Verwendung an.

  2. Das Utility fordert zur Eingabe der Benutzerzugangsdaten für den Service Manager des MA-Deployments auf:

    ***************************************************************************

**      Oracle GoldenGate Classic to Microservices Migration Utility              **

**        Version 23.4.0.0.0 Build 66 at Fri Jan 22 17:24:41 UTC 2024             **

**  Copyright (C) 1995, 2024, Oracle and/or its affiliates. All rights reserved.  **

**                                                                             **

**         Operating system character set identified as UTF-8.                    **

*******************************************************************************

Command Entered: -classicHome /ogg/payroll -debug
Log File for this session is /ogg/payroll/./Migration081321105419.log. Debug Mode is Enabled.
Enter Service Manager Credentials: User Id: dba
Password:

  3. Das Utility scannt nach einem Service Manager auf dem Host und bietet eine Auswahl an Deployments, in die migriert werden soll, wenn mehrere Deployments vorhanden sind. Anschließend werden Sie aufgefordert, fortzufahren.

    Scanning for Microservices Deployments...
Using Deployment payroll [cf4c7c93-3a1c-4cbc-b1ab-bc942bab7645]
The following processes will be migrated to deployment payroll:
Extracts: EXTE
Replicats: REPW
Pumps: DPE
Do you wish to continue? (yes/no):>

    Geben Sie yes ein, um fortzufahren.

  4. Das Utility migriert die Datenbankzugangsdaten aus dem Classic-Deployment in das Ziel-Microservices-Deployment und kopiert dann alle Traildateien im Classic-Deployment, und migriert alle Extracts- und Replicats-Prozesse.

    Migrating Credentials from /ogg/payroll/./dircrd
Migrating Credentials for Domain Payroll with an alias of ogg.
Migrating Credentials for Domain Payroll with an alias of user.

Copying Trail Files from /ogg/payroll/dirdat to /ogg/Microservices/payroll/var/lib/data.
235 trail files copied.

Migrating EXTRACT EXTE to http://10.20.0.221:9901.
Checkpoint File(s) Copied and Converted Successfully.
Parameter File EXTE.prm Saved Successfully.
Migration of Extract EXTE Completed Successfully.

Migrating REPLICAT REPW to http://10.20.0.221:9901.
Parameter File REPW.prm Saved Successfully.
Checkpoint File(s) Copied and Converted Successfully.
Migration of Replicat REPW Completed Successfully.

  5. Das Utility migriert dann alle Extract Pump-Prozesse und fordert die URL für den jeweiligen Zielempfängerservice an. Drücken Sie die Eingabetaste, um den Standardwert zu übernehmen.

    Wenn Sie ein anderes Ziel verwenden, geben Sie die URL ein. Standardmäßig geht das Utility davon aus, dass die klassische Pumpe an einen anderen klassischen Deployment-Serverprozess gesendet wird. Mit der Standard-URL kann der Distributionsservice mit dem klassischen Ziel verknüpft werden. Wenn Sie auch planen, das klassische Ziel-Deployment zu einem späteren Zeitpunkt zu migrieren, müssen Sie den neu erstellten Verteilungspfad gleichzeitig ändern. Weitere Informationen finden Sie unter Verschiedene Anwendungsfälle für Migration.

    Hinweis: Die Loopback-Pumpen werden häufig in einer Testumgebung verwendet, in der eine klassische Pumpe an denselben Manager im selben Deployment gesendet wird. Diese Loopback-Pumpe wird beim migrierten MA-Deployment automatisch an den Empfangsservice weitergeleitet.

        Migrating PUMP PMPW2E to http://
10.20.0.221:9902.

    Use Default Pump Target URI of ogg://ushost1:9903/services/v2/targets?trail=./bb?
    Press Enter to Accept or type Alternate URI:>
    Creating Distribution Path for Pump PMPW2E.
    Distribution Path Created Successfully.
    Setting trail sequence to 235 with an RBA of 1319472691.

    Migration of Pump PMPW2E Completed Successfully.

    Migrating Manager tasks to http://10.20.0.221:9901.
    Creating Task for Parameter PurgeTrail-aa. Task Created Successfully.
    Creating Task for Parameter Purge-Extract. Task Created Successfully.
    2 Tasks were migrated, 2 Successfully, 0 with errors.

    Migrating Lag Report.
    Creating Task for Parameter LagReport. Task Created Successfully.
    Migration pf Manager Tasks Completed Successfully.

  6. Als Nächstes fragt das Utility, ob es Parameter in der GLOBALS-Konfigurationsdatei migrieren und alle aufgetretenen Probleme melden soll.

    Do you wish to migrate your GLOBALS parameters? (yes/no):> y
GLOBAL parameters successfully migrated, 3 parameters merged.

  7. Das Utility fordert Sie auf, vorhandene Wallet-Einträge zu kopieren, falls sie vorhanden sind, und gibt eine Warnung aus, wenn Einträge im Ziel-Wallet vorhanden sind. Diese Ziel-Wallet-Einträge werden überschrieben. Nach Abschluss dieser Aufgabe wird das Utility beendet.

    Your Classic Deployment has existing wallet entries.
Do you wish to copy them? (yes/no):> y

Copying Oracle Wallet Entries.

WARNING: Target deployment has existing wallet entries and will be overwritten!

Do you wish to continue? (yes/no):> y
Wallet entries successfully copied.

Migration Processing Complete, 3 processes were migrated successfully.

    Wenn die Migration erfolgreich war, werden die Checkpoint-Dateien im klassischen Verzeichnis dirchk umbenannt, indem .migrated an den Namen angehängt wird. Dadurch wird verhindert, dass die Classic-Deployment-Prozesse versehentlich gestartet werden.

    Wenn das Utility auf ein Problem stößt und den Migrationsprozess nicht abschließen kann, führt es ein Rollback aller ausgeführten Arbeiten durch und stellt das klassische Deployment in den ursprünglichen Zustand zurück. Es wird eine Diagnose-ZIP-Datei mit der Logdatei classic configuration und target configuration erstellt, um das Problem zu diagnostizieren.

Verschiedene Anwendungsfälle für die Migration

Oracle GoldenGate Classic Architecture-Deployments sind in der Regel nicht eigenständig. Deployments senden Traildaten normalerweise mit dem Pump-Prozess an andere Deployments, die sehr komplexe miteinander verbundene Topologien aufweisen. Wenn ein Deployment zu Microservices migriert wird, sendet es möglicherweise weiterhin Traildaten an ein anderes Classic- oder Microservices-Deployment. Eine wichtige Funktion der Microservices-Architektur ist die Möglichkeit, das Deployment mit etablierten Sicherheitsprotokollen wie TLS/SSL und gesicherten Web-Sockets zu sichern.

Bei der Migration von Deployments sollte ein durchdachter Ansatz verwendet werden. Normalerweise wird es bevorzugt, dass Quell- und Ziel-Deployments einzeln migriert werden und nicht alle gleichzeitig. Mit dem Migrationsutility können Sie Deployments nacheinander migrieren. Da das Quell-Deployment ein nicht gesichertes Protokoll zur Kommunikation mit Classic Server/Collector oder dem Receiver-Service verwendet, verwendet der migrierte Verteilungspfad das Legacy-Protokoll ogg im Pfad. Dies wird zwar funktionsfähig sein, nutzt jedoch nicht die Sicherheitsfunktionen der Microservices-Architektur, um ein vollständig sicheres Deployment zu erstellen.

Es wird empfohlen, den vom Migrationsutility generierten Verteilungspfad durch einen mit den Protokollen wss oder ws zu ersetzen, nachdem alle Deployments zu Microservices Architecture migriert wurden oder wenn die Quell- und Ziel-Deployments migriert wurden.

Um eine schrittweise Migration von Deployments und Prozessen in die Microservices-Architektur zu ermöglichen, können Quell- und Ziel-Classic-Architektur-Deployments unabhängig migriert werden.

Im Folgenden werden verschiedene Anwendungsfälle und das zugehörige Verteilungsprotokoll aufgeführt, das beim Einrichten des Verteilungspfads verwendet wird.

Quelle Ziel Verteilungsprotokoll Beschreibung

Hubarchitektur (keine Verteilungswege)

Classic zu Microservices migrieren

 Nicht anwendbar Nicht anwendbar Nicht anwendbar
Classic zu Microservices migrieren Klassisches Deployment ogg-Protokoll für das klassische Deployment -
Classic zu Microservices migrieren Microservices-Deployment ogg-Protokoll Optional können Sie DISTPATH löschen und neu erstellen, um das ws- oder wss-Protokoll zu verwenden (wenn das Ziel mit einem Reverse Proxy gesichert ist).
Klassisches Deployment Classic zu Microservices migrieren Pumpe zum Zielempfängerdienst

Quellpumpe muss geändert werden:

Empfänger Service Port und Remote Trail
Microservices-Deployment Zu Classic zu Microservices migrieren ogg-Protokoll Löschen und erstellen Sie DISTPATH neu, und verwenden Sie das ws- oder wss-Protokoll (wenn das Ziel mit einem Reverse Proxy gesichert ist)

Migration der Quelle von Classic zu Microservices mit Target als Microservices

In diesem Anwendungsfall können Sie den Verteilungspfad löschen und neu erstellen, um das Protokoll ws oder wss zu verwenden (wenn das Ziel mit einem Reverse Proxy gesichert ist), indem Sie die Sequence-Nr. (seqno) und die RBA-Werte angeben. Dies ist optional, da das Ziel-Deployment die Microservices-Architektur verwendet.

Führen Sie den Admin-Client aus, und stellen Sie eine Verbindung zum Quell-Deployment her, um die SEQNO- und RBA-Werte abzurufen:

OGG (http://north:9001)> INFO DISTPATH dpe, DETAIL
Path Name: dpe Status: running
Source: trail://north:9002/services/v2/sources?trail=ea
Target: ogg://south:9003/services/v2/targets?trail=ra
Authentication Method: USERIDALIAS ggsca domain OracleGoldenGate
[...]
Checkpoints:
Input Checkpoint:
  Current:
     Name: ea
     Sequence: 14
     Offset: 2579
     Path: /u01/ogg_deployments/depl_north/var/lib/data/
[...]

Konvertieren Sie den Verteilungspfad in das ws- oder wss-Protokoll, indem Sie den Verteilungspfad, der vom Migrationsutility erstellt wurde, neu erstellen und positionieren:

OGG (http://south:9001)> DELETE DISTPATH dpe, DETAIL

## If using Secure Web Socket Protocol (wss)
OGG (http://south:9001)> ADD DISTPATH dpm
                         SOURCE trail://src_host:9002/services/v2/sources?trail=ea
                         TARGET wss://trg_host:9003/services/v2/targets?trail=ra
                         AUTHENTICATION CERTIFICATE default
## If using Web Socket Protocol (ws)
OGG (http://south:9001)> ADD DISTPATH dpm
                         SOURCE trail://src_host:9002/services/v2/sources?trail=ea
                         TARGET ws://trg_host:9003/services/v2/targets?trail=ra
                         AUTHENTICATION USERIDALIAS ggsca DOMAIN OracleGoldenGate
OGG (http://south:9001)> ALTER DISTPATH dpm, BEGIN SEQNO 14, RBA 2579
OGG (http://south:9001)> START DISTPATH dpm

Ziel von Classic zu Microservices migrieren, bei denen Source Microservices ist

In diesem Anwendungsfall ist es obligatorisch, den Verteilungspfad zu löschen und neu zu erstellen, um das ws- oder wss-Protokoll zu verwenden, wenn das Ziel mit einem Reverse Proxy gesichert ist. Befolgen Sie die Schritte unter Quelle von Classic zu Microservices mit Ziel als Microservices migrieren, um den Verteilungspfad im Ziel-Deployment zu löschen und neu zu erstellen.

Ziel von Classic zu Microservices mit Quelle als Classic migrieren

Wenn Sie das Ziel-Deployment zu Microservices Architecture migrieren, während sich das Quell-Deployment auf Classic Architecture befindet, müssen Sie die folgenden zusätzlichen Schritte ausführen:

Wie im folgenden Beispiel gezeigt, wurde die Portnummer des Zielmanagers in die Portnummer des Empfängerservice 9903 geändert, und der Dateipfad RMTTRAIL wurde in der Extract Pump-Parameterdatei geändert.

GGSCI> STOP EXTRACT PMPW2E
GGSCI> EDIT PARAMS PMPW2E

Die Parameterdatei Extract Pump lautet wie folgt:

EXTRACT PMPW2E
USERIDALIAS ggeast,
target uri: host1:9903/services/v2/targets?trail=./bb? ENCRYPT AES192,
RMTTRAIL ./rt SEQUENCE hr.employees_seq; TABLE hr.*;

Starten Sie Extract Pump neu, nachdem Sie die Änderungen abgeschlossen haben:

GGSCI> START EXTRACT PMPW2E

Hinweis: Dem Ziel werden keine Traildateien zugestellt.

Stoppen Sie vor Beginn der Migration alle Prozesse an der Quelle ordnungsgemäß.