Eseguire la migrazione dall'architettura classica a quella dei microservizi utilizzando la utility di migrazione
La utility di migrazione da Oracle GoldenGate Classic a Microservices viene utilizzata per eseguire la migrazione da un'installazione dell'architettura classica di Oracle GoldenGate a una distribuzione di microservizi. Questa utility è una utility interattiva che esegue la migrazione di estrazioni e repliche da un'installazione di architettura classica alla distribuzione di microservizi e converte le estrazioni pompa in un percorso di distribuzione. Esegue inoltre la migrazione di file trail, checkpoint e altri artifact associati.
La utility di migrazione è disponibile nel portale My Oracle Support (MOS) come Patch 37274898.
Gli aggiornamenti alla patch vengono rilasciati quando necessario. La descrizione della patch include dettagli con il numero di build più recente.
Prerequisiti per l'utilizzo della utility di migrazione
Di seguito sono riportati i prerequisiti per l'utilizzo della utility di migrazione.
-
Oracle GoldenGate 19c e versioni successive con patch di bundle 200714 o versioni successive. Questa è la versione minima dell'installazione dell'architettura classica di origine.
Nota: la utility di migrazione può essere utilizzata anche con Oracle GoldenGate 21c, se il database o il sistema di base supporta già l'architettura dei microservizi Oracle GoldenGate nella versione precedente, ad esempio Oracle GoldenGate per DAA. Se il database di base non supporta l'architettura dei microservizi, puoi utilizzare Oracle GoldenGate 26ai per database eterogenei.
-
JRE Java versione 1.8 o successiva (come fornito da Oracle GoldenGate).
-
Le nuove distribuzioni create utilizzando Microservices Architecture devono essere locali per l'installazione di Classic Architecture oppure il file system home di Classic Architecture deve essere disponibile sullo stesso host.
-
Nuova distribuzione dell'architettura dei microservizi creata e tutti i servizi in esecuzione.
-
L'installazione di Classic Architecture deve essere interrotta durante la migrazione. Assicurarsi che anche gli eventuali raccoglitori del server siano arrestati. I processi interrotti devono essere riavviati e chiusi in modo graduale.
-
La utility di migrazione deve essere eseguita da un prompt shell/comando in cui le variabili ambientali sono impostate per la distribuzione dell'architettura dei microservizi.
Le variabili di ambiente per
OGG_HOMEdevono essere impostate sulla posizione della directory software dei microservizi Oracle GoldenGate.In Microsoft Windows, la variabile
PATHdeve puntare aOGG_HOME\lib.Sulle piattaforme UNIX e Linux,
LD_LIBRARY_PATHdeve puntare aOGG_HOME/lib.
Limitazioni utility di migrazione
La utility di migrazione non può eseguire la migrazione di processi con le seguenti impostazioni:
-
Processi Pump Extract che eseguono trasformazioni o hanno un
DBLOGIN. -
Classic Extract (non più valido in Oracle GoldenGate 19c e non più supportato nella versione 21c per qualsiasi MA di destinazione maggiore della 19.1.)
-
Processi che utilizzano i seguenti parametri:
-
MACRO -
OBEY -
MACROCHAR
-
-
Utilizzo di file trail remoti, task remoti o caricamento iniziale.
-
Nomi di percorso assoluti per i file trail. Il file trail classico DEVE risiedere in
./dirdat(o in una sottodirectory al suo interno). Se il file trail si trova in un'altra directory, può essere spostato in./dirdate quindi modificare il checkpoint utilizzando l'utilityconvchkper Extract. Modificare quindi il parametro per qualsiasi Replicat interessato. Vedere convchk nel documento Parameters and Functions Reference for Oracle GoldenGate per Oracle GoldenGate 26ai. -
INCLUDERE le limitazioni:
-
INCLUDE Nidificate
-
Solo in Extract e Replicats, non in Extract Pump.
-
-
Oracle GoldenGate for DAA (Only): per ogni gruppo Extract e Replicat, è necessario ispezionare manualmente il file
.propertiescorrispondente per individuare le proprietà il cui valore fa riferimento a un file nel file system Classic. Per ciascuna di queste proprietà, effettuare le operazioni di migrazione manuale riportate di seguito.-
Copiare il file di riferimento nel file system di distribuzione dei microservizi.
-
Modificare il valore della proprietà per fare riferimento al nuovo percorso del file nel file system di distribuzione dei microservizi.
-
Eseguire la utility di migrazione
Assicurarsi di aver completato i passi indicati in Prerequisiti per l'utilizzo della utility di migrazione prima di iniziare i task in questa sezione.
Per eseguire la utility di migrazione, attenersi alla procedura riportata di seguito nel prompt dei comandi.
-
Eseguire il comando seguente per avviare la utility di migrazione:
java -jar ogg-migration-package-23.4.0.0.0.jar -classicHome /scratch/ogg/home -dryrunjava -jar ogg-migration-package-23.4.0.0.0.jar -debugjava -jar ogg-migration-package-23.4.0.0.0.jar -helpLe opzioni disponibili con questo comando sono:
-
-classicHome path: (Obbligatorio) deve puntare alla posizione della directory del software Oracle GoldenGate Classic. -
-dryrun: (facoltativo) indica che la migrazione viene simulata (Fai un'esecuzione manuale) per verificare la presenza di possibili problemi. -
-debug: questa opzione è facoltativa, ma si consiglia di utilizzare questa opzione con la utility. Abilita la registrazione e la diagnostica del livello di debug. Fornisce dati di log più dettagliati e produrrà un file zip con artifact sia dal classico che dal MA quando una migrazione non riesce. -
-skipPumpURI: specifica Accetta URI predefinito in Migrazione pompa -
-dbtype: specifica il nome del database. I valori validi sono 'ORACLE', 'MYSQL', 'MSSQL', 'POSTGRESQL', 'SYBASE', 'DB2400', 'DB2ZOS', 'DB2LUW', 'TERADATA', 'TIMESTEN' -
-help: mostra l'uso.
-
-
La utility richiede le credenziali utente per il Service Manager della distribuzione MA:
*************************************************************************** ** 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: -
La utility esegue la scansione di un Service Manager sull'host e fornisce una scelta di distribuzioni a cui eseguire la migrazione se sono presenti più distribuzioni, quindi richiede di continuare.
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):>Immettere
yesper continuare. -
La utility eseguirà la migrazione delle credenziali del database dalla distribuzione Classic alla distribuzione dei microservizi di destinazione, quindi copierà tutti i file trail nella distribuzione Classic ed eseguirà la migrazione di tutti i processi Estrazioni e Repliche.
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. -
La utility esegue quindi la migrazione di tutti i processi Extract Pump e richiede l'URL per il servizio ricevente di destinazione per ciascuno di essi. Per accettare il valore predefinito, premere Invio.
Se si utilizza una destinazione diversa, immettere l'URL. Per impostazione predefinita, l'utilità presume che la pompa classica stia inviando a un altro processo server di distribuzione classico. L'URL predefinito consente al servizio di distribuzione di collegarsi alla destinazione classica. Se si prevede anche di eseguire la migrazione della distribuzione classica di destinazione in un secondo momento, sarà necessario modificare contemporaneamente il percorso di distribuzione appena creato. Per informazioni dettagliate, vedere Casi d'uso diversi per la migrazione.
Nota: le pompe di loopback sono comuni in un ambiente di test in cui una pompa classica viene inviata allo stesso manager nella stessa distribuzione. Questa pompa di loopback viene instradata automaticamente al servizio ricevente nella distribuzione MA migrata.
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. -
Successivamente, l'utility chiede se deve migrare i parametri nel file di configurazione GLOBALS e segnalare eventuali problemi riscontrati.
Do you wish to migrate your GLOBALS parameters? (yes/no):> y GLOBAL parameters successfully migrated, 3 parameters merged. -
La utility richiede di copiare le voci del wallet esistenti se esistono e invia un'avvertenza se esistono voci nel wallet di destinazione. Queste voci del wallet di destinazione verranno sovrascritte. Al termine dell'attività, l'utility termina.
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.Se la migrazione è riuscita, i file di checkpoint verranno rinominati nella directory
dirchkclassica aggiungendo.migratedal nome. Ciò impedirà l'avvio involontario dei processi di distribuzione Classic.Se l'utility rileva un problema e non è in grado di completare il processo di migrazione, eseguirà un rollback di tutto il lavoro eseguito e ripristinerà lo stato originale della distribuzione classica. Produrrà un file zip di diagnostica contenente il file di log,
classic configurationetarget configurationper facilitare la diagnosi del problema.
Casi d'uso diversi per la migrazione
Le distribuzioni dell'architettura Oracle GoldenGate Classic in genere non sono autonome. Le distribuzioni in genere inviano dati trail ad altre distribuzioni utilizzando il processo Pump con topologie interconnesse molto complesse. Quando viene eseguita la migrazione di una distribuzione a microservizi, è comunque possibile che invii dati trail a un'altra distribuzione Classic o Microservizi. Una caratteristica importante di Microservices Architecture è la capacità di proteggere la distribuzione utilizzando protocolli di sicurezza consolidati come TLS/SSL e socket Web protetti.
Quando si esegue la migrazione delle distribuzioni, è necessario utilizzare un approccio ben ponderato. In genere, è preferibile eseguire la migrazione delle distribuzioni di origine e destinazione su base individuale e non tutte contemporaneamente. La utility di migrazione consente di eseguire la migrazione delle distribuzioni una alla volta. Poiché la distribuzione di origine utilizza un protocollo non protetto per comunicare con Classic Server/Collector o il servizio ricevente, il percorso di distribuzione di cui è stata eseguita la migrazione utilizzerà il protocollo precedente ogg nel percorso. Sebbene sia funzionale, non sfrutta le funzionalità di sicurezza dell'architettura dei microservizi per creare una distribuzione completamente sicura.
Si consiglia di sostituire il percorso di distribuzione generato dalla utility di migrazione con uno che utilizza i protocolli wss o ws dopo la migrazione di tutte le distribuzioni nell'architettura dei microservizi o ogni volta che viene eseguita la migrazione delle distribuzioni di origine e destinazione.
Per consentire la migrazione graduale di distribuzioni e processi all'architettura dei microservizi, è possibile eseguire la migrazione indipendente delle distribuzioni dell'architettura classica di origine e di destinazione.
Di seguito sono elencati i diversi casi d'uso e il protocollo di distribuzione associato utilizzato durante l'impostazione del percorso di distribuzione.
| Origine | Destinazione | Protocollo di distribuzione | Descrizione |
|---|---|---|---|
Architettura dell'hub (senza percorsi di distribuzione) Esegui migrazione da versione classica a microservizi |
Non applicabile | Non applicabile | Non applicabile |
| Esegui migrazione da versione classica a microservizi | Distribuzione classica | ogg protocollo per indirizzare la distribuzione classica | - |
| Esegui migrazione da versione classica a microservizi | Distribuzione microservizi | Protocollo ogg | Facoltativamente, eliminare e ricreare DISTPATH per utilizzare il protocollo ws o wss (se la destinazione è protetta con un proxy inverso) |
| Distribuzione classica | Esegui migrazione da versione classica a microservizi | Servizio ricevente da pompa a destinazione | La pompa di origine deve essere modificata: Porta servizio ricevente e trail remoto |
| Implementazione dei microservizi | Esegui migrazione a servizi classici e microservizi | Protocollo ogg | Eliminare e ricreare DISTPATH e utilizzare il protocollo ws o wss (se la destinazione è protetta con un proxy inverso) |
Migrazione dall'origine classica ai microservizi con target come microservizi
In questo caso d'uso, è possibile eliminare e ricreare il percorso di distribuzione per utilizzare il protocollo ws o wss (se la destinazione è protetta con un proxy inverso) specificando il numero di sequenza (seqno) e i valori RBA. Questa operazione è facoltativa poiché la distribuzione di destinazione utilizza l'architettura dei microservizi.
Eseguire il client di amministrazione e connettersi alla distribuzione di origine per ottenere i valori SEQNO e RBA:
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/
[...]
Convertire il percorso di distribuzione in protocollo ws o wss ricreando e riposizionando il percorso di distribuzione creato dalla utility di migrazione:
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
Esegui migrazione destinazione da servizi classici a microservizi con origine microservizi
In questo caso d'uso, è obbligatorio eliminare e ricreare il percorso di distribuzione per utilizzare il protocollo ws o wss, se la destinazione è protetta con un proxy inverso. Seguire la procedura descritta in Migrazione dell'origine da classica a microservizi con destinazione come microservizi per eliminare e ricreare il percorso di distribuzione nella distribuzione di destinazione.
Migrazione della destinazione da classica a microservizi con origine classica
Quando si esegue la migrazione della distribuzione di destinazione all'architettura dei microservizi mentre la distribuzione di origine si trova nell'architettura classica, è necessario eseguire i passi aggiuntivi riportati di seguito.
-
Modificare la porta pompa durante l'instradamento dell'origine al servizio ricevente di destinazione.
-
La directory
dirdatnon è necessaria nella gerarchia di file dei microservizi di destinazione. Modificare il fileRMTTRAILda./dirdat/raa./ranel file dei parametri di Extract Pump, come mostrato nell'esempio seguente:
Come mostrato nell'esempio riportato di seguito, il numero di porta del gestore target è stato modificato nel numero di porta del servizio ricevente 9903 e il percorso del file RMTTRAIL è stato modificato nel file dei parametri di Extract Pump.
GGSCI> STOP EXTRACT PMPW2E
GGSCI> EDIT PARAMS PMPW2E
Di seguito è riportato il file dei parametri di Extract Pump.
EXTRACT PMPW2E
USERIDALIAS ggeast,
target uri: host1:9903/services/v2/targets?trail=./bb? ENCRYPT AES192,
RMTTRAIL ./rt SEQUENCE hr.employees_seq; TABLE hr.*;
Riavviare Extract Pump dopo aver completato le modifiche:
GGSCI> START EXTRACT PMPW2E
Nota: nessun file trail viene consegnato alla destinazione.
Prima dell'inizio della migrazione, arrestare tutti i processi all'origine in modo esteso.