How do you preserve the File Group on the Subscriber of a Merge Replication Publication?
I created identical databases with 3 filegroups for various groups of tables, assigned to the appropriate filegroups when the tables were created.
The first time I created a publication (populated publishing database first, data went into correct filegroups) the tables on the subscriber were all dropped and recreated in the default filegroup of the subscriber.
OK, so I changed the "Action if name is in use" property to Truncate data in destination tables on initialization: snapshot ran fine, subscriber sync failed because it said it could not execute the script to add the rowguid column to the tables.
So what is the best way to keep the filegroups from changing? I want the data to go into the desired file groups when it is pushed by the publisher to the subscriber.
After yet more research, it turns out there is a flag in the the Article Properties called "Copy file group associations" which is set to FALSE by default.
It wouldn't let me just change it, had to rebuild the publication, but doing so and setting the FLAG to true recreated the tables with the desired Filegroups on the subscription databases and after snapshot creation, the subscriptions pushed and the data flowed into the correct filegroups. Sweet!
Related
SQL Server 2012, 2014, 2016 transactional replication
Publication is created. (copy Foreign Keys is false, the default)
Subscription is created.
Snapshot and sync.
Turn off synchronization.
Upgrade the publication database.
Upgrade the subscriber database for tables affected by modified views.
Set the snapshot to only gather information for changes.
Restart sync.
There is now an error at the subscriber because the two new columns exist and the snapshot is trying to create them but with foreign keys.
Typically it hasn't cared but now it seems to because of the FK creation it wants to do. If I manually delete the two new columns the sync will now create them again but with FKs.
The same operation happens for other new fields but we've never run into this issue before.
Looking to understand why FKs are being sent and if there is a workaround or setting.
I have a specific requirement in Transactional Replication, but I am not sure whether it is achievable or not. Could you please help me out if there is any possible way to achieve the same.
Requirement:
As per the requirement, there will be two databases. One is the publication database and another is subscription database.
I want to replicate some of the tables (articles) of the publication database to the subscription database. But what I want is to replicate data only. Because I want to keep those tables (replicating tables) to always present in the subscription database, they may be the empty table initially and when replication starts, these tables may get their data from publication database.
But I don't want the replication to create these tables for me in subscription database. I want to use already created tables. They will have the same schema as publication database tables.
When you configure a publication, you can set the properties for articles. One of the article properties is called Action if name in use. You can set that to the option Keep existing object unchanged.
I have setup merge replication in SQL Server 2012 for a database with around 300 tables and two subscribers. Whenever I add a new table in the publication properties, the agent generates a snapshot for the all the tables again. How can I configure it to only create snapshot of the newly added articles and only synchronise those ones to subscribers?
To avoid generating a full snapshot when you add a new article, publication properties #immediate_sync and #allow_anonymous must be set to 0.
It's likely #immediate_sync is 1 (true) in your configuration, so snapshot agent creates a full snapshot.
See also https://msdn.microsoft.com/en-us/library/ms188738.aspx
I currently have SQL Server Transactional replication running. Server A (Publisher & Distributor) to Server B (Subscriber). Everything is working great. I just need to know whether i can add a table to the subscriber only in that database? will it affect my replication? must the databases be the exact same in terms of schema etc?
I need to add a table that's not part of the publishers published articles on Server B(Subscriber).
I just need to know whether i can add a table to the subscriber only
in that database?
Yes, you can. It won't affect to the replication, but, for example, if you create table dbo.A on subscriber database first and later you'll create table with the same name and schema on publisher database you can lost data in table dbo.A on subscriber because by default new articles on the subscriber will be drop if exists within initialize process.
You can change this behavior in publication properties.
must the databases be the exact same in terms of schema etc?
No, it must not. In transaction replication you can replicate either whole tables or some columns of those tables.
Background information
Let's say I have two database servers, both SQL Server 2008.
One is in my LAN (ServerLocal), the other one is on a remote hosting environment (ServerRemote).
I have created a database on ServerLocal and have an exact copy of that database on ServerRemote. The database on ServerRemote is part of a web application and I would like to keep it's data up-to-date with the data in the database ServerLocal.
ServerLocal is able to communicate with ServerRemote, this is one-way traffic. Communication from ServerRemote to ServerLocal isn't available.
Current solution
I thought it would be a nice solution to use replication. So I've made ServerLocal a publisher and subscriptions are pushed to the ServerRemote. This works fine, when a snapshot is transfered to ServerRemote the existing data will be purged and the ServerRemote database is once again an exact replica of the database on ServerLocal.
The problem
Records that exist on ServerRemote that don't exist on ServerLocal are removed. This doesn't matter for most of my tables but in some of my tables I'd like to keep the existing data (aspnet_users for instance), and update the records if necessary.
What kind of replication fits my problem?
Option C: Transactional replication.
I've done this before where you have data in a subscription database and don't want it overwritten by the snapshot. You can set your initial snapshot to not delete the existing records and either don't create the records that are in the publisher (assume they are there) or create the records that are in the publisher (assume they are not there).
Take a look at what would be correct for your situation or leave a comment with more details on how you get your data in the subscriber originally. I'm not too familiar with aspnet_users and what that is. Transactional replication only helps if you don't want the data in the subscriber back at the publisher. If you want that you'll have to do merge replication.