Replication - Publisher moving to a different server

Hi,
I need to move my publisher to a different database as the current server on
which it is running is slow compared to my current requirements.
But I have 2 subscribers to this server. I have merge replication in SQL
Server 2k with sp3 on.
Can someone advice me as to how to have a smooth transition? I cannot just
replace the harddisk as the new server has a much powerful harddisk.
Is it possible for me to just restore the backup of the current publisher on
the new server alongwith the master and msdb, and replication starts? I will
take care to name the new server as the old one and remove the old one from
the network.
Can someone please help me with the same?
Thank you in advance.
Regards,
Karthik
The best approach is to drop the publication move the database to a new
server and then configure this server as the publisher and publish the
database to the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Karthik" <Karthik@.discussions.microsoft.com> wrote in message
news:6AE54F19-FB6F-4DDA-85DC-9430C4C8BF70@.microsoft.com...
> Hi,
> I need to move my publisher to a different database as the current server
on
> which it is running is slow compared to my current requirements.
> But I have 2 subscribers to this server. I have merge replication in SQL
> Server 2k with sp3 on.
> Can someone advice me as to how to have a smooth transition? I cannot just
> replace the harddisk as the new server has a much powerful harddisk.
> Is it possible for me to just restore the backup of the current publisher
on
> the new server alongwith the master and msdb, and replication starts? I
will
> take care to name the new server as the old one and remove the old one
from
> the network.
> Can someone please help me with the same?
> Thank you in advance.
> Regards,
> Karthik
>
|||Hi Hilary,
Thank you for the advice.
But the problem is, one of my subscriber is a remote subscriber. And this
subscriber is in a different continent. If I try to drop and recreate the
subscription, it fails to apply the initial snapshot as the shapshot is more
than 2 GB. Is there any other way I can go about applying the snapshot in
case I really need to drop the publication and go about this situation?
Thank you once again.
Regards,
Karthik.
"Hilary Cotter" wrote:

> The best approach is to drop the publication move the database to a new
> server and then configure this server as the publisher and publish the
> database to the subscriber.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "Karthik" <Karthik@.discussions.microsoft.com> wrote in message
> news:6AE54F19-FB6F-4DDA-85DC-9430C4C8BF70@.microsoft.com...
> on
> on
> will
> from
>
>
|||Karthik,
you could do a nosync initialization of this particular
subscriber. The table could be transferred using the
normal means - linked servers, DTS, BCP (with winzip),
backup and restore - or it may be that the subscriber and
publisher are already in sync, in which case you won't
need to do the transfer. To verify if this is the case,
you can do a binary checksum test.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
The publisher and subscriber would not have too many changes as I would be
moving the servers over the weekend. I can safely assume that no user would
be connected at either the publisher or subscriber over the weekend.
So do you think I can just restore the backup's of the master, msdb,
distribution, alongwith the replicated database on to the new server?
Also what is binary checksum test?
Thank you in advance.
Karthik.
"Paul Ibison" wrote:

> Karthik,
> you could do a nosync initialization of this particular
> subscriber. The table could be transferred using the
> normal means - linked servers, DTS, BCP (with winzip),
> backup and restore - or it may be that the subscriber and
> publisher are already in sync, in which case you won't
> need to do the transfer. To verify if this is the case,
> you can do a binary checksum test.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Karthik,
you just need to run the merge agent then prevent any changes on the
publisher and subscriber. Remove the subscription. Restore the subscriber's
database on the new server. Create a new subscription and in the wizard
state that there is no need to synchronize the data.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
Thank you for the information.
But I have a query, why should I restore the subscriber if I am not touching
the subscriber at all?
The only thing I need to do is to move the publisher to a different machine
(with different configuration but the same name).
I am not an expert at replication, so I may not understand what you are
trying to telling me. I am sorry if that is the case. But it would be really
helpful if you could explain to me in slightly greater detail.
Thank you in advance.
Regards,
Karthik
"Paul Ibison" wrote:

> Karthik,
> you just need to run the merge agent then prevent any changes on the
> publisher and subscriber. Remove the subscription. Restore the subscriber's
> database on the new server. Create a new subscription and in the wizard
> state that there is no need to synchronize the data.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Karthik,
my apologies. I hadn't noticed that my Outlook Express doesn't have your
first post so I was replying to the thread from your reply onwards.
Backing up the publisher database, master, msdb and distribution database
and restoring them on the new (identical named) server will allow everythng
to continue as before. If this is not possible, backing up the publishing
database and restoring it on a new server, setting up the merge replication
from scratch and when adding the subscriber selecting the option to not
initialize the data is another option. This is referred to as a nosync
initialization. For this to work, the subscriber and publisher databases
need to be identical, so after synchronizing before the database move, you
must ensure no other data changes can occur.
Regards,
Paul Ibison
|||Hi Paul,
Thank you once again.
One last thing that I wanted to ask was about the snapshot directory. In my
earlier setup, the snapshot directory (FTP) was in the same machine that
contained the publisher database.
So if I create the snapshot folder in the same path in my new publisher
would things be in place?
Thank you in advance.
Regards,
Karthik
"Paul Ibison" wrote:

> Karthik,
> my apologies. I hadn't noticed that my Outlook Express doesn't have your
> first post so I was replying to the thread from your reply onwards.
> Backing up the publisher database, master, msdb and distribution database
> and restoring them on the new (identical named) server will allow everythng
> to continue as before. If this is not possible, backing up the publishing
> database and restoring it on a new server, setting up the merge replication
> from scratch and when adding the subscriber selecting the option to not
> initialize the data is another option. This is referred to as a nosync
> initialization. For this to work, the subscriber and publisher databases
> need to be identical, so after synchronizing before the database move, you
> must ensure no other data changes can occur.
> Regards,
> Paul Ibison
>
>
|||Karthik,
if you chnage the directory used, the ftp properties will need altering but
this only applies to initialization, so it won't make any difference in your
case if you're restoring all databases to an identically-named server. If
you're restoring to a new server and doing a no-sync initialization (merge)
then the ftp path, login etc will need changing because even though the data
isn't transferred, the metadata is created on the subscriber.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)