Upgrading RSSD or ERSSD and User Databases with repserver

Use the repserver utility to upgrade the Replication Server RSSD or ERSSD, and user databases in one step.

  1. If the Replication Server uses Adaptive Server for the RSSD, grant sa_role to the primary user at the RSSD:
    sp_role 'grant', sa_role, primary_user
    You can revoke the “sa” role after the upgrade process is finished, by executing:
    sp_role 'revoke', sa_role, primary_user
    Note: The RSSD_primary_user in the .cfg file must have a replication role or “sa” role. The RSSD_primary_user may not necessarily be the sa user ID or the user that has been entered in the rs_init pane.
  2. Grant sa_role to the maintenance user for each user database.
  3. Shut down the preupgrade version of Replication Server.
    1. Use isql to log in to the Replication Server as the system administrator:
      isql -Usa -Psa _password - Srs_name
go
    2. Enter:
      shutdown
go
  4. Start the new version of Replication Server in upgrade mode. Enter:
    repsrvr –upgr –S rs_name –A  erssd_release_dir
 –C config_file –I interfaces_file –E errorlog_file

    In upgrade mode, Replication Server upgrades the ERSSD or RSSD it is using, automatically connects to each user database to which it has maintenance user access, and where a connection exists, applies the upgrade scripts to the database.

    The full syntax is:

    repsrvr [-C config_file] [-i id_server] 
[-S rs_name] [-I interfaces_file] 
[-E errorlog_file] [-M] [-v] [-K keytab_file] 
[-upgr] [-A erssd_release_dir] [-purgeq] 
[–nodb {all|dbid_1[,dbid_2[,dbid_3[,…]]]]} 
[-e]
    where:
    • -upgr – instructs Replication Server to start the upgrade
    • -A erssd_release_directory – specifies the location of the release directory of the ERSSD you are going to upgrade if Replication Server is using an ERSSD, for example:

      c:\sybase\REP-15_5\ASA11

      If you do not include the -A option, Replication Server obtains the release directory location from the Replication Server configuration file if the configuration file contains the information. Replication Server ignores the release directory location in the configuration file if you specify the -A option because what you specify manually in the repsrvr command overrides configuration file settings.

    • -purgeq – purges transactions from the inbound queue. You must use this option if you are upgrading from a version of Replication Server earlier than 15.5.
    • -nodb all – excludes all user databases from the upgrade process
    • -nodb dbid_1[,dbid_2[,dbid_3[,...]]] – excludes specific databases from the upgrade process. Separate multiple database IDs with a comma and do not include a space between the IDs. For example: 
      repsrvr –upgr . . .  -A . . .  -nodb 101,102,105
    • -e – records the SQL statements that Replication Server sends to data servers when you enter the -upgr parameter for upgrading. Without the -e option, there is no record of the SQL statements generated. With or without the -e option, the upgrade process uses the Replication Server error log file to record any errors that occur during the upgrade process, and why any user database was not upgraded.
    You can use only the -A, -purgeq, -nodb, and -e options when you use -upgr. See Replication Server Reference Manual > Executable Programs > repserver for descriptions of the other repserver parameters.
    For example, if you are upgrading the NY_RS Replication Server from version 15.5 to 15.7.1 SP100, and before the upgrade, NY_RS is using the c:\sybase\REP-15_5\ASA11 ERSSD release directory location, the ny_rs.cfg configuration file, the sql.ini file, and the ny_rs_errorlog error log file, enter:
    repsrvr –upgr –SNY_RS –Ac:\sybase\REP-15_5\ASA11 –Cny_rs.cfg –Isql.ini –E ny_rs_errorlog

    If the upgrade is successful, the upgrade mode shuts down Replication Server and you do not see any warning or error messages.

  5. Restart Replication Server using the appropriate executables for the new version.
    Warning!  Some Replication Server configuration options with newer versions may have a wider valid range. If you increase any of these configuration options after upgrading, you must reinstate the old values before downgrading. Otherwise, the Replication Server may not start or may behave incorrectly.
  6. If you installed the new Replication Server software in a different directory than the earlier version, modify the runserver files for the Replication Server to replace the old binary with new binary in the new version directory.
  7. If you are using Adaptive Server as the RSSD, restart the RepAgent for the RSSD:
    sp_start_rep_agent RSSD_name
  8. Resume log transfer to Replication Server from all Replication Agents for primary databases, and RSSD or ERSSD:
    resume log transfer from all
  9. If there are incoming routes to dest_rs, the Replication Server you upgraded and now restarted, log in to the source Replication Server and resume all routes to dest_rs to allow the source Replication Server to begin sending queued messages to dest_rs. At the source Replication Server, execute:
    resume route to dest_rs
  10. Check the upgraded Replication Server:
    1. Verify that the RSSD or ERSSD version of the upgraded Replication Server is correct.
      You can check one of:
      • Replication Server error log – you see:
        Upgraded RSSD successfully. The current RSSD version is '1571100'.
      • rs_config table – log in to isql and enter:
        select * from rs_config where optionname='current_rssd_version'
    2. Check that the Replication Server modules are running by executing admin who with the relevant options.
  11. If you have more Replication Servers to upgrade, repeat steps 1 to 12.
Parent topic: Upgrading Replication Server
Previous topic: Upgrades to RSSD or ERSSD and User Databases
Next topic: Upgrading RSSD or ERSSD with rs_init