Replication related issue,
I am explaining my architecture .
I have created , its transactinal replication process
2 Publisher on table vendors script I have given below,
A Distributor
2 Subscribers
Data replication set up is like this as :
Table VENDORS gets replicated from 2-publishers to 2-subcribers via-Distributor.
While replication, ERROR issued in Distributor database as :
Here, What must happen is
Pub1 (creates pubs table vendors) –> inserts (vendors) data to Distributor. -> pull by subscribers
What is happening now for me is ,
Pub1 (creates pubs table vendors-done) -> Throws error at distributor database as
Replication-Replication Distribution Subsystem: agent abc-serv1\PRD01-star-star Billing-PROD-VREPL1\REPL01-25 failed.
Violation of PRIMARY KEY constraint 'PK_vendors'. Cannot insert duplicate key in object 'dbo.vendors'.
Error is issued while operation is done between Publishers to Distributor.
The Primary Key at the Publisher has to be maintained at the Subscriber when using Transactional Replication. It sounds as though a record with the given key value already exists at the Subscriber.
From your topology description you have two separate Publications.
So:
Subscriber 1 receives Publication 1
Subscriber 2 receives Publication 2
Is there any crossover i.e. can Subscriber 2 also receives Publication 1. If so then you will encounter Primary Key conflicts unless you manage the key ranges on both Publishers or use an alternative Replication technology, such as Merge Replication.
Related
I have a subscription with DB2 for i (as400) as source and Kafka as target (11.4.0.2). The replication method is REFRESH.
There was a table in the subscription, which was running well.
But after I delete it and add it to another new subscription (with same source and target, also REFRESH), it cannot be replicated. The replication end with following message:
Subscription XXX has received a request for an abort shutdown. There are no other error messages. The table mapping (flag for refresh already) seems being ignored by CDC.
From the log, it returns:
Received normal shutdown request number 9 with reason OTHER_ENGINE_COMPLETE
I have no idea what is happening as there are no obvious hints from logs.
I tried (1) recreate table mapping and (2) update table definitions, but not working.
Other tables in the subscription can be replicated.
Please check after you delete table mapping from earlier subscription, is it still showing by checking 'replication tables' in MC (select datastore -> replication tables) select and remove and remap in new subscription.
Thanks
Sudarshan K
I am with replication so after trying for 1 month I am able to initialize publisher on remote system and subscriber on my local system. When I run job at subscriber end I get an error
the schema script AccountNotic1234.sch could not be propagated to the subscriber
Somewhere I read this error happens when tables are connected using foreign keys and you missing primary table but I am synchronizing all tables. So it can not be the issue.
When I run the subscription I get error for 3 tables in order not on 1st and 2nd don't know why?
What can be the possible reasons for this?
Should the SQL database replication stop if i delete one record in a replicated table on the subscriber end?
I remember having a replication running where the delete on subscriber would be overwritten from publisher effectively preventing you from deleting the data.
But in our new configuration it crashed the replication when we deleted one record.
It depends. If you deleted a row at the subscriber that is subsequently updated at the publisher, replication will break when the update is propagated. Why is this? If you look at how the command is replicated, it calls a stored procedure with the PK column(s), a bit mask of what columns changed, and then the list of new values for columns that changed (I'm glossing over some detail, but you can look for yourself in the subscriber database; the procedures are all there and pretty accessible). Because it doesn't re-replicate the whole row again, if it doesn't find the row indicated by the PK, replication assumes (correctly) that the subscriber is no longer in sync with the publisher and stops. As far as I know, replication has never worked in the way you describe.
TL;DR: you should treat the subscriber database(s) as read-only except by the replication process itself.
We have a big database (100 GB) in our production environment and we have two mirrors. we use replication to sync our mirrored database.(Transactional Replication on SQL Server 2012)
when we created replication, our DBA first download full backup from our servers and restore it on Mirror server ,then configured the replication between Publisher (Production-DB) and Subscriber (Mirror-1). Everything works fine and mirror and production are synced perfectly.
before each release, we should test our system on our UAT server with REAL! data. so we create a back up from one of our Mirrored Servers (onsite mirror) and Restore it on our UAT Database.
All table in our database have one PK like :
[ID] [int] IDENTITY(1,1) NOT NULL
In our UAT Database the last record of OrderTransaction table ID = 160.000.000, but when our application try to insert into this table, system encounter a problem and exception raised.
Violation of PRIMARY KEY constraint ‘ID’. Cannot insert duplicate key in object ...
system try to insert an integer value smaller than 160.000.000 (ID = 145.695.000)
as i queried the database this id is the last ID when the backup of production db restored to mirrored db and after that transactional replication started.
all information on production and mirrored are synced correctly and ID of the Tables on both servers are the same and identical.
When I run this command on the UAT or Mirrored Database it returns 145.695.000
SELECT IDENT_CURRENT( 'OrderTransaction' )
as I read MSDN, blogs and related SO question, this problem related to replication and identity columns.
But, how can i force our Mirror database to grow its Identity with Production.(and accept this value as local identity value). Or may be we should write a script that reseed every table for testing in our UAT environment!?
thanks.
If you are only having issues when restoring a prod mirror into UAT your simplest solution, as you suggest, is likely to just script a reseed for each table.
For more general problems replication and identity problem you may find this excellent article from Hilary Cotter on Simple-Talk useful.
In this article we looked at ways to implement identity management
solutions in replication to avoid primary key conflicts. We looked at
partitioning and manual and automatic identity range management
solutions. Solutions using automatic identity range management can work well with careful planning.
EDIT:
This should reset all the identities to the current max value:
EXEC sp_MSForEachTable '
IF OBJECTPROPERTY(object_id(''?''), ''TableHasIdentity'') = 1
DBCC CHECKIDENT (''?'', RESEED)'
Which is a slight modification to Pinal Dave's work.
I'm using Merge Replication. The Identity range management is AUTOMATIC
I HAVE A TRIGGER ON COMPANIES TABLE WHICH INSERTS ROWS IN SERIALNUMBERSCHEME TABLE which has documentID as identity column
While synchronizing I'm getting below error
A row insert at 'SERVER\MUMBAI.PROD_SUB' could not be propagated to 'SERVER\NEWYORK.PROD'. This failure can be caused by a constraint violation. Explicit value must be specified for identity column in table 'SerialNumberScheme' either when IDENTITY_INSERT is set to ON or when a replication user is inserting into a NOT FOR REPLICATION identity column.
Data is inserted properly at subscriber but not replicated at publisher
Any solution/suggesstion?
Sounds like your trigger gets fired when the replication agent applies the updates. Normally the trigger should run only at the publisher (or more precisely, at the site which inserts the original data). Then replication will replicate the effect of the trigger. I think that all you need is to mark the trigger as NOT FOR REPLICATION.
See Controlling Constraints, Identities, and Triggers with NOT FOR REPLICATION.