Oracle GoldenGate – MicroServices Architecture

Nesse post iremos falar sobre os pincipais componentes da arquitetura MicroServices, que surgiu na versão 12.3 e se tornará a única a partir do 23c.

Nessa nova arquitetura o GoldenGate passa a usar REST API que é usado para configuração, administração, tudo de forma remota view browser ou console.

Em um post anterir, foi visto como instalar o GoldenGate na arquitetura MicroService, e pode ser visto aqui. Após isso devemos fazer o deploy do GoldenGate, que é quando iremos utilizar todos os processos do mesmo. Diferente da Classic Architecture, onde a instalação já era o deploy. Na MicroServices, instalarmos uma vez, e podemos fazer vários deploys.

Na imagem abaixo temos os principais componentes da arquitetura MicroServices, ou apenas MA. Vamos falar um pouco sobre cada uma delas.

• Service Manager – É um watchdog para os serviços do GoldenGate. O Service Manager é que administra um ou mais deploys que existe na máquina. Ele pode ser comparado ao Manager da Classic Architecture.
• Administration Server – administra, supervisiona, gerencia e monitora todos os processos de um deploy, que pode ser extract, replicat, e etc. É ele que usamos para criar todos os processos.
• Receiver Server – é o serviço responsável por receber os trail files. É como se fosse o collector da arquitetura classic.
• Distribuition Server – Envia os trail files para o receiver server. É como se fosse o Data Pump da classic architecture.
• Performance Metrics Server – É um componente opcional, e precisamos ter o Oracle GoldenGate Management Pack Plug-in para utilizar. Coleta e armazena resultados de performance do ambiente.
• Admin Client – é como o ggsci da classic architecture. Aqui podemos usar a linha de comando para ser conectar ao GoldenGate, que pode estar remoto, e usar comandos para criar, monitorar e gerenciar serviços do GoldenGate, como extract, replicat e etc. O bom aqui é que os velhos comandos do ggsci continuam funcionando aqui.

Então, com dois deploys, um no source e um no target, para fazer a replicação de dados, teremos o extract salvando em um local trail file, o distribuition server enviando para o receiver server remoto que irá escrever no trail file, onde o replicat irá ler e aplicar. Esse fluxo esta na imagem abaixo:

Nada complicado. Vamos ver na prática nos próximos posts, como fazer um deploy e configurar todo o ambiente.