I have a mysql replication setup with one master reporting to one slave. The schema on the slave is the same than the master but for each table I have an additional synchronized column only on the slave which I use for sync with a third system. I need the following behavior:

1. By default, the synchronized column is set to 0
2. I have an external python script that copies each row with synchronized=0 to another system (with another schema) and then sets the synchronized field to 1
3. If the row is updated again by the master through replication, I want the synchronized field to be set to 2 (probably through a trigger on update) so that my python script can detect updated rows and update them in the third system.

To simplify, let's say we have a master table like this :

People
id (int)
name (varchar)

and the corresponding table on slave

People
id (int)
name (varchar)
synchronized (tinyint)

If I insert I already tried to set up a trigger on update on the slave to change the synchronized field to 2. It works when I update a row manually but not when it is updated through replication.

I understood that in row-based replication triggers are not replicated from the master but I am not trying to replicate a trigger from the master but rather create a trigger on slave whenever a row is updated through replication.

Right now my replication is row-based but i could change it to statement based or mixed if needed. Hope it makes sense and that everything is clear, any suggestions are welcome,

Thanks

I am getting an Error on Slave as:

could not execute Write_rows event on table mydatabasename.atable; Duplicate entry '174465' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000004, end_log_pos 60121977

As I am directly getting updates from master so why this happens.

How can we handle this in an effective manner so that there is no data loss on the slave.I do not want to set up the whole replication again for maintaining the data integrity.

Thanks..!

I am looking to replicate redshift data on different region. However, redshift does allow replication for backup reason only. What i am looking for is process the data on one region and then replicate processed data on other region so that tools on second region can directly connect to redshift in that region to reduce latency.

I know I can use kinisis like described in below solution but since its not transactional app really dont want to use it.

https://aws.amazon.com/blogs/big-data/building-multi-az-or-multi-region-amazon-redshift-clusters/

When I try to send a tracer token on some of my publications to get the latency I get the following error -

No active subscriptions were found. The publication must have active subscriptions in order to post a tracer token.

There are subscriptions tied to these publications as well. I can fix this by re-initializing\rebuilding replication, but I was wondering if there is a way to tell with when the subscription stopped receiving anything? I want to determine how long this has not been working.

The tables that are being replicated do not have timestamps on them that allow me to figure it out based on that. I have checked Replication Monitor, navigated through several of the tables in the distribution database, checked the job history and SQL logs and not able to determine this. Is there a timestamp recorded somewhere that shows the last synch from the distributor to the subscriber?

We are using SQL Transactional Replication (Push) and on SQL Server 2012 SP4.

I am looking for ideas to restore a large backup on a VM hosting SQL Server that is replicating to another VM in a remote location. Restoring it will replicate the restored backup consuming a lot of the bandwidth between both sites.

Both sites are in same city. Would it work if I pause the replication, restore the DB on both local and remote VMs, then resume replication? This will save from wasting bandwidth.

I know I can break the replication, restore the DB, export the local VM and import into the remote site. It would work, but there are other DBs on the VM server. The exported VM image would be huge. The other issue with this. I will need to repeat this process when moving other databases into the local VM which does not sound like a good idea.

Is there a better way?

I am running master-slave replication, Can I manually move binlog files from the master server to the slave and make the slave read them locally?

I am willing to do so because I am running out of space on the master storage. and the number of binlog files is huge.

I have replica set up with 3 nodes. I'm testing failover when primary MongoDB lost network connection then my Java client waits about 15min ( although it determines the new primary right after disconnection happened) and only after that it starts to send messages to the new primary.

All 3 replica sets are running on three separate VMs and my java code are running from another VM. They can see each other.

I also tried to set optional configurration parameters for MongoDB like connectTimeoutMS and socketTimeoutMS but it didnt help

java implementation:

String uri = "mongodb://" + username + ":" + password + "@mongo01:27017,mongo02:27017,mongo03:27017/" + database + "?replicaSet=ReplicaSet&ssl=false&connectTimeoutMS=100000";
        MongoClientURI connectionString = new MongoClientURI(uri);
        MongoClient mongoClient = new MongoClient(connectionString);
        MongoDatabase db = mongoClient.getDatabase(database);
        MongoCollection<Document> collection = db.getCollection(collectionName);
        collection.drop();
        for (int i = 1; i <= numberOfMessages; i++) {
            Timestamp timestamp = new Timestamp(System.currentTimeMillis());
            System.out.println("Sending message " + i + " @ " + timestamp);
            try {
                collection.insertOne(createDocument(i));
            } catch (Exception e) {
                System.out.println("Failed: " + e.getMessage());
                i--;
            }
        }

log output (previous primary was mongo01 and after network disconnection mongo02 became primary):

2019-10-21 14:34:41.965  INFO 6599 --- [}-mongo02:27017] org.mongodb.driver.cluster               : Discovered replica set primary mongo02:27017
2019-10-21 14:49:27.206  WARN 6599 --- [           main] org.mongodb.driver.connection            : Got socket exception on connection [connectionId{localValue:6, serverValue:38}] to mongo01:27017. All connections to mongo01:27017 will be closed.
2019-10-21 14:49:27.214  INFO 6599 --- [           main] org.mongodb.driver.connection            : Closed connection [connectionId{localValue:6, serverValue:38}] to mongo01:27017 because there was a socket exception raised by this connection.
Failed: Exception receiving message
Sending message 12 @ 2019-10-21 14:49:27.716
2019-10-21 14:49:27.741  INFO 6599 --- [           main] org.mongodb.driver.connection            : Opened connection [connectionId{localValue:78, serverValue:56}] to mongo02:27017

I would like to know why it takes so long time to start sending messages for my java client after disconnection. I'd appreciate for any help.

I have a MYSQL master with two slaves also running MYSQL 5.6. I want to create another slave and that needs to be MYSQL 5.5. I was wondering if replication will work smoothly. I have log_bin_use_v1_row_events switched off in MYSQL 5.6 and I am using mixed format replication.

Can anyone give me advise on doing above.

I'm trying to create a cross-region read replica of my AWS RDS MySQL instance in eu-central-1 (Frankfurt) in another region (Asia/Pacific).

When I'm choosing Hong Kong as "Destination region" there is following error message shown at the bottom of the form:

Cannot find endpoint for region: 'ap-east-1'

which prevents me from creating a replica at all. When I choose any other region in Asia/Pacific, i.e. Seoul, there is no such error and I can click on "Create read replica".

It then throws another exception though:

Invalid security group , groupId= sg-970580f5, groupName=. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 95937f8e-10c8-4527-8769-a1d807a6f6ec)

This is the security group assigned to the master database, and I can't choose another one for the read replica. There is nothing wrong with the security group, it's as basic as it gets, and the group name is not ".".

Has any of you experienced similar problems and knows a solution to either one of these problems?

Please let me know if you need any further informations.

Thanks in advance and kind regards

We are in the middle of a project to upgrade nearly 30 servers from SQL 2008 R2 to SQL 2017, this project merged with another to upgrade Windows Server 2008 to 2016. We started later than planned (previous over-run) and are mid-testing our process / timings.

We have created new Win 2016 servers with SQL 2017 installed, clone disks to attach to the new servers, run scripts to attach DBs, create logins with the original GUI, etc. When we re-direct DNS entries our in house & off the shelf Apps work. All good so far.

The problem we have is with SQL Replication.

Is there any proven way to migrate Snapshot and Transactional Push Replication from one server to its upgraded self ?

We have tried following various sets of advice (Google being our best friend), but even if we think we have followed the same process a second time (re-runs for practice / confirmation of process / timings) we get different SQL Agent Jobs set up. Sometimes Log-Reader jobs attached to Snapshot Replication, sometimes duplicate Distribution Jobs where on the original server there was only one. Sometimes when we re-Initialise a publication from the Replication Monitor it fails to start the SQL Agent Job ( but if we start it manually it works OK ).

I suspect if we keep at it we will end up with all our Replication working, but in Production we have approaching 40 Publications some going to two Subscriptions and to “fix” those on the fly during a GO Live weekend is a daunting task ( some extract data for MI, but others are bi-directional updating data between the Core App and remote users via servers in a DMZ ).

However complicated .. is there a tried and trusted method of achieving this ?

Many thanks in anticipation

I am working with SQL Server 2014 Transactional Replication with tables that have partitions. The source tables are partition switched when they are loaded and so far I have been able to replicate this successfully.

The replication source I am working with performs some dynamic partition management by creating partitions on the Partition Function/Partition Scheme during the load into the table. This is not natively supported by Transactional Replication per the documentation found here:

After the Subscriber is initialized, data changes are propagated to the Subscriber and applied to the appropriate partitions. However, changes to the partition scheme are not supported. Transactional and merge replication do not support replicating the following commands: ALTER PARTITION FUNCTION, ALTER PARTITION SCHEME, or the REBUILD WITH PARTITION statement of ALTER INDEX. The changes associated with them will not be automatically replicated to the Subscriber. It is the responsibility of the user to make similar changes manually at the Subscriber.

This is where I am getting hung up. We've worked through most of the problems with the loading and switching of partitions and we are now dynamically creating the new partitions, as they come in, on both the replication source (publisher) and replication target (subscriber) through the use of a stored procedure as part of the load to the publisher. The stored procedure exists on both the publisher and subscriber (manually put there).

When running a test last night, we saw that partitions were dynamically created on the publisher and subscriber, but there was a new error on the Log Reader Agent. At this point, I don't even know where to begin to start tracking this down.

Error messages: The process could not execute 'sp_replcmds' on 'RNCAZFAST2'. (Source: MSSQL_REPL, Error number: MSSQL_REPL20011) Get help: http://help/MSSQL_REPL20011

No catalog entry found for partition ID 72057598976393216 in database 27. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption. (Source: MSSQLServer, Error number: 608)

I started looking up the error and it looked like it was a bug back in 2005, but we are on SQL Server 2014 Enterprise on an Azure VM. Any help is greatly appreciated!

I have a mongodb cluster with 3 nodes.

How can i configure the cluster for asynchronous replication in this cluster? Is there any global configuration which provides this functionality?

I have been having trouble finding an example of what use cases are suitable for Vector Clocks and Version Vectors, and how they might differ. I understand that they largely work in the same way, with Vector Clocks using receive and send functions, and Version Vectors using a sync function instead, but I do not understand the differences between the two options. Is it just two different ways of expressing the same thing, or are there real differences in use cases between them?

I was only able to find one question that was somewhat related: "When do I use a consensus algorithm like Paxos vs using a something like a Vector Clock?"

Even though the linked answer states the following, and references a short article, the differences are still unclear to me.

You might want to use a version vector for a leaderless distributed storage. You might use vector clocks for the same (although it's a worse fit; the article also suggests you use it for consistent snapshots, for implementing causal ordering in general distributed systems etc).

Now I'm observing in Activity Monitor permanent count of waiting tasks:

and at "Resource waits" tab I see next:

so, my question is: How to find and resolve this wait tasks?

I suspect that it related with transactional replication, which running on the server. This wait tasks I see only on Distributor. This issues appeared after restarting SQL server service.

sp_whoisactive - doesn't show any locks.

Thanks a lot for any information.

When I use the GUI to make any changes to transactional replication on SQL server, I live in fear of the "the changes you have made require a reinitialization of all articles" dialog.

I have had this happen even when doing something simple like adding or removing individual tables.

How do I avoid this?

Are there replication settings that impact when a full reinitialization is required? I found this blog post that claims that publication properties @immediate_sync and @allow_anonymous should be set to 0, I've done that but I've still sometimes had it prompt to reinitialize the whole thing.

Should I be scripting the add/remove instead of using the GUI?

Also, we frequently remove a table from replication but need to add it back in later, are there scripts out there to preserve the replication settings so this process is easier?

What would be the easiest way to do real time replication of an on premises SQL Server/Oracle to an cloud Azure Cosmos DB ?

I've been trying to add a new node to a replica set without success due to these errors:

2019-08-12T06:48:15.031+0200 I ASIO [NetworkInterfaceASIO-RS-0] Ending connection to host mongo03:27017 due to bad connection status; 1 connections to that host remain open 2019-08-12T06:48:15.031+0200 I REPL [replication-224] Restarting oplog query due to error: NetworkInterfaceExceededTimeLimit: error in fetcher batch callback: Operation timed out. Last fetched optime (with hash): { ts: Timestamp(1565585283, 1317), t: 9 }[1741433982986566690]. Restarts remaining: 10 2019-08-12T06:48:15.032+0200 I REPL
[replication-224] Scheduled new oplog query Fetcher source: mongo03:27017 database: local query: { find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565585283, 1317) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, batchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565585283, 1317), t: 9 } } } query metadata: { $replData: 1, $oplogQueryData: 1, $readPreference: { mode: "secondaryPreferred" } } active: 1 findNetworkTimeout: 7000ms getMoreNetworkTimeout: 10000ms shutting down?: 0 first: 1 firstCommandScheduler: RemoteCommandRetryScheduler request: RemoteCommand 2262327 -- target:mongo03:27017 db:local cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565585283, 1317) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, batchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565585283, 1317), t: 9 } } } active: 1 callbackHandle.valid: 1 callbackHandle.cancelled: 0 attempt: 1 retryPolicy: RetryPolicyImpl maxAttempts: 1 maxTimeMillis: -1ms 2019-08-12T06:48:17.637+0200 I ASIO [NetworkInterfaceASIO-RS-0] Connecting to mongo03:27017 2019-08-12T06:48:17.645+0200 I ASIO
[NetworkInterfaceASIO-RS-0] Successfully connected to mongo03:27017, took 8ms (2 connections now open to mongo03:27017) 2019-08-12T06:49:36.961+0200 I - [repl writer worker 13]
DB.CollectionName collection clone progress: 221390504/643329790 34% (documents copied) 2019-08-12T06:51:52.859+0200 I ASIO
[NetworkInterfaceASIO-RS-0] Ending connection to host mongo03:27017 due to bad connection status; 1 connections to that host remain open 2019-08-12T06:51:52.859+0200 I REPL [replication-229] Restarting oplog query due to error: NetworkInterfaceExceededTimeLimit: error in fetcher batch callback: Operation timed out. Last fetched optime (with hash): { ts: Timestamp(1565585502, 204), t: 9 }[3285716995067894969]. Restarts remaining: 10 2019-08-12T06:51:52.859+0200 I ASIO
[NetworkInterfaceASIO-RS-0] Connecting to mongo03:27017 2019-08-12T06:51:52.859+0200 I REPL [replication-229] Scheduled new oplog query Fetcher source: mongo03:27017 database: local query: { find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565585502, 204) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, batchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565585502, 204), t: 9 } } } query metadata: { $replData: 1, $oplogQueryData: 1, $readPreference: { mode: "secondaryPreferred" } } active: 1 findNetworkTimeout: 7000ms getMoreNetworkTimeout: 10000ms shutting down?: 0 first: 1 firstCommandScheduler: RemoteCommandRetryScheduler request: RemoteCommand 2272962 -- target:mongo03:27017 db:local cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565585502, 204) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, batchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565585502, 204), t: 9 } } } active: 1 callbackHandle.valid: 1 callbackHandle.cancelled: 0 attempt: 1 retryPolicy: RetryPolicyImpl maxAttempts: 1 maxTimeMillis: -1ms

I'm a little bit lost regarding how to debug it. It's a 250GB database, the synchronization is being done through a private network 100Mb. There is an iptables in all servers but the traffic from the private network is allowed:

-A INPUT -i eth1 -p tcp -m tcp --dport 27017 -m state --state NEW,ESTABLISHED -j ACCEPT

At some point the replication process fails:

2019-08-12T02:22:37.582+0200 I REPL [replication-143] Restarting oplog query due to error: ExceededTimeLimit: error in fetcher batch callback: Executor error during find command :: caused by :: errmsg: "oper ation exceeded time limit". Last fetched optime (with hash): { ts: Timestamp(1565569328, 710), t: 9 }[7908135344534364729]. Restarts remaining: 1 2019-08-12T02:22:37.582+0200 I REPL [replication-143] Scheduled new oplog query Fetcher source: mongo03:27017 database: local query: { find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565569328, 710) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, batchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565569328, 710), t: 9 } } } query metadata: { $replData: 1, $oplogQ ueryData: 1, $readPreference: { mode: "secondaryPreferred" } } active: 1 findNetworkTimeout: 7000ms getMoreNetworkTimeout: 10000ms shutting down?: 0 first: 1 firstCommandScheduler: RemoteCommandRetryScheduler re quest: RemoteCommand 1381614 -- target:mongo03:27017 db:local cmd:{ find: "oplog.rs", filter: { ts: { $gte: Timestamp(1565569328, 710) } }, tailable: true, oplogReplay: true, awaitData: true, maxTimeMS: 2000, ba tchSize: 13981010, term: 9, readConcern: { afterOpTime: { ts: Timestamp(1565569328, 710), t: 9 } } } active: 1 callbackHandle.valid: 1 callbackHandle.cancelled: 0 attempt: 1 retryPolicy: RetryPolicyImpl maxAttem pts: 1 maxTimeMillis: -1ms 2019-08-12T02:22:39.612+0200 I REPL [replication-142] Error returned from oplog query (no more query restarts left): ExceededTimeLimit: error in fetcher batch callback: Executor error during find command :: caused by :: errmsg: "operation exceeded time limit" 2019-08-12T02:22:39.615+0200 I REPL
[replication-142] Finished fetching oplog during initial sync: ExceededTimeLimit: error in fetcher batch callback: Executor error during find command :: caused by :: errms g: "operation exceeded time limit". Last fetched optime and hash: { ts: Timestamp(1565569328, 710), t: 9 }[7908135344534364729] 2019-08-12T02:22:43.034+0200 I REPL [replication-142] CollectionCloner ns:DB.CollectionName finished cloning with status: IllegalOperation: AsyncResultsMerger killed 2019-08-12T02:22:44.551+0200 W REPL [replication-142] collection clone for 'DB.CollectionName' failed due to IllegalOperation: While cloning collection 'DB.CollectionName' there was an error 'AsyncResultsMerger killed' 2019-08-12T02:22:44.551+0200 I REPL
[replication-142] CollectionCloner::start called, on ns:DB.CollectionName2 2019-08-12T02:22:44.551+0200 W REPL [replication-142] database 'dbName' (9 of 9) clone failed due to ShutdownInProgress: collection cloner completed 2019-08-12T02:22:44.551+0200 I REPL
[replication-142] Finished cloning data: ShutdownInProgress: collection cloner completed. Beginning oplog replay. 2019-08-12T02:22:44.551+0200 I REPL [replication-142] Initial sync attempt finishing up.

And it has to start over again.

Don't know if I could configure a bigger time out to avoid this disconnections.

Thanks in advance.

I started a mongodb master slave, but due to technical issues the slave server crashed. I restarted it and the mongod proccess as well with the host parameter, but for some reason the slave isn't replicating the data which was created when it was down. How can I tell the slave to get in sync with the master, including the existing data?

I am setting up replication on SQL Server 2017. Transaction replication with push subscriptions such that many smaller database are replicated into a single larger database for reporting.

The snapshots wouldn't initialize for some tables in some databases because of "field size too small" errors. The tables had the same "schema" in that they had all the same fields with the same datatypes and primary key. However, the ordinal position of the columns varies for some of the tables in question between databases. I think the snapshots wouldn't initialize because the bcp command it uses expects the tables' columns to be in the same order. Two questions

1) Can anyone confirm that the the ordinal position matters for replication as far as snapshots initializing goes? It makes sense to me that it would but I can't find anything that says that it does explicitly.

2) If initialize the Subscription Manually (allowing me to skip the snapshot initialize step) would replication work with the ordinal position of the columns being different for the tables but otherwise being identical? Is this supported or do I need to reorder all the columns to make sure they are the same?

I want to use Redis Master-slave feature for replication between active and backup servers. But I want to know how the master-slave communication works? Because I have limitations in production, I cannot use Master-Slave configuration if Master makes TCP connections with the slave.