Is there any way to find the exact Query responsible for replication lag? I've tried checking slowquery.log and binlog.

Slow query log kind of helps but not all the time.

Binlog entries are inaccurate. I used the following command to check binlog.

show binlog events in &lt;binlog name&gt; from &lt;log position&gt; limit &lt;n&gt;;
log_slow_slave_statements = ON in the Slave's my.cnf.  Also long_query_time=1.  Turn on the slow log; wait a day; look in the slowlog.  mysqldumpslow -s t or pt-query-digest will summarize the slowlog, putting the 'worst' query first.

(From the Changelogs)
----- 2013-04-23 5.7.1 Milestone 11 &amp; 2013-04-18 5.6.11 -- Bugs Fixed -- -----


  The --log-slow-admin-statements (
  http://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_log-slow-admin-statements
  ) and --log-slow-slave-statements (
  http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_log-slow-slave-statements
  ) command options now are exposed at runtime as the
  log_slow_admin_statements (
  http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_slow_admin_statements
  ) and log_slow_slave_statements (
  http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_log_slow_slave_statements ) system variables. Their values can be examined using SHOW VARIABLES
  ( http://dev.mysql.com/doc/refman/5.7/en/show-variables.html ). The
  variables are dynamic, so their values can be set at runtime. (The
  options were actually replaced by the system variables, but as system
  variables can be set at server startup, no option functionality is
  lost.) (Bug #59860, Bug #11766693)


In older versions, the command line --log-slow-slave-statements existed even though the variables did not.