GoldenGate active-active entre regiões: defina quem é dono dos dados antes de resolver conflitos

A tese central é que active-active é, antes de tudo, um problema de propriedade de dados. Os handlers de conflito só limpam o que o modelo de ownership não evitou. O autor, que projetou replicação bidirecional com GoldenGate para propriedades de hotelaria, propõe classificar cada tabela em cinco classes: single-owner, escrowed, commutative, last-value e never multi-master. Só depois disso fazem sentido redo tags, particionamento de chaves, comparação de before-image e USEMAX ou USEDELTA.

Uma simulação com dois sites (40 quartos por execução, 500 execuções por configuração, 4.000 execuções no total) mostra três falhas. Com last-writer-wins, todas as execuções convergiram, mas houve atualizações perdidas, e a ferramenta de comparação veria tudo como saudável. Com clock skew, muda qual escrita vence, não quantas se perdem. Com delta resolution, nenhuma atualização se perde, mas ainda houve overselling (0,10 e 1,38 quartos por execução), porque os dois sites enxergaram o último quarto. O modelo omite partições, transações multilinha e triggers, então ilustra mecanismos, não comportamento de produção.

Em 26 de outubro de 2026, o CEVIU noticiou "Replication lag no Oracle GoldenGate: diagnóstico fila a fila ajuda a achar o gargalo". Aquele texto tratava o lag como problema de filas ao longo do pipeline. Esta matéria usa o mesmo lag por outro ângulo: ele é a janela de conflito. Segundo o autor, conflitos crescem com a latência, e reduzir o lag é trabalho de correção, não só de frescor dos dados.

Para quem opera GoldenGate bidirecional, a leitura é que a planilha de ownership por tabela deve ser revisada antes dos parâmetros. Um conflito em tabela single-owner deve soar como alarme de violação, não como ruído. Para contadores com piso, como estoque, o handler sozinho não basta: é preciso dono único ou cota em escrow, além de reconciliação contra registros de negócio, e não só comparação de linhas.