MySQL Replication – Issues with Triggers

MySQLreplicationtrigger

MySQL master has a table Products that has triggers on update and delete. Deleted/Updated records are stored in ProductsUpdatedDeleted tab.

When a record is deleted, the operation is replicated to the slave server. The issue is that slave also executes the trigger thus adding a record in its ProductsUpdatedDeleted table. Then a duplicate record in ProductsUpdatedDeleted received from the master server through replication.

What is the best way to stop the slave to execute triggers? I can comment trigger code in the slave but I would prefer both servers in the same state to quick failover.

Best Answer

Basically, there are two methods

METHOD #1

Use row-based replication. It says so in Paragraphs 1-3 of "Replication and Triggers"

With statement-based replication, triggers executed on the master also execute on the slave. With row-based replication, triggers executed on the master do not execute on the slave. Instead, the row changes on the master resulting from trigger execution are replicated and applied on the slave.

This behavior is by design. If under row-based replication the slave applied the triggers as well as the row changes caused by them, the changes would in effect be applied twice on the slave, leading to different data on the master and the slave.

If you want triggers to execute on both the master and the slave—perhaps because you have different triggers on the master and slave—you must use statement-based replication. However, to enable slave-side triggers, it is not necessary to use statement-based replication exclusively. It is sufficient to switch to statement-based replication only for those statements where you want this effect, and to use row-based replication the rest of the time.

METHOD #2

Drop all the triggers on the Slave. No trigger present, no trigger to execute.

Do not do both method. Just select one method.

Related Solutions

Mysql – Keeping 2 tables in sync

If you have this scenario

table_a has an auto_increment field
table_b and table_c have table structure identical to table_a
You are running MySQL 5.1+

you can create a Stored Procedure and a MySQL event instead of a Trigger

For the sake of example, let's say table_a looks like this:

CREATE TABLE table_a
(
    id not null auto_increment,
    ....
    primary key (id),
);

Create a Stored Procedure on the Slave to Copy Data to table_b and table_c

DELIMITER $$ 
DROP PROCEDURE IF EXISTS `Load_New_Data` $$ 
CREATE PROCEDURE `Load_New_Data` () 
BEGIN
    DECLARE min_id,min_idb,mid_idc INT;

    SELECT MAX(id) INTO min_idb FROM table_b;
    SELECT MAX(id) INTO min_idc FROM table_c;
    SET min_id = IF(min_idb < min_idc,min_idb,min_idc);

    DROP TABLE IF EXISTS table_a_delta;
    CREATE TABLE table_a_delta SELECT * FROM table_a WHERE 1=2;
    INSERT INTO table_a_delta SELECT * FROM table_a WHERE id >= min_id;
    INSERT IGNORE INTO table_b SELECT * FROM table_a_delta;
    INSERT IGNORE INTO table_c SELECT * FROM table_a_delta;

    DROP TABLE table_a_delta;
END $$ 
DELIMITER ;

Then, schedule a MySQL Event on the Slave for the Stored Procedure to go off every 5 minutes starting 5 minutes after you create the event:

CREATE EVENT ev 
    ON SCHEDULE 
      EVERY 5 MINUTE 
      STARTS (NOW() + INTERVAL 5 MINUTE) 
    DO 
      CALL Load_New_Data();

Don't forget to Add This to the Slave's /etc/my.cnf

[mysqld]
event_scheduler=1

Mysql – Created databases and inserted data on MySQL slaves in Master-Slave replication – how to fix

You say:

databases have been created on the slaves and filled with data.

The easiest way of correcting this is to take a mysqldump of the specific databases on the slave, drop the database on the slave, and import the dumpfile onto the master. The slaves will then replicate the data.

This of course gets trickier if it is not whole databases or even tables (but specific rows inside a table).