¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Actualización de ASE 15.7 en srv_a: Solución a transacciones duplicadas sin incrementar número de generación

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 15 Vistas
0
Cargando...

Hola,

Tenemos la siguiente configuración para replicar entre los servidores de datos srv_a y srv_b (usando los servidores de replicación rep_a y rep_b):

-) replicación: srv_a <---> rep_a <---> rep_b <----> srv_b

-) replicación bidireccional utilizando msa: con definiciones de replicación de base de datos y suscripciones de base de datos en ambos sitios (es decir, en ambas direcciones)

-) utilizado como sistema activo/pasivo con srv_b siendo el servidor activo.

srv_a es ASE 12.5.4 (solaris sparc/2K páginas), srv_b es ASE 15.7 (solaris intel/4K páginas).

Quiero actualizar srv_a a ASE 15.7.

Esto es lo que hice:

-) crear un nuevo servidor 15.7, definir las bases de datos, cargar un volcado de srv_b en él, deshabilitar los agentes de replicación.

-) eliminar las suscripciones de base de datos en ambas direcciones.

-) detener srv_a, renombrar y reiniciar el nuevo servidor con nombre srv_a.

para cada base de datos:

-) crear una suscripción de base de datos de b a a usando un marcador de volcado

-) volcar la base de datos en srv_b y cargar en srv_a.

el volcado contiene la configuración de replicación de srv_b, por lo que esto debe cambiarse en la configuración de srv_a:

-) sp_config_rep_agent $db, 'connect dataserver', 'srv_a'

-) sp_config_rep_agent $db, 'rs servername', 'rep_a'

-) dbcc settrunc('ltm', 'ignore')

-) dbcc settrunc('ltm', 'valid')

-) dbcc settrunc('ltm', 'end')

y en rssd_db de rep_a:

-) rs_zeroltm srv_a, $db

-) luego iniciar el repagent y reanudar la conexión.

-) finalmente, crear una suscripción de base de datos de a a b.

El resultado es que la replicación de b a a funciona bien (lo cual es bueno porque es de activo a pasivo),

pero la replicación de a a b no lo hace.

Usé sysadmin dump_queue para ver qué hay en la cola estable, y parece que las transacciones en srv_a no llegan a la cola estable.

Al leer la documentación, me encontré con la descripción de los números de generación.

Normalmente se incrementan para evitar que después de restaurar una base de datos principal, las transacciones se consideren duplicadas.

La columna Duplicados en la salida de admin who, sqm está aumentando.

Como no pude encontrar qué estaba causando el problema, pensé en probar configurar el número de generación, y agregué:

-) dbcc settrunc('ltm', 'gen_id', 1)

después del comando settrunc('ltm', 'ignore') en la descripción anterior.

Cuando hice eso, la replicación de srv_a a srv_b comenzó a funcionar.

No entiendo por qué está sucediendo esto y por qué las transacciones se consideran duplicadas.

También quiero evitar aumentar el número de generación, ¿hay alguna solución sin hacer esto?

Gracias,

Luc.

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

2 Respuestas

0
Cargando...

Gracias por tus respuestas Mark y Mikael.

He modificado mis scripts para obtener el id de generación actual del comando gettrunc y aumentarlo en uno, ahora es parte de los comandos que ajustan los parámetros del repagent después de cargar una base de datos (como cambiar el nombre del repserver que gestiona el repagent).

He convertido 4 servidores con un total de 48 bases de datos sin problemas adicionales. Quedan 2 por hacer.

Este fin de semana, estoy trabajando en nuestro servidor principal con 54 bases de datos replicadas. Para terminar el trabajo lo más rápido posible, tendré que dejarlo funcionando sin supervisión durante la noche, por lo que no quería complicarlo más yendo tan lejos como para desconectar las conexiones.

Luc.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...


¡Hola Luc!

Estamos utilizando exactamente la misma configuración de MSA.

¡Experimentamos exactamente el mismo problema con las IDs de generación aquí al principio, y fue realmente un dolor!

Pero decidimos en una etapa temprana que, para no tener que preocuparnos por ellos, eliminamos "todo" lo relacionado con ese hilo cuando tenemos que materializar y configurar una base de datos/hilo desde "cero". De esa manera siempre comenzará en gen_id 0.

Por lo tanto, no solo eliminamos las suscripciones, sino también todos nuestros rep_agents, descripciones, conexiones, etc. para cada base de datos/hilo que materializamos.

Y desde entonces, ya no tenemos que preocuparnos.

/Mike

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?