bi-directional replication, resync databases

[luc_vanderveurst]

Hello,

We have the following setup to replicate between dataservers srv_a and srv_b  (using repservers rep_a and rep_b) :

-) replication : srv_a   <--->   rep_a  <--->   rep_b   <----> srv_b

-) bidirectional-replication using msa : having database replication definitions and database subscriptions on both sites (i.e. in both directions)

-) used as active/passive system with srv_b being the active server.

srv_a is ASE 12.5.4 (solaris sparc/2K pages), srv_b is ASE 15.7 (solaris intel/4K pages).

I want to upgrade srv_a to ASE 15.7.

Here is what I did :

-) create a new 15.7 server, define the databases, load a dump of srv_b into it, disabled the replication agents.

-) drop database subscriptions in both directions.

-) stop srv_a, rename and restart the new sever iwth name srv_a.

for each database :

-) create a database subscription from b to a using dump marker

-) dump database on srv_b and load on srv_a.

the dump contains the replication configuration of srv_b, so this has to be changed in the settings of 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')

and in rssd_db of rep_a :

-) rs_zeroltm srv_a, $db

-) then start the repagent, and resume the connection.

-) finally, create a database subscription from a to b.

The result is that replication from b to a is working fine (which is good because that's from active to passive),

but replication from a to b isn't.

I used sysadmin dump_queue to see what 's in the stable queue, and it seems that transactions on srv_a don't make it to the stable queue.

When reading the documentation, I came across the description of generation numbers.

Normally it's increased to avoid that after restoring a primary database, transactions are considered

to be duplicates.

The Duplicates column in the output of admin who, sqm is increasing.

Since I couldn't find what was causing the problem, I thought of giving setting the generation number a try, and added :

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

after the settrunc('ltm', 'ignore') command in the description above.

When I did that, replication from srv_a to srv_b started to work.

I don't understand why this is happening, and why transactions are considered as duplicates.

I also want to avoid increasing the generation number, is there a solution without doing this ?

Thanks,

Luc.

[former_member350489]

Hi Luc !

We're using exactly the same MSA setup

We experienced exactly the same problem with generation id's here in the beginning, and it was a real pain !

But we descided in an early state, that in order to not having to bother us about them we remove "everything" related to that thread when we have to materialize and set up a database/thread from "scratch". In that way it will always start on gen_id 0

So we remove not only the subscriptions, but also all our rep_agents, descriptions, connections etc for each database/thread that we materialize

And since then, we don't have to worry anymore

/Mike

[luc_vanderveurst]

Thanks for your answers Mark and Mikael.

I have modified my scripts to get the current generation id from the gettrunc command and increase it by one, it's now part of the commands that adjust the repagent parameters after loading a database (like changing the name of the repserver that manages the repagent).

I've converted 4 servers with a total of 48 databases without further problems. 2 to go.

This weekend, i'm doing our main server with 54 replicated databases. To get the job done as fast as possible, I'll have to let it run unattended during the night, so I didn't want it to make more complicated by going as far as dropping the connections.

Luc.