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.

Limitazioni utility di migrazione

La utility di migrazione non può eseguire la migrazione di processi con le seguenti impostazioni:

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.

  1. 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 -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

    Le 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.

  2. 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:
  3. 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 yes per continuare.

  4. 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.
  5. 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.
  6. 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.
  7. 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 dirchk classica aggiungendo .migrated al 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 configuration e target configuration per 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.

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.