Hola Jaime
En mis pruebas utilice tablas con y sin pk, es por eso que
vi la duplicación de datos y en la pk errores en log, te comento que
finalmente solucione el problema, era algo trivial como procedimiento
recree las subscripciones con copy_data en false,
que es lo que coincide con lo que me indicas, y así al momento de activar
la subs.. esta no hace la carga inicial, y empieza a replicar desde el
último punto, esto de postgresql en RDS es un poco extraño por decir, es
más, soporte de amazon RDS también
me recomendó lo mismo (usar el param copy_data en false) si que bueno, tema
solucionado. Muchas Gracias Jaime por tu respuesta.
Sldos.,
Fernando Monjes
El mié, 23 ago 2023 a las 10:30, Jaime Casanova (<
jcasa...@systemguards.com.ec>) escribió:
> On Wed, Aug 2, 2023 at 10:27 AM Fernando Monjes <ing.bo...@gmail.com>
> wrote:
> >
> > Buenas días comunidad
> >
> > Favor su ayuda con una situación de replicación que tengo, voy a
> explicar el contexto:
> >
> > Tengo que hacer upgrade de Postgresql en una plataforma aws rds
> postgresql de 13.10 a 15.2, este ambiente mantiene replicacion logica
> bidireccional con un ambiente on-premise postgresql 15.3, el procedimiento
> que utilice fue el siguiente para el upgrade en RDS:
> >
> > Procedimiento:
> >
> > 1.-Detener todas las Subscripciones de AWS y Onpremise
> > 2.-Eliminar todos los slots de las subscripciones
> > 3.-Crear el grupo de parámetro en RDS Amazon para la versión mayor y
> habilitar los siguientes parámetros
> > rds.logical_replication = 1
> > max_logical_replication_workers = 10
> > 4.- Generar Upgrade RDS AMAZON de version 13.10 a 15.2 (compatible
> según matriz)
> > 5.- Crear los slots de las subscripciones (eliminados en punto 2)
> > 6.- Activar las subscripciones de aws y onpremise y refrescar las
> publicaciones
> > 7.- Validar mediante select informacion de las tablas replicadas
> >
> > Al termino de este procedimiento las replicas que van de RDS a onpremise
> ningun problema pero las réplicas que van de onpremise a RDS se duplican
> los datos como si fuera una replica de cero , lo que me llama la atención
> es que en el origen (onpremise) se genera un slot SNAPSHOT
> >
> > log:
> > STATEMENT: CREATE_REPLICATION_SLOT
> "pg_16414_sync_16427_7262054625870888800" LOGICAL pgoutput (SNAPSHOT 'use')
> >
> > si lo consulto a la vista pg_replication_slots este slot
> (pg_16414_sync_16427_7262054625870888800) aparece en estado "false"
> >
> > No entiendo por que se genera ese nuevo slot y porque se me generar
> duplicidad de datos
> >
>
> Saludos,
>
> Espero que hayas podido solucionar este problema, pero si no has podido
> aún...
> El gran problema aquí es que estás usando RDS y eso parece tener una
> versión modificada, al menos rds.logical_replication no es un
> parámetro de postgres.
>
> - Puedes mostrar los comandos exactos que usaste en cada lado
> (editando IPs y otros datos sensibles claro)?
> - tienes PK en tus tablas? no deberían duplicarse los datos si
> tuvieras un PK, mas bien te daría un error de conflicto quizá.
>
> Ese slot adicional que ves lo usa para copiar los datos y es causado
> por que en el comando que usaste para crear la subscripción incluiste
> la opción copy_data en true.
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SYSTEMGUARDS - Consultores de PostgreSQL
>
--
Atentamente,
Fernando Monjes B.
Consultor DBA
Ingeniero en Informática
Cel: 09 -78521024
