Moving replication server

[PB]

Hi,

We are in the process of physically moving production replication server to
a new location.
We will be having a new IP address. This repserver manages 3 warm-standby
replication.

This moving process is going to take 2 hours. I am planning to shutdown the
replication
before move, then once it's back up, change the corresponding IP address in
other
hosts and bring up the rep server and we should be fine.

Our RSSD is on the same box.

Please suggest me if I am missing here something.

I greatly appreciate your help

Thanks
PB

[dfcgdg]

Stable queues ???

Make sure the system is quiesced , and there is nothing in the stable queue
before you stop the replication. Or you will have to sync the databases at
primary and replicate later.

On the new machine make sure that the stable devices have the same name as the
old one.

[PB]

Thanks. We have a big disk which can hold a days worth data.
I forgot about quiesced. Stable device name is not going to change.

dfcgdg <gdf...@gfdgsdf.com> wrote in message
news:3B5DB9A2...@gfdgsdf.com...

[Allen]

I called tech support with the same question the following is their response.
Hope it helps.
FR: mairey

Here are a couple of examples for Moving a Unix Repserver and RSSD. Let me know
if these help

Sincerely,

Marilyn Airey
Sybase Technical Support
1-800-8-SYBASE

To "Move" a Unix Repserver

Presumption: This Repserver's RSSD is NOT moving

NOTE: If the Repserver's RSSD IS moving,
perform the procedure Moving an RSSD Database
BEFORE continuing with this procedure.

1) Suspend log transfer from all

2) Suspend all routes from remote repservers into this repserver

3) Using "admin who,sqm", make certain that all queues in this
repserver are empty. That is, for all queues displayed, the
value reported in the First Seg.Block column must equal the value
reported in the Last Seg.Block column. (Exception: Totally
untouched queues will report as First Seg.Block = "0.1" and
Last Seg.Block = "0.0")

4) Suspend all routes to remote repservers from this repserver

5) Suspend all connections to replicate databases

6) Take a full database dump of the RSSD Database (call it Dump_0)

7) Delete all rows from rs_segments

8) Delete all rows from rs_diskpartitions

9) At each RSSD for each repserver to which a route exists,
you must perform the equivalent of an "rs_zeroltm" for
the Repserver-Repserver interface. In the RSSD of each
Replicate Repserver, proceed as follows:

9.1) Shutdown Replicate Repserver

9.2) Issue the following SQL

use RRS_RSSDname
go

select * into tempdb..prsname
from rs_locater, rs_sites
where sender = id
and name = "&LTPrimary_Repserver_name>"
go

update rs_locater set locater = 0x0
from rs_locater, rs_sites
where sender = id
and name = "&LTPrimary_Repserver_name>"
go

9.3) Restart Replicate Repserver

10) Copy/tar the $SYBASE directory structure containing Repserver
to new host

-or-

10.1) Sybload Sybase software into new home
10.2) Copy Interfaces file from old home into new home
10.3) Copy Repserver's RUN file from old home to new home
10.4) Copy Repserver's cfg file from old home to new home

11) Update the repserver's interfaces file entry to indicate
its new host address

12) Update the repserver's &LTrepservername>.cfg file to indicate any path
name changes

13) Start the repserver

14) "add partition" to add the desired stable device space
(Remember, raw partition or file system file names referenced in
the "add partition" statement must already exist in the new local
host)

15) At all LTM Hosts' interfaces files, update the repserver's connection
string to point to the repserver's new host address

16) At all repservers from which routes into this repserver originate,
update the repserver's connection string to point to the repserver's
new host address

17) Resume connections to replicate databases

18) resume log transfer from all

19) resume all routes out of this repserver

20) resume all routes into this repserver

--DONE--

Moving a Repserver's RSSD
to another SQLServer

------------------------
The following procedure has successfully moved an RSSD from one
SQLServer to another. Databasename has remained unchanged between
the two SQLServers.
------------------------

1) Are the present SQLServer and the future SQLServer at the same
SQLServer release level and on the same platform?

--> Procedure below is valid
ONLY IF "future SQLServer" is on the same platform
AND "future SQLServer" is at the same release or HIGHER

2) Do you have RSM installed?

--> No RSM issues are addressed in this procedure

3) Does this RSSD have an associated LTM?

4) Quiesce your system:

isql into repserver whose RSSD is the subject of this move

admin get_generation, &LTrssd servername>, &LTrssd databasename>
--> remember this value for Step 10

suspend log transfer from all
suspend connection to replicate_dataserver.replicate_database
<-- repeat for all replicate_databases controlled by this RS -->
suspend route to replicate_repservers &LTrepeat for all routes>

shutdown

(If answer to 3, above, was "YES")
isql into RSSD_ltm
shutdown

5) Examine the RS.cfg and the LTM.cfg:

RS.cfg LTM.cfg
------ -------
... ...
RSSD_server=SQLBP_CHAMP SQL_server=SQLBP_CHAMP
RSSD_database=RS1_RSSD SQL_database=RS1_RSSD
RSSD_primary_user=RS1_RSSD_prim RS_source_ds=SQLBP_CHAMP
RSSD_primary_pw=RS1_RSSD_prim_ps RS_source_db=RS1_RSSD
RSSD_maint_user=RS1_RSSD_maint SQL_user=sa
RSSD_maint_pw=RS1_RSSD_maint_ps SQL_pw=
ID_server=RS1 RS=RS1
ID_user=RS1_id_user RS_user=RS1_ltm
ID_pw=RS1_id_passwd RS_pw=RS1_ltm_ps
... ...

To simply dump RSSD at SQLServer_0 and load RSSD into SQLServer_1
will not be sufficient. "Users" in RSSD..sysusers are maintained as
numbers, rather than names, that tie to the master..syslogins on that
server. Adding the corresponding logins to the new SQLServer will not
guarantee that the userid numbers will correspond - in fact, you can
practically guarantee that they won't...

6) Examine RSSD..sysusers:

1> use RSSD
2> go
1> sp_helpuser
2> go
ID_
in_
Users_name db Group_name Login_name Default_db
-------------- -- -------------- -------------- ----------
RS1_RSSD_maint 4 rs_systabgroup RS1_RSSD_maint RS1_RSSD
RS1_RSSD_prim 3 rs_systabgroup RS1_RSSD_prim RS1_RSSD
dbo 1 public sa master

Now here's the plan. We want to drop all users from this database.
Then we will dump the database and restore the database at its new
home. At the new home, we want to re-add the users.

There is some "fine print," however.

We want to "sp_dropuser" those ids that represent "real users."
If your list of "real users" includes more than the 2 indicated above
(RSSD Maintenance user and RSSD Primary user), you must determine their
authorities, so that you may reissue the corresponding "grant"s at the
target location.

7) sp_dropuser RS1_RSSD_maint
sp_dropuser RS1_RSSD_prim
sp_dropuser &LTothers, if results of step_6 indicates>
checkpoint

8) dump the database

dbcc settrunc(ltm,ignore)
rs_zeroltm original_dataserver.rssdname
truncate log
dump database

9) At the target SQLServer:

9a) Create the RSSD database
9b) Load the RSSD database
9c) sp_addlogin RS1_RSSD_maint, RS1_RSSD_maint_ps, RSSD_dbname
sp_addlogin RS1_RSSD_prim, RS1_RSSD_prim_ps, RSSD_dbname
sp_addlogin &LTothers, if indicated by results of step 6, above>
sp_adduser RS1_RSSD_maint to RSSD_dbname
sp_adduser RS1_RSSD_prim to RSSD_dbname
sp_adduser &LTothers, if indicated by results of step 6, above>
sp_changegroup rs_systabgroup, RS1_RSSD_maint
sp_changegroup rs_systabgroup, RS1_RSSD_prim

10) (If answer to 3, above, was "YES")

--NOTE--

This step is NOT required in this procedure.
Therefore, you may SKIP THIS STEP.
It is only documented here, because as a general rule of thumb,
IF a database LOAD is performed to a Primary Database,
the generation number MUST be advanced.
This procedure, if followed to the letter, is an EXCEPTION
since the inherited database server timestamp in fact reflects
precisely the point from which processing may be resumed.

dbcc settrunc(ltm,gen_id, &LTvalue_from_step4 plus 1>)

11) (If answer to 3, above, was "YES")
dbcc settrunc(ltm,valid)
update rs_databases
set dsname = '&LTnew_dataserver_name'>
where dbname = '&LTRSSD_dbname>'
(this update will propagate across your repserver domain once the
RSSD ltm is restarted)

12) Regarding the ID server for this replication domain,
perform the following update at your ID server's RSSD SQLServer:

update rs_idnames
set name1 = '&LTnew_dataserver_name'>
where name2 = '&LTRSSD_dbname>'

13) Update the RS.cfg and LTM.cfg files.
From Step 5, above, change the following

RS.cfg LTM.cfg
------ -------
RSSD_server=&LTnew_servername> SQL_server=&LTnew_servername>
... RS_source_ds=&LTnew_servername>

...

14) Confirm that the interfaces file (or SQL.INI file) used by this
Repserver has an entry pointing to the new RSSD SQLServer

15) Confirm that the interfaces file (or SQL.INI file) used by each
Repserver to which this repserver has routes has an entry pointing
to the new RSSD SQLServer

16) Restart the Repserver
16a) Resume routes
16b) Resume log transfer from all
16c) Resume connection to dataserver.database
<-- repeat for all replicate_databases controlled by this RS -->

17) (If answer to 3, above, was "YES")
Confirm that the interfaces file (or SQL.INI file) used by the
RSSD LTM has an entry pointing to the new RSSD SQLServer

18) (If answer to 3, above, was "YES")
Restart RSSD LTM

19) Restart all other LTMs

***** The preceding is an email out from Sybase Technical Support
***** regarding case number: 10746351.
*****
***** To respond to the originator of this message, you can reply
***** as you would normally.
*****
***** If you would like your reply logged as a note in the case
***** history, please do the following:
*****
***** (A) Send the email addressed to:
*****
***** <support...@sybase.com>
*****
***** (B) Include the keyword 'Case Number:' followed by the
***** Case ID in the subject line.
*****
***** Example: Case Number: 10001234
*****
***** (C) The body of the email will be used as the text of the
***** case note.
*****
***** (D) The sender will receive an email confirmation when the
***** note is successfully logged against the case.
*****
***** Thank you and if you have any questions please contact
***** Sybase Technical Support at (800)-8-SYBASE.
*****
*****

[PB]

How to make sure nothing in the stable queue (SQ)?
I checked num_segs & allocated_segs in rs_diskparitions .
allocated_segs show 1. I think repserver operates on SQ
in 1MB chunk!

How to make sure SQ is clean before I stop the rep server.

Thanks

dfcgdg <gdf...@gfdgsdf.com> wrote in message
news:3B5DB9A2...@gfdgsdf.com...

[PB]

[Boe]

Is this method better than using DD to dump the raw devices to another
disk?

Is it faster?

Is it safer?

Is it easier?

We are looking to move a repserver to a larger server and configure it for
HA Cluster using shared storage. Current plans involve DD from old devices
to new devices (with repserver down).

Thanks
Boe

[Benny]

Are you moving the db server as well? or is it just the rep server alone? I
don't think 'dd' is supported by Sybase. You can call them up and ask for a
doc how to move a RS server. I got them a couple of months ago and am about
to move them this weekend. If you want I can probably send you what they
sent me.

benny

<Boe> wrote in message
news:99832869872A2BCF000563A285256AF5.003A975785256AB3@webforums...

[bple...@yahoo.com]

You suspend route, suspend log transfer, suspend all connection and
wait for the queue to finish.

Here is how to make sure stable queue is empty:
admin who,sqm
go
-> make sure all queues are empty.
-> FirstSeg.Blk == LastSeg.Blk or 0.1 = 0.0 if queue is
untouched.

benny