I have a REMOTE suppliers' table with, let's say, a code and a name, and several client databases will be creating new suppliers.

Server database

code  |  name
------+-------
1     |  Mark
2     |  John
3     |  Jodie

I thought that a federated table would fit the best, as every client could create new suppliers in a centralized table which assigns incremental codes,

Obviously, if the Internet connection is down, clients won't be able to create new suppliers, so this won't work for me.

I thought that the best idea would be assigning a prefix to each client, and the code count would be assigned locally.

Local table client A

code   |  name
-------+------
A1     |  Mark
A2     |  Jodie

Local table client B

code  |  name
------+------
B1    |  John

Then, the data would be merged into a single remote table.

Remote merged table

code  |  name
------+---------
A1    |  Mark
B1    |  John
A2    |  Jodie

But at this point, I am lost, I don't know if there is a solution for this problem, or I would need to merge them with a cron job + script.

Maybe a multiple-masters-to-1-slave would work?

Is there any way to schedule merge jobs?

Any idea would be appreciated.

Received an error mentioned below after failover when mirror partner is down.

Error :

to fail over to a database which is not configured for database mirroring. code: 22037, text: 'Invalid connection string attributeCannot open database "DBName" requested by the login. The login failed.Login failed for user 'domain\user'.The connection attempted to fail over to a database which is not configured for database mirroring.'.

Scenario :

1. X is a Principal server and Y is a mirror partner of X
2. X is a publisher too, Z is a distributor server
3. Z is added as distributor in X and Y Server. X and Y added as publisher in Z server too
4. Configured Y as a "PublisherFailoverPartner" in replication log reader agent profile setting
5. Did failover of X
6. Thereafter Y became a principal and X became mirror partner
7. Break mirror from Y to X or X server is down and unavailable

After above steps performed, replication is started to throw an error. When mirror is ON the replication is working, otherwise it raising an error mentioned.

Can you please suggest me steps to resolve it?

I got hired into a new company and they had merge replication already in place. They have had issues with it to the point I have to evaluate whether to keep it or replace it. The main issue is it takes many hours (over 12 hours in some cases) to insert or update a record. Honestly that is just unacceptable.

As an example I am trying to insert one record into a table (ComputerUsers) that links a laptop to a user. You only have two columns (one is call ComputerID and one is called UserID). There is a Computers table that stores the ComputerIDs and the Computername. There also is a Users table that stored the UserID and username.

All I am trying is insert one record into the ComputerUsers table. Last time I ran it it took over 13 hours. This table is published and it is part of the Dynamic Filter.

I have tried everything I have read online. I created two separate indexes for the UserID and ComputerID columns since they are both included in separate joins in the Filter. There is also a clustered primary key on the Userid and ComputerID columns since the combination of the two are unique (A computer can be assigned to two users or vica versa). I have also have tried rebuilding the indexes and even created some suggested indexes on the merge replication tables.

I am at my wit's end. What am I missing? I find it hard to believe this is normal for Replication because I doubt anyone would use it if it was. Thanks.

Having a merge publication for replicating BLOBs (type image), got very high tempdb disk I/O for my size of data. Publication is download-only and has no filters.

High disk I/O is caused by synchronization (when no subscribers are synchronizing, everything is ok), strongly correlated with number of subscribers. It happens even when no data is changed at Publisher between synchronizations, and that bothers me.

• Size of replicated table: 7MB (total count of rows is about 100)
• tempdb I/O : ~30 MB/sec for write (log and data files)
• Number of subscribers: slightly over 100, each synchronizing every 30 minutes (more or less evenly).
• Retention period set to 14 days

Using SQL Server 2008 at Publisher, SQL Server 2005-2008R2 at Subscribers. All subscribers use Web Synchronization.

Additionally, synchronization at subscriber takes a lot of time, with multiple occurrences in replmerg.log like these:

DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload     

DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload

Tried setting @stream_blob_columns on and off with no effect.

The question is: Is it a good idea to use merge replication to send these blobs to subscribers? We have other publications (though they have no BLOB columns) with a lot of data without tempdb problem. Is it an SQL Server flaw, or bad setup?

Publisher and Distributor are on the same instance, SQL Server 2008 SP4, cannot be sure about Subscribers, some of them maybe not up-to-date. Anyway, I can prepare a test environment with few subscribers having controlled versions, if it seems to help.

Confirmed, that excessive tempdb usage caused by execution of sys.sp_MSenumgenerations90. Checked MSMerge_genhistory table, found over 1.2 millions of records where pubid is null.

Found this conversation with replication guru:

Executed sp_mergemetadataretentioncleanup with no effect.

Found a remark on a case like this (too much rows in MSmerge_genhistory) where deleting rows where pubid is null and genstatus=1 helped to fix replication.

Deleted rows where pubid is null (implying that all Subscribers are synchronized, and which are not - will be reinitialized in "manual mode") and disk IO is back to normal again!

I have a feeling, that this situation could be caused by the fact, that all of my Subscribers are anonymous via WebSync and most of them have the same hostname. I'll try to check, if -hostname key helps not to multiply records in MSmerge_genhistory.

I need to perform a delicate operation to my table in which I will solely insert, delete and select upon all of my rows and no God may interfere with the table during this operation: the table will be in an inconsistent state and any concurrent MySQL session shall not be allowed to modify it until commit-ed.

The use of SELECT ... FOR UPDATE | LOCK IN SHARE MODE is not suitable because, while it may potentially be used to lock all the rows in the table, it won't prevent the insertion of further rows by a concurrent session. Basically, I need to LOCK TABLES my_table WRITE within the body of a transaction.

The table contains about 20,000 rows and a master-slave, mixed-format replication is in place over a slow connection so, for any workaround, I'd prefer to avoid using temporary tables which may faint the slave, and the amount of data dumped into the binlog should ideally be minimized.

The engine is InnoDB on MySQL 5.6, for both master and slave.

XY Problem background info:

I have a pull replication publisher in which I want to add or alter a index and have those changes be applied to the subscriber.

The solution to that problem I would like to do is to generate a new snapshot and re-init the subscription.

My Question:

How do I, from the publisher, mark a pull merge replication publication as having a invalid snapshot such that if I did sp_helpmergepublication the snapshot_ready column would return 0.

Doing exec sp_reinitmergesubscription @upload_first = 'true' will cause the subscriber to re-initialize but it does not mark the snapshot as invalid.

I know I could change a publication or article property then change it back and cause to invalidation to happen that way but I would really like to invalidate as the "primary action" instead of having the invalidation be a side effect of some other action.

I am looking for something similar to transactional replication's sp_reinitsubscription procedure which has a @invalidate_snapshot parameter, but I could not find the equivalent for merge replication.

Is there any way to invalidate a merge replication snapshot only without making some other kind of change that has snapshot invalidation as a side effect?

CRUD replicates just fine. But we noticed that DB structure altering commands such as ALTER TABLE and/or adding/updating columns to a table and even creating new ones do not replicate to the slave at all.

Setup

This is the content of our my.cnf files:

Replication Setup A

• Where: (master) Mysql 5.5.40> (slave) MariaDB 10.0.19

Master:

server-id = 1002
binlog-do-db = db_1
binlog-do-db = db_2
binlog-do-db = db_3
sync_binlog = 1
expire_logs_days = 30
innodb_flush_log_at_trx_commit = 1

Slave:

server-id = 1005
replicate-do-db = db_1
replicate-do-db = db_2
replicate-do-db = db_3
slave-parallel-threads=4
slave_compressed_protocol = ON
slave-skip-errors = all
log-slave-updates = ON

Strangely, DB structure altering commands works just fine on a different server pair with an *almost similar replication setup:

Replication Setup B

• Where: (master) MariaDB 10.0.17> (slave) MariaDB 5.5.41

Master:

server-id = 1004
bind-address = "0.0.0.0"
binlog-do-db = db_a
binlog-do-db = db_b
binlog-do-db = db_c
binlog-do-db = db_d
binlog-do-db = db_e
binlog-do-db = db_f
binlog-do-db = db_g
sync_binlog = 1
expire_logs_days = 30
innodb_flush_log_at_trx_commit = 1

Slave:

server-id = 1003
bind-address = "0.0.0.0"
replicate-do-db = db_a
replicate-do-db = db_b
replicate-do-db = db_c
replicate-do-db = db_d
replicate-do-db = db_e
replicate-do-db = db_f
replicate-do-db = db_g
slave_compressed_protocol = ON
slave-skip-errors = all

Notes for both replication pairs:

• Names of the databases were obscured.
• Parts of the my.cnf file where i think replication is configured are only posted.

Questions

1. Is this a bug or an undocumented feature?
2. Did i do something wrong on my setup?
3. What could be other factors that might effect to this behaviour?
4. If there really are (query)commands that aren't supported for replication, what are these?
   • 4.a) Mysql/MariaDB version setups that has the same effect?

I tried looking at the error logs of the slave for any hints and used structure altering query commands as search keywords but to no avail. Maybe I'm not looking in the right direction?

Update (2015-06-04)

Further testing ensued. As suggested by this SO post, I might have to remove or comment out replicate-do-db from my.cnf; So I did and I found out that:

• Creating a new table is replicated.
• Altering a table is not replicated.
• CRUD transactions were not replicated.

Also, things just got stranger for Replication Setup B where everything was just supposed to work.

• One DB failed to replicate an ALTER TABLE command just yesterday and we only found out about it now.
• After the incident, I tried testing executing ALTER TABLE commands to all other DBs of the same server and it replicated just fine. In this test, I am unable to remove replicate-do-db from my.cnf as restarting the server is currently not an option.

I am configuring transactional replication in SQL Server. The subscription is configured as push from 2008R2 publisher (distributor is the same server) to 2012 subscriber.

The object I want to replicate is an indexed view. The base tables exist only on the publisher.

The replication fails due to the following error:

Unable to replicate a view or function because the referenced objects or columns are not present on the Subscriber

It is true that the view doesn't exist in the subscription database. How can i create it without the base tables?

I have a transactional Replication (Non-SQL Server Publishers - Oracle) implemented for one SQL Server Database. Let's say Publishers: A, B Subscriber: C

Note:

• I can not modify the Oracle DBs.
• The Publishers have the same DB schema.
• On the subscriber I have the same tables, with one column more "Publisher" to identify where that line comes from.

I used the After-Snapshot Script to create and populate this column for the Initial Load for the Publisher A.

Also, created a (After-Snapshot) script for the publisher B to populate the column.

It works when I do the first snapshot for A, and my bulkload fails for B with the following error:

Replication-Replication Distribution Subsystem: agent AgentName failed. The process could not bulk copy into table '"dbo"."EMployees"

Error Log: Error: 14151, Severity: 18, State: 1.

Replication Monitor Source: MSSQL_REPL, Error number: MSSQL_REPL20037)

Anyone has an idea? Is it due the schema difference between B and C, since when the A does the bulkload there is no table and first I create the table, then do the initial load, the do the alter table to add the column, update values to be ready for the second bulk load?

I have a master/slave replication setup based on statement based replication. On master database named DB1, I have 5 tables and I want to replicate only two table on slave's database named DB2.

Also, I want to change the database name on my slave end.

So my configuration file on Slave end look like this and replication filtering is this:

   replicate-rewrite-db="DB1->DB2"
   replicate-do-table=DB2.table4
   replicate-do-table=DB2.table5

Also I have tried below filtering as well:

   replicate-rewrite-db="DB1->DB2"
   replicate-do-table=DB1.table4
   replicate-do-table=DB1.table5

But in both case records not getting replicated , also no error is reporting.

As per MySQL documentation , replicate-rewrite-db doesn't work with replicate-do-table.

Any method to resolve this? Or is this not possible?

I'm using MySQL 5.6 community edition on Linux server.

I haven't made any changes to master end as it is on customer side.

I am using MariaDB 10.0 multi-source replication for a specific use case.

For security reasons, I would like to prevent ALTER commands on master to replicate (such as CREATE, ALTER, DROP...) whatever user run these commands (even root) but of course let SELECT, INSERT, UPDATE, DELETE commands to replicate....

I do not want to use SET SQL_LOG_BIN=0|1 on client side. In fact, I never want to replicate schema modification.

In practice, I wish I could revoke alter permissions to my replication user (who currently has REPLICATION SLAVE permission)

Is there a way to achieve this?

I need to move my distributor server to a brand new server without resnapshotting it. The scenario I have is similar to the one defined in below link.

http://www.sqlservercentral.com/Forums/Topic844095-291-1.aspx

Environment:

1 publisher 1 distributor 4 subscribers Replication type: Transactional replication with updatable subscription

I want to know if someone has tried the solution given in above link or if you have any alternate solution.

I have an implementation doubt regarding replicating data between SQL Server 2014 database servers (Replicating data from Local Premises SQL Server to Cloud DB Server, which are not in same domain or VPN).

May I request you to please advise a solution, to achieve this data transfer push from Local DB Server to Cloud DB Server.

I will elaborate the scenario over here, what we are trying to achieve.

SCENARIO

My client has an ETL application developed in .NET which uses SQL Server as a backend.

They have their Live SQL Server hosted on a cloud provider (not Microsoft Azure)

They are opening up a new branch which does not have a leased line, since the area is on outskirts of the city. This new branch will have almost 1500 users who will make entries to a locally hosted application which will use local DB Server.

They have 2 SQL Servers:

1. SQL Server 2014 Web Edition Database on Cloud (not Azure)
2. SQL Server 2014 Standard Edition with same Application database on Local Premises

They need to push the data entries inserted in local DB Server Database named as LabProdData to the Cloud DB Server Database LabProdData, so all other branches can refer to this branch data, with a certain delay of 30 minutes or less.

What are the options to implement this scenario?

SOLUTION PROPOSED

I have proposed a solution of ETL creation to open up a SQL Port on the Cloud DB server to facilitate communication to Local DB Server and to push data to the Cloud DB Server But, this will be quite hectic to develop multiple ETL's since the number of tables are more. Also, the Deletion and Updation of Data needs to be tracked and Synced, which will add up complexity

My client is bit hesitant about opening the port on Cloud DB Server, since this can be vulnerable to threats.

REQUEST SOLUTION

My doubts are:

1. Can we use SQL Server Replication to replicate the data between Local SQL Server and Cloud DB Server, with no Active Directory or no common domain?
2. If yes, how do we implement this scenario using SQL Server Replication?
3. Is there any other way to implement this scenario, other than Replication? Can you please suggest.
4. Can Replication or Database Mirroring help here
5. Can SQL Server Replication support this with 2 DB Servers of same version but one is Web Edition and other is Standard. We need to push data from Standard Edition to Web Edition.
6. How can the communication be implemented between both these servers? Note: Network Domain or Active Directory do not exists.

Please do let me know if you need any further details to understand the problem statement. Eagerly awaiting for your reply.

For various reasons I need one of the databases from intranet MySQL server to be made available to (insecure) online server. Due to the requirements it was decided that a db dump will be used via cron to transfer data as the firewall does not allow any connections to be initiated from outside. Then MySQL Master-Slave solution was suggested. From what I have understood, the slave should be able to connect to the master via (preferably insecure) TCP protocol. Such a solution is preferable, however, via secure TCP connections without permitting the slave to initiate (possibly lost) connections to the master.

I would like to know if it is possible to have Master-Slave replication via secure TCP where connections are always initiated by the Master to the slave. The use case does not require too much data transfer, and data base size is within 5GB on a 1GBPS intranet. It is acceptable that there could be some delay in updating to the slave.

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!

Our setup:

• Master: MariaDB 10.0.21
• Slave: MariaDB 10.0.17

Replication was working fine until recently at which point the slave's DBs had to be restored from a dump. I performed all of the necessary steps: Dump the master's DBs, transfer the dump to the slave, drop the old DBs, execute the dump to restore the DBs, execute the appropriate CHANGE MASTER command, and finally START SLAVE.

I am receiving the error:Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

The first log file that the slave needs from the master is mysql-bin.000289. I can see that this is present on the master:

I can also see that the binary log index on the master seems to have an entry for this log file:

Still replication is not working - I keep getting the same error. I'm out of ideas - what should I check next?

Updated: Output of SHOW SLAVE STATUS\G as requested:

MariaDB [(none)]> SHOW SLAVE STATUS\G
--------------
SHOW SLAVE STATUS
--------------

*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: replication
                  Master_Port: 1234
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000289
          Read_Master_Log_Pos: 342
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000289
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxx_yyy,xxx_zzz
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 342
              Relay_Log_Space: 248
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Additional requested information:

root@master [818 18:54:22 /var/lib/mysql]# ls -l /var/lib/mysql/mysql-bin.000289
-rw-rw---- 1 mysql mysql 1074010194 May 19 03:28 /var/lib/mysql/mysql-bin.000289
root@master [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
root@master [821 18:56:52 /var/lib/mysql]# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6345382
Server version: 10.0.21-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |
| mysql-bin.000283 | 1073742000 |
| mysql-bin.000284 | 1074219591 |
| mysql-bin.000285 | 1074184547 |
| mysql-bin.000286 | 1074217812 |
| mysql-bin.000287 | 1022733058 |
| mysql-bin.000288 |     265069 |
| mysql-bin.000289 | 1074010194 |
| mysql-bin.000290 | 1074200346 |
| mysql-bin.000291 |  617421886 |
| mysql-bin.000292 |     265028 |
+------------------+------------+
14 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
root@master [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
root@master [822 18:58:13 /var/lib/mysql]# tail /tmp/somefile.txt 
# at 1074010124
#160519  3:28:59 server id 5  end_log_pos 1074010151    Xid = 417608063
COMMIT/*!*/;
# at 1074010151
#160519  3:28:59 server id 5  end_log_pos 1074010194    Rotate to mysql-bin.000290  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@master [823 18:58:31 /var/lib/mysql]# 

/etc/my.cnf.d/server.cnf (excerpt):

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

Edit: Postion 342 does seem to exist:

root@master [826 12:15:33 /var/lib/mysql]# grep "end_log_pos 342 " /tmp/somefile.txt
#160517 14:43:13 server id 5  end_log_pos 342   Binlog checkpoint mysql-bin.000288

I had an unforeseen issue with a sub going down (generic error, was probably a connection issue) and now that I've reconnected the sub it is insanely slow re-syncing. It seems to download about 1000 changes then sit there for about an hour before adding another 1000.

Any ideas why this is going so slowly? This is just one table of dozens and I feel like this won't catch up before Monday (when I have users meant to be coming online).

Any help is appreciated! Thanks!

UPDATE

It's been running for over 24 hours now and is slowly chewing through the records but at a still very slow pace. It now toggles between the shot above and 'Enumerating changes in filtered articles using Subscriber's assigned partition ID'. Yes, there is a filter in place but it's been there since I first set up replication and has never caused an issue before.

SECOND UPDATE

When I go into Replication Monitor there is an error:

The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

But what is strange is that there is zero system activity and I have another subscriber on this publication working as well a secondary replication from the same publisher to the same subscriber that is working perfectly. I've tried stopping and restarting, taking and applying a fresh snapshot but nothing seems to work. There are no blocked processes, no active queries that are deadlocking or anything else I can think to check.

To be clear:

• Publication A => Sub 1: WORKING
• Publication A => Sub 2: NOT WORKING
• Publication B => Sub 1: WORKING
• Publication B => Sub 2: WORKING

If anyone has any help, I'd much appreciate it.

(Hi; sorry for my English) My question is: how can I restart MySQL replication on a slave server. At first sight everything seems to be normal but when I check with

SHOW SLAVE STATUS\G

besides Relay_Log_Space, Read_Master_Log_Pos and Seconds_Behind_Master which continue to increase. Other data remain fixed for several days. I tried STOP/START SLAVE; but nothing has changed.

root@localhost [mysql]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: x.x.x.x
                  Master_User: slave_replicator
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000103
          Read_Master_Log_Pos: 197827259
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 149672940
        Relay_Master_Log_File: mysql-bin.000029
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 305160334
              Relay_Log_Space: 65277287216
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 1724670
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 3464562
                  Master_UUID: 727b7e74-325f-11e6-9b54-faa1cd739fa9
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Reading event from the relay log
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0

I am getting no errors yet replication is not working . wonder where i am going wrong My master status is

            File: mysql-bin.000002
        Position: 2006432
    Binlog_Do_DB: site3,site2
Binlog_Ignore_DB: 

My Slave Status is

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 104.131.119.241
                  Master_User: drupal
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 2006432
               Relay_Log_File: mysqld-relay-bin.000003
                Relay_Log_Pos: 2006577
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: site3,site2
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 2006432
              Relay_Log_Space: 2006879
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
1 row in set (0.00 sec)

We have recently implemented an Attunity replication between 2 servers (From Oracle -> to MSSQL).

Sometimes, we are facing high latency / incoming changes between the 2 servers.

and most of the time we can observe (on SQL Server) a query from attunity program, on a specific table, blocking users queries :

When the query complete, there is no more latency between servers.

According to sp_woisactive, the query is in RUNNABLE state. Trying to start a select on the lock table, my query is blocked, waiting for the attunity query to end.

If we stop attunity replication, the query end and all other transactions runs fines.

Have you Any ideas why this query is taking so much time ? How can I diagnostic this ? it's just a delete on a specific id. Moreover, Indexes are all up to date and there is no fragmentation.