OCI GoldenGate – primeiros passos

O OCI GoldenGate é a versão cloud do já conhecido GoldenGate, ele funciona na arquitetura de microserviços e uma de suas principais vantagens é cobrar pela quantidade de OCPU alocada para o deployment e não pela origem e destino, o serviço pode ser encontrado no menu de serviços -> Oracle Database -> Goldengate, ele é divido em 3 menus básicos: Deployments, Deployment Backups e Registered Databases.

Deployments

Aqui é o menu onde o serviço é criado:

Os pontos importantes são:

  • Quantidade minima/base de OCPU, cada OCPU entrega 16GB de RAM e 250GB de storage
  • Auto Scaling, caso você marque essa opção o serviço vai alocar até três vezes a quantidade inicial de CPU de acordo com a utilização.
  • Subnet, aqui é importante selecionar uma rede que tenha acesso tanto ao banco de origem quanto ao de destino.
  • Indo em Advanced, você tem a opção de criar um endpoint público e também criar um fqdn próprio

Na segunda tela, você pode especificar o nome do serviço, qual o nome do usuário administrador e também a sua senha

Após o serviço criado, você tem acesso aos detalhes dele:

No meu caso, esse é um deployment mais antigo e já podemos ver uma das vantagens do serviço que é a questão de upgrade de versão, como podem ver, assim que uma nova versão é lançada ele mostra um banner com a opção de em apenas um clique realizar o upgrade.

Nos botões temos acesso ao Edit, nele você pode alterar o nome do serviço e também ativar ou desativar o acesso público(você também precisa fazer as liberações direto na subnet ou no NSG do serviço).

No botão Scale você pode alterar a quantidade minima de OCPU e também ativar/desativar o Auto Scaling

Uma dica importante aqui é que qualquer alteração na quantidade minima vai fazer o serviço reiniciar!

Na parte de métricas temos alguns dados importantes para você saber se o sizing está correto e também acompanhar a saúde e performance do deployment, a dica aqui é criar alertas para que acompanhe de forma automatizada.

No menu Deployment backups você pode restaurar um backup ou criar um deployment novo a partir do backup.

Registrando um banco de dados

Agora que já vimos algumas opções do deploy, vamos passar pelo processo de registro dos bancos, aqui devem ser registrados tanto origem quanto destino, importante que o usuário que vai extrair/escrever os dados no banco já esteja criado.

Se o seu banco for um Autonomous, DBCS ou ExaCS você pode usar o próprio wizard para selecionar o banco e ele já carrega o IP, dns, etc, bastando você colocar o usuário e senha do banco, lembrando que para a parte de redes o deployment precisa ter acesso na rede do banco de dados.

Agora se o seu banco estiver fora do OCI ou você queira customizar alguma informação você pode usar a opção Enter Database Information.

Indo de forma manual você pode escolher se conectar diretamente no banco de dados ou através de um scan

No campo Database Node FQDN você pode colocar qualquer FQDN valido, não sendo necessário que ele seja uma entrada de DNS pública, esse FQDN vai ser inserido dentro do serviço e uma amarração vai ser feita com o IP que você vai entrar em Network Connectivity via private endpoint , então você pode usar por exemplo meudbcs.local, dbtnk.dbcs, etc.

No campo Database Connection String você precisa usar o mesmo FQDN e preencher com sua string de conexão, aqui você pode usar EZ connect ou a string completa.

Um ponto importante é marcar a opção Network Connectivity via private endpoint e selecionar uma subnet que possua acesso ao banco desejado e colocar o Database Node IP que é o IP do banco de dados, dessa forma a amarração entre o Database node FQDN e esse IP vai ser realizada.

Fazendo nossa primeira replicação

Essa vai ser a nossa arquitetura

No meu OCI Goldengate eu já tenho os dois bancos registrados:

E também já preparei os dois bancos com a seguinte configuração:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE FORCE LOGGING;
alter system set ENABLE_GOLDENGATE_REPLICATION=true scope=both sid='*';
Alter system set streams_pool_size=3g scope=both sid='*';

E criei o usuário de replicação dessa forma, lembrando que esse é um ambiente de teste e em um ambiente produtivo você deve ser mais restritivo.

create user C##GGADMIN identified by "SenhA#123_123#" ;
exec dbms_goldengate_auth.grant_admin_privilege('C##GGADMIN','*',container=>'ALL',grant_select_privileges=>true)
grant DBA to C##GGADMIN container=all;

No console do Goldengate -> Menu de hamburger -> Configuration eu consigo ver as credenciais

Aproveite para adicionar o Trandata, o trandata é necessário para que mais informações sejam capturadas e escritas pelo Goldengate, ele pode ser adicionado por schema ou por tabela a ser replicada, nesse caso vou colocar por schema

Note que ao fazer isso, ele já reconhece que possuo uma tabela no schema a ser replicado.

Criando o Extract

O Extract é o processo responsável pela extração dos dados e sua criação (geralmente) é bem simples:

Além de selecionar as credenciais registradas na console do OCI, outra parte importante aqui é marcar a opção Critical to Deployment health no menu Managed options, dessa forma além de o processo ser iniciado/reiniciado em caso de problemas, ele ainda gera um alerta no serviço do OCI que você pode criar um alarm para envio de notificações.

Deixei de propósito alguns parâmetros errados e ele notificou na console:

Esse é o meu “arquivo” de parâmetros corrigido:

EXTRACT ext_s
TRANLOGOPTIONS SOURCE_OS_TIMEZONE  GMT-3
ddl include mapped
USERIDALIAS dbsource DOMAIN OracleGoldenGate
EXTTRAIL so
table DBAMD_PDB1.source_tanaka.source;

Criando o replicat

Com o nosso processo no ar, já podemos criar o nosso replicat, ele vai ser o responsável pela escrita

Ele segue a mesma ideia do Extract, você seleciona a credencial do banco de destino, seleciona o trail que você mandou o Extract escrever(no meu caso ele se chama so) e você parametriza da forma que deseja que a escrita ocorra, aqui disse que tudo que for escrito vai ser mapeado para o schema DEST, da mesma forma caso ele tenha algum problema, o status do serviço na console é alterado e você pode interceptar essa mudança:

Após tudo corrigido, teremos tanto o extract quanto o replicat rodando

E um exemplo de sincronização ocorrendo

Também podemos acessar a guia de estatísticas (tanto do extract quanto do replicat) onde também temos os detalhes do que está acontecendo:

Ou pelo adminclient usando o cloud shell

chevron_left
chevron_right