Question

I have a table with 15 million rows. At some point in the day I run a query that deletes about 2 million of those rows. It was taking about 30 minutes to run which as per the mysql admin was slowing down the replication for the whole instance.

I thought I could convert it in to a stored procedure that commits every 1000 rows but it seems replication still gets stuck until my whole stored procedure finishes. It would be possible to do the outside of mysql but I would really like to try and do this inside mysql. This is what I have…. Is there a way to make this more replication friendly.

BEGIN
   DECLARE rowcount INT;
   REPEAT   
      DELETE FROM tbl_sales_records WHERE salesFileNo = PassedInValue LIMIT 1000;
      SELECT ROW_COUNT() INTO rowcount;
      COMMIT;
   UNTIL rowcount=0
   END REPEAT;
END$$

Answer 1

One strategy I use for queries like this is to keep them out of the binary log, and run them separately on the replication master and the replication slave(s). That way they will not block the replication, assuming the delete does not cause any locks that block other statements.

In order to do this you need to run the commands as a user with the SUPER privilege, and you need to be careful to make sure you delete the exact same data on the master and the slave(s) to avoid inconsistency but it can be a very useful technique.

The key is to use the SQL_LOG_BIN setting to disable binary logging for the session in which you run the delete.

For example:

SET SQL_LOG_BIN = 0;
DELETE FROM tbl_sales_records WHERE salesFileNo = PassedInValue;

Or if you are using a stored procedure you can still disable binary logging the same way:

SET SQL_LOG_BIN = 0;
CALL your_delete_proc();