HEllo!!!!
Our enterprise need build a SQL server CLUSTER (4 computers).. but
now we don't have resources to buy a DISK ARRAY.. My Question is : Is
it possible to do this using MERGE REPLICATION between each SQL
instance in each Server?.
Thanks Brian
Brian,
these are not really the same functionally as clustering is not a method of
duplicating data but if you want to prepare for disaster recovery and can't
afford a cluster I suggest checking out Log Shipping. Replication can be
used (usually transactional with queued subscribers), but we can discuss
that if you don't like the look of log shipping.
Regards,
Paul Ibison
Showing posts with label build. Show all posts
Showing posts with label build. Show all posts
Monday, March 19, 2012
Friday, March 9, 2012
merge replication generation problem
Merge Replication Web Sync - Pull subscriptions
publisher and distributor: SQL Server 2005 X64 build 2221
clients are SQL Express builld 2047
We have 3 of our clients that received the following error at the end
of a merge.
SessionStatistics:
============================
UploadInserts:4
DownloadInserts:1748
DownloadUpdates:67
DownloadDeletes:15
SchemaChanges:1
ChangeDeliveryTime:64sec
SchemaChangeandBulkInsertTime:26sec
DeliveryRate:28.66rows/sec
TotalSessionDuration:368sec
================================================== ===========
2007-04-1823:50:38.669 The merge process was unable to create a new
generation at the'Subscriber'.Troubleshoot by restarting the
synchronization with verbose history logging and specify an output
file to which to write.
Since that time, they recieve the same error message at the beginning
of every merge attempt and fail immediately:
2007-04-1900:28:06.672 The merge process was unable to create a new
generation at the 'Subscriber'...
We have marked for re-init, but they get the above message prior and
fail, before ever doing a re-init.
Has anyone seen this? Have any suggestions what to look for/at?
TIA,
jg
Hi,
I am having the same problems with Merge Replication, did you find a solution?
Cheers
Pieter
"johng@.garrisonenterprises.net" wrote:
> Merge Replication Web Sync - Pull subscriptions
> publisher and distributor: SQL Server 2005 X64 build 2221
> clients are SQL Express builld 2047
> We have 3 of our clients that received the following error at the end
> of a merge.
> SessionStatistics:
> ============================
> UploadInserts:4
> DownloadInserts:1748
> DownloadUpdates:67
> DownloadDeletes:15
> SchemaChanges:1
> ChangeDeliveryTime:64sec
> SchemaChangeandBulkInsertTime:26sec
> DeliveryRate:28.66rows/sec
> TotalSessionDuration:368sec
> ================================================== ===========
> 2007-04-1823:50:38.669 The merge process was unable to create a new
> generation at the'Subscriber'.Troubleshoot by restarting the
> synchronization with verbose history logging and specify an output
> file to which to write.
>
> Since that time, they recieve the same error message at the beginning
> of every merge attempt and fail immediately:
> 2007-04-1900:28:06.672 The merge process was unable to create a new
> generation at the 'Subscriber'...
>
> We have marked for re-init, but they get the above message prior and
> fail, before ever doing a re-init.
> Has anyone seen this? Have any suggestions what to look for/at?
> TIA,
> jg
>
publisher and distributor: SQL Server 2005 X64 build 2221
clients are SQL Express builld 2047
We have 3 of our clients that received the following error at the end
of a merge.
SessionStatistics:
============================
UploadInserts:4
DownloadInserts:1748
DownloadUpdates:67
DownloadDeletes:15
SchemaChanges:1
ChangeDeliveryTime:64sec
SchemaChangeandBulkInsertTime:26sec
DeliveryRate:28.66rows/sec
TotalSessionDuration:368sec
================================================== ===========
2007-04-1823:50:38.669 The merge process was unable to create a new
generation at the'Subscriber'.Troubleshoot by restarting the
synchronization with verbose history logging and specify an output
file to which to write.
Since that time, they recieve the same error message at the beginning
of every merge attempt and fail immediately:
2007-04-1900:28:06.672 The merge process was unable to create a new
generation at the 'Subscriber'...
We have marked for re-init, but they get the above message prior and
fail, before ever doing a re-init.
Has anyone seen this? Have any suggestions what to look for/at?
TIA,
jg
Hi,
I am having the same problems with Merge Replication, did you find a solution?
Cheers
Pieter
"johng@.garrisonenterprises.net" wrote:
> Merge Replication Web Sync - Pull subscriptions
> publisher and distributor: SQL Server 2005 X64 build 2221
> clients are SQL Express builld 2047
> We have 3 of our clients that received the following error at the end
> of a merge.
> SessionStatistics:
> ============================
> UploadInserts:4
> DownloadInserts:1748
> DownloadUpdates:67
> DownloadDeletes:15
> SchemaChanges:1
> ChangeDeliveryTime:64sec
> SchemaChangeandBulkInsertTime:26sec
> DeliveryRate:28.66rows/sec
> TotalSessionDuration:368sec
> ================================================== ===========
> 2007-04-1823:50:38.669 The merge process was unable to create a new
> generation at the'Subscriber'.Troubleshoot by restarting the
> synchronization with verbose history logging and specify an output
> file to which to write.
>
> Since that time, they recieve the same error message at the beginning
> of every merge attempt and fail immediately:
> 2007-04-1900:28:06.672 The merge process was unable to create a new
> generation at the 'Subscriber'...
>
> We have marked for re-init, but they get the above message prior and
> fail, before ever doing a re-init.
> Has anyone seen this? Have any suggestions what to look for/at?
> TIA,
> jg
>
Monday, February 20, 2012
Merge Replication after data moved to a new server.
We need to move a database to a new server that is the main replication server.
The process was to build a new clean server and apply all patches and updates.
Replicate with all servers, then backup the database. Restore this database
to the new server. create a new subscription. All seemed to work except now
only new records created are replicating and any updates to existing records
are not updating. Any Ideas ?.
Conrad,
I'm a little unclear as to what you actually did. Did you have an existing
publication and then move this to a new server? Did the server have the same
name? Did you restore the msdb and distribution databases also? What type of
replication was this?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Envoriment is the following.
Server A publication database
Server B Remote Server
Server C Remote Server
Server A using push subscription to server B & C.
Server D new server.
Process:
Allow agents to sync with Server B & C so all databases are in sync.
Backup Server A Publication Database.
Disable Server A subscriptions. (disable server subscription agents)
Restore Server A Publication Database to Server D ( Different Name )
Create new publication for Server D
Create new push subscriptions to Server B & C
All subscriptions are merge subscriptions only.
When data is changed on server B & C some data was merged ( as new data was
modified or added ) and some create replication errors where the agents
believe that the data was changed outside of replication. ( I beleive the
metadata on Server B & C did not believe the system was in sync and was
trying to update the new publication server while it believes the data was
changed on server A publication and not applied yet )
When I restored the publication database to Server D ( Differenet Server
Name) the metadata is cleared by design ( This was done to make sure metadata
was clean. I assumed because the data was in sync that the remote server B &
C also believed the data is in sync ).
Is there a way to clear all metadata of the remote servers replication
history ?
I was hoping that this process would re-create the initial install of the
databases which worked great for a long time.
"Paul Ibison" wrote:
> Conrad,
> I'm a little unclear as to what you actually did. Did you have an existing
> publication and then move this to a new server? Did the server have the same
> name? Did you restore the msdb and distribution databases also? What type of
> replication was this?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Conrad,
probably needa little more info about the topology - eg why is Server D set
up as another publisher?
Does it publish the same articles or different ones?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Server D is a new faster server replacing Server A
Server A will then become the test server for future application testing in
a replicated env. This is why Server D is using a different Name. Server A
will remain as is but witha role in the test env.
So the production setup is
Server D Publication Server using push subcription to Server B & Server C
Where the data changes are on Server B & C. There are no data changes on
Server D. and backup of the data is on Server D ( Central data center )
"Paul Ibison" wrote:
> Conrad,
> probably needa little more info about the topology - eg why is Server D set
> up as another publisher?
> Does it publish the same articles or different ones?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>
|||Conrad,
whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
D then remove the replication setup (after scripting it all out). Then I'd
set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
if you try to move replication in situ to differently named servers this is
not supported as the servername is hardcoded into too many meta data tables.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||The step of
do a nosync intialization to B and C. not sure what you mean by this step.?
I setup a subscription where the the data and schema are not used is this
what you mean.
"Paul Ibison" wrote:
> Conrad,
> whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
> D then remove the replication setup (after scripting it all out). Then I'd
> set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
> if you try to move replication in situ to differently named servers this is
> not supported as the servername is hardcoded into too many meta data tables.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||I think we're talking about the same thing. It's the option in the wizard
where you select to Not initialize the data because the subscriber already
has it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
The process was to build a new clean server and apply all patches and updates.
Replicate with all servers, then backup the database. Restore this database
to the new server. create a new subscription. All seemed to work except now
only new records created are replicating and any updates to existing records
are not updating. Any Ideas ?.
Conrad,
I'm a little unclear as to what you actually did. Did you have an existing
publication and then move this to a new server? Did the server have the same
name? Did you restore the msdb and distribution databases also? What type of
replication was this?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Envoriment is the following.
Server A publication database
Server B Remote Server
Server C Remote Server
Server A using push subscription to server B & C.
Server D new server.
Process:
Allow agents to sync with Server B & C so all databases are in sync.
Backup Server A Publication Database.
Disable Server A subscriptions. (disable server subscription agents)
Restore Server A Publication Database to Server D ( Different Name )
Create new publication for Server D
Create new push subscriptions to Server B & C
All subscriptions are merge subscriptions only.
When data is changed on server B & C some data was merged ( as new data was
modified or added ) and some create replication errors where the agents
believe that the data was changed outside of replication. ( I beleive the
metadata on Server B & C did not believe the system was in sync and was
trying to update the new publication server while it believes the data was
changed on server A publication and not applied yet )
When I restored the publication database to Server D ( Differenet Server
Name) the metadata is cleared by design ( This was done to make sure metadata
was clean. I assumed because the data was in sync that the remote server B &
C also believed the data is in sync ).
Is there a way to clear all metadata of the remote servers replication
history ?
I was hoping that this process would re-create the initial install of the
databases which worked great for a long time.
"Paul Ibison" wrote:
> Conrad,
> I'm a little unclear as to what you actually did. Did you have an existing
> publication and then move this to a new server? Did the server have the same
> name? Did you restore the msdb and distribution databases also? What type of
> replication was this?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Conrad,
probably needa little more info about the topology - eg why is Server D set
up as another publisher?
Does it publish the same articles or different ones?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Server D is a new faster server replacing Server A
Server A will then become the test server for future application testing in
a replicated env. This is why Server D is using a different Name. Server A
will remain as is but witha role in the test env.
So the production setup is
Server D Publication Server using push subcription to Server B & Server C
Where the data changes are on Server B & C. There are no data changes on
Server D. and backup of the data is on Server D ( Central data center )
"Paul Ibison" wrote:
> Conrad,
> probably needa little more info about the topology - eg why is Server D set
> up as another publisher?
> Does it publish the same articles or different ones?
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>
|||Conrad,
whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
D then remove the replication setup (after scripting it all out). Then I'd
set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
if you try to move replication in situ to differently named servers this is
not supported as the servername is hardcoded into too many meta data tables.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||The step of
do a nosync intialization to B and C. not sure what you mean by this step.?
I setup a subscription where the the data and schema are not used is this
what you mean.
"Paul Ibison" wrote:
> Conrad,
> whenm doing this, I'd synchronize the A publisher with B and C. Restore A on
> D then remove the replication setup (after scripting it all out). Then I'd
> set up D as the publisher and do a nosync nitialization to B and C. AFAIK,
> if you try to move replication in situ to differently named servers this is
> not supported as the servername is hardcoded into too many meta data tables.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||I think we're talking about the same thing. It's the option in the wizard
where you select to Not initialize the data because the subscriber already
has it.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Subscribe to:
Posts (Atom)