Skip to Content
avatar image
Former Member

Replication server update

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?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Jun 22, 2017 at 12:06 AM

    NOTE: While there was a SRS version 15.7, it was quickly superseded by version 15.7.1 (and a slew of SP XXX releases since then); so I'm assuming you're planning to upgrade to SRS 15.7.1 SP XXX.

    --------------

    If you plan to upgrade your repserver(s) in place then you shouldn't need to reverse engineer anything. Having said that ...

    It's highly recommended that you backup your RSSDs prior to performing an upgrade ... and it wouldn't hurt to have a complete set of RCL (eg, repdefs, subs, function strings, etc) just in case you find yourself having to rebuild from scratch.

    Obviously if you plan to install a whole new SRS environment (as opposed to upgrading in place) then you'll need a complete set of your RCL scripts.

    I'm only aware of a few ways to reverse engineer your SRS environment ... a) PowerDesigner supposedly has a module that can reverse engineer a SRS environment [NOTE: I've never used PD for this purpose so I can't comment on its reverse engineering accuracy/completeness] ... b) roll your own code [you'll want to become intimately familiar with the RSSD/rs_help* stored procs as well as the structure of the RSSD/rs_* tables] ... or c) hire someone who's done #b.

    --------------

    If you have any routes between repservers then you'll need to be aware of an issue that (as far as I'm concerned) is not clearly documented ... an issue that I ran into at a client last year ...

    When upgrading routes between 15.0/15.0.1/15.1/15.2/15.5 repservers and 15.7.1 repservers ... or when creating/dropping routes between these two sets of versions ... spurious errors (some of which are not fixable) can arise due to issues with differences in the various RSSD schema versions, ie, there are some bugs in the repserver logic (invoked when upgrading/creating/dropping routes) that handles syncing the RSSDs.

    Per tech support the only workaround was to a) first upgrade all 15.0/15.0.1/15.1/15.2/15.5 repservers to 15.6 and b) then upgrade all repservers to 15.7.1; the gist of the workaround is that 15.6 is the only version capable of handling routes between all of the associated versions. When we implemented this workaround (using RS 15.6 ESD #3) at my client we found that the spurious route-related errors were eliminated.

    While the manuals suggest you can upgrade from 12.6 to 15.7.1; if you have any routes I'm guessing you could run into the same issues I ran into (last year at my client); if you have routes you may find that you need to perform an initial upgrade of all repservers from 12.6 to 15.6, then upgrade all repservers from 15.6 to 15.7.1. [I suggest you contact tech support if you have any questions/doubts.]

    Add comment
    10|10000 characters needed characters exceeded

    • 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)

  • Jul 19, 2017 at 03:50 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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.