MySQL Trigger (Pro) node for n8n

A real-time, event-driven MySQL Trigger node for n8n. This node leverages MySQL's binary logs (CDC / Change Data Capture) via the replication protocol, providing instant execution triggers without the latency or database overhead of polling.

Compared to a basic binlog trigger, this version is built to survive against a real production database: it keeps its control connection alive so it doesn't leak replication threads on reconnect, uses a stable replica ID, backs off on failures instead of hammering the server, and never opens a live replication stream just because you clicked "Test workflow".

Features

• True Real-time Triggers (CDC): Powered by MySQL Binlog replication protocol. Triggers instantly upon table changes.
• Flexible Event Monitoring: Listen specifically for INSERT, UPDATE, and DELETE actions (or any combination of them).
• Granular Filters: Filter events by specific databases and comma-separated tables.
• Data States: Provides the full event payload, including both the "before" and "after" row states for UPDATE events.
• Auto-Reconnect & Fault Tolerance: Robust handling of protocol disconnects and connection losses with auto-retries.

Installation

From the n8n UI (Community Nodes)

1. Go to Settings > Community Nodes.
2. Click Install a community node.
3. Enter the package name:

   n8n-nodes-mysql-trigger-pro

4. Check the agreement box and click Install.

MySQL Server Configuration (CDC Prerequisites)

Because this node acts as a replication replica to stream binlog events, your MySQL server must have binary logging enabled and configured for Row-Based Logging (RBL).

1. Enable Row-Based Binlogs

Add the following configuration to your MySQL configuration file (e.g., my.cnf or mysqld.cnf) under the [mysqld] section:

[mysqld]
server-id         = 1
log-bin           = mysql-bin
binlog-format     = ROW
binlog_row_image  = FULL

Restart your MySQL server to apply the changes:

sudo systemctl restart mysql

2. Create database user with Replication privileges

The user credentials used by the trigger node must have replication slave and replication client privileges. Run the following SQL queries as root:

CREATE USER 'n8n_cdc_user'@'%' IDENTIFIED BY 'your_secure_password';

-- Grant required replication permissions
GRANT REPLICATION SLAVE, REPLICATION CLIENT, SELECT ON *.* TO 'n8n_cdc_user'@'%';

FLUSH PRIVILEGES;

Parameter Configuration

Connection details (host, port, user, password, database) come from the standard n8n MySQL credential. The user must have the REPLICATION SLAVE privilege.

• Table Names or IDs: Tables to watch, picked from a list loaded from your database. Leave empty to watch every table.
• Events: Multi-select option to trigger on Insert, Update, and/or Delete events.

Options

| Option | Default | What it does | | --- | --- | --- | | Keepalive Interval (Seconds) | 30 | Pings the control connection so MySQL's wait_timeout cannot close it. Letting it close forces a full reconnect of a healthy stream. 0 disables. | | Replica Server ID | 0 (auto) | How MySQL identifies this client as a replica. Derived from the node automatically. Two replicas sharing an ID repeatedly kill each other's stream. | | Batch Window (Seconds) | 0 | Collects events and emits them as one execution. 0 emits immediately, which means one execution per changed row during a bulk update. | | Max Events Per Execution | 100 | Flushes the batch early once this many rows accumulate. | | Start Position | End of Binlog | Where to start reading: end of log, resume from the last processed position, or the beginning. | | Test Mode | Emit Sample Data | What "Test workflow" does. The default builds a sample row from the table schema and puts no replication load on the database. | | Test Timeout (Seconds) | 60 | How long a "Wait for Real Event" test waits before giving up. | | Max Reconnect Attempts | 0 | Gives up after this many consecutive failed reconnects. 0 is unlimited. | | Max Reconnect Delay (Seconds) | 300 | Ceiling for the exponential reconnect backoff. | | Include Old Values | true | Includes the pre-update row as oldData on update events. |

Running against a production database

The defaults are chosen to be safe, but two are worth reviewing before activating against production:

• Keep Keepalive Interval enabled. It is what prevents the reconnect cycle that otherwise leaks a Binlog Dump thread on the server every time the connection times out.
• Set a Batch Window if watched tables receive bulk writes, so a migration cannot turn into one workflow execution per row.

To confirm the trigger is behaving, a healthy instance holds exactly one dump thread:

mysql -e "SELECT id, user, time, state FROM information_schema.processlist WHERE command = 'Binlog Dump';"

Output Schema Example

The node outputs a structured JSON array representing the event payload:

INSERT event:

[
  {
    "action": "insert",
    "database": "my_store",
    "table": "users",
    "timestamp": 1718873099,
    "data": {
      "id": 42,
      "email": "[email protected]",
      "created_at": "2026-07-06T12:00:00Z"
    }
  }
]

UPDATE event (Includes Before/After):

[
  {
    "action": "update",
    "database": "my_store",
    "table": "users",
    "timestamp": 1718873105,
    "data": {
      "id": 42,
      "email": "[email protected]",
      "created_at": "2026-07-06T12:00:00Z"
    },
    "oldData": {
      "id": 42,
      "email": "[email protected]",
      "created_at": "2026-07-06T12:00:00Z"
    }
  }
]

License

MIT