Replication server update

[Former Member]

Greetings gurus

I am preparing a migration from a RS from version 12.6 to 15.7 with MSA and it has 60 subscriptions and replicas in many different paths.
Is there a way to get the T-SQL and RCL for inverse ingeriery for the definitions, subscriptions and connection configurations?
Is there any way to migrate the base to the new version or has to be done by hand?

[Former Member]

Thanks Mark, for your valuable comments

It is a new environment, and I will migrate too 4 ASEs and the RepServer. It is a MSA, so Se have no routes, only connections, and some bidirectional, I mean, dataserverA with a dabasbase a, replicate in DataserverB database a, and vice versa, DataserverB database a replicate in dataserverA dabasbase a. Fortunately the database are not big.

I ran RSSD/rs_help* stored procs, but i dont want to miss nothing.

Other issue is that I want to prevent data replications loops with the bidirectional replication.

And a last one: Which method of materialization do you recommend for bi-directional replication? I plan to stop all the activity of the primaries databases, copy them with a cross platform migration ( from Digital Tru64 to Linux) or with sybmigrate, and add the databases to the RS, create definitions and subscriptions, remove the secondary truncations points, do a rs_zeroltm and enable the secondary truncation points is both databases with dbcc settrunc (ltm,valid)

[sladebe]

Re: replicas in many different paths

What's a "path"? Are you using repserver routes?

So you're actually migrating to a new repserver, not upgrading an existing repserver. I actually think that's a safer way to go, although it's some extra work.

After you shutdown the old repserver, you'll have to stop the agents on the primary and then run "sp_config_rep_agent, <db>, disable" for primary and warm standby databases. Then you'll have to use rs_init to setup primary and warm standby databases, and connections to MSA replicate databases (database replication), Then use the normal create db rep def and create database subscription command (with no materialization) to re-setup replication.

Here are some Linux hacks to generate repserver create simple db repdef/db subscription commands (for simple cases, doesn't include all options) using the sqsh utility (version of isql upgraded to work in the modern world).

Create a create db repdef command:

> rs_helpdbrep mydb; | head -3 | tail -1 | awk '{print "create database replication definition",$1"rep"; print "with primary at",$2} $3="Yes" {print "replicate ddl"} '

output is:

create database replication definition mydbrep <br>with primary at my_logical_connection.mydb
replicate ddl

Create a create db subscription command:

> rs_helpdbsub my_db_sub; -mbcp | tail -3 | head -1 | awk -F'|' '{print "create subscription",$1; print "for database replication",$5; print "with primary at",$6;print "with replicate at",$2; print "without materialization"} $10=="Yes" {print "subscribe to truncate table"}' 

Creates the command:

create subscription my_db_sub for database replication mydbrep
with primary at my_logical_connection.mydb
with replicate at mydbserver.mydb
without materialization

Obviously, this is incredibly hackish, but works for simple cases.

[Former Member]

Thanks a lot, very usefull hacks

Maybe "path" it is not a good name; I will use MSA for the replica, with many replication-definitions - not path- and many of them with bidirectional replication

[sladebe]

Glad to hear my answer was useful. FYI, I made a minor fix to it. Also, remember to upvote the answer! 😉

Re: I will use MSA for the replica, with many replication-definitions

I assume you mean replication definitions which are not db replication definitions. Are they table specific repdefs? Function repdefs?

I thought the purpose of MSA was to make it easy to replicate the whole database so you don't need table specific repdefs. So I'm curious what kind of repdefs you're using.