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
Related
I've created a Data Fusion replication job to replicate some tables on a test database.
It works well at the beginning if I don't change the tables schema. But I've added a new column and that column is ignored from the replication job. I guess that if I create a new table, even that table would be ignored.
Is there a way to include schema updates (new table, update column field, new column etc...) inside an already running Data Fusion replication job?
I guess a possible solution would be to stop the currently running job and create a new one including new tables, new columns etc... but I'd like to avoid that a new job would replicate all the database again.
Any possible solution?
Unfortunately, Data Fusion Replication for SQL server currently does not support DDL propagation during runtime; you will need to delete and recreate the replicator pipeline in order to propagate any changes to schema to the new BigQuery table.
One way to avoid replicating existing data with DDL change is that , you can manually modify the BigQuery table schema (But BigQuery also has limited support for schema changes) and create a new replication job and disable replicating existing data(there is an option that let you choose whether to replicate existing data, default is true)
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 done transnational replication to my SQL Server 2014 instance.
There are two db servers subscribing to it. Currently I have added
only some of the tables (10 tables) as articles to replicate. However, in the future there will be new tables added to the distributor database that needs to be included as replication articles.
I know that whenever I want to add a new article to the replication, I can go to the Properties of publication and add new articles through the wizard.
However, my problem is that there are some tables added by an application through T-SQL queries.Those tables need to be replicated. So there is no way
I can go to the wizard and add those to articles.
Is there a way that I can add articles to the replication through a T-SQL? or Is there any system stored procedure or anything we can use to add articles to replication.
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!
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.