MySQL 8.4 GTID Replication: Setup, Failover & Monitoring Guide

Binlog position-based replication breaks in exactly the wrong moments — during failovers, when you need to promote a replica, or after a crash. MySQL 8.4's GTID replication eliminates this fragility entirely. Here's how to set it up correctly and avoid the common configuration mistakes that cause data loss.

TL;DR

GTID assigns each committed transaction a globally unique ID, making replication position-independent
Failover and replica promotion become deterministic — no manual binlog position lookup
MySQL 8.4 adds gtid_mode=ON as a live, non-disruptive change for the first time
Common pitfalls: non-transactional DDL, temporary tables, and CREATE TABLE ... SELECT

How GTIDs Work in MySQL 8.4

A GTID (Global Transaction Identifier) is a unique ID assigned to each transaction committed on the primary: source_uuid:transaction_sequence_number. For example: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100 means the first 100 transactions from that server UUID.

The replica tracks which GTIDs it has executed (gtid_executed) and requests from the primary all GTIDs it hasn't seen yet. No binlog file or position needed.

Enabling GTID Mode

ini

# /etc/mysql/mysql.conf.d/primary.cnf
[mysqld]
# GTID settings
gtid_mode                  = ON
enforce_gtid_consistency   = ON

# Required for GTID replication
binlog_format              = ROW
binlog_row_image           = FULL
log_bin                    = /var/lib/mysql/binlog
server_id                  = 1

# Retain binlog long enough for slow replicas
binlog_expire_logs_seconds = 604800  # 7 days

Setting Up GTID Replication

sql

-- On replica: configure GTID-based replication
STOP REPLICA;

CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = 'primary.db.internal',
    SOURCE_PORT = 3306,
    SOURCE_USER = 'repl_user',
    SOURCE_PASSWORD = 'strong_password',
    SOURCE_AUTO_POSITION = 1;  -- GTID auto-positioning (key change vs. binlog position)

START REPLICA;

-- Verify GTID replication is active
SHOW REPLICA STATUS\G
-- Look for: Auto_Position: 1
-- Executed_Gtid_Set should match primary's gtid_executed

Creating the Replication User

sql

-- On primary: create dedicated replication user
CREATE USER 'repl_user'@'10.0.0.%'
    IDENTIFIED WITH mysql_native_password
    BY 'use-a-strong-password-here';

GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'10.0.0.%';
FLUSH PRIVILEGES;

Initializing a New GTID Replica

bash

# Step 1: Take a consistent backup with GTID info
mysqldump \
  --single-transaction \
  --master-data=2 \
  --set-gtid-purged=ON \
  --all-databases \
  -u root -p > /backup/full-backup.sql

# Alternatively, use Percona XtraBackup (non-blocking for InnoDB):
xtrabackup --backup --target-dir=/backup/xtrabackup
xtrabackup --prepare --target-dir=/backup/xtrabackup

# Step 2: Restore on the new replica
mysql -u root -p < /backup/full-backup.sql

# Step 3: Start replication (GTID auto-position handles everything)
STOP REPLICA;
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = 'primary.db.internal',
    SOURCE_AUTO_POSITION = 1;
START REPLICA;

GTID Failover with MySQL Orchestrator

bash

# Install Orchestrator
wget https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator-3.2.6-linux-amd64.tar.gz
tar -xzf orchestrator-3.2.6-linux-amd64.tar.gz

# Promote a replica to primary (GTID-safe)
orchestrator-client -c graceful-master-takeover-auto \
  -i current-primary:3306

# Orchestrator automatically:
# 1. Identifies the most up-to-date replica
# 2. Erases replication from all replicas
# 3. Points all replicas to the new primary using GTID auto-position

Important

Several MySQL operations are incompatible with enforce_gtid_consistency=ON: CREATE TABLE ... SELECT, CREATE TEMPORARY TABLE inside transactions, and non-transactional DDL mixed with DML. Review your application code before enabling GTID mode.

Monitoring GTID Health

sql

-- Check replication lag using GTID sets
SELECT
    GTID_SUBTRACT(
        (SELECT @@GLOBAL.gtid_executed FROM primary_link),
        @@GLOBAL.gtid_executed
    ) AS gtid_lag_set;

-- Count transactions behind
SELECT GTID_SUBTRACT(
    '3E11FA47:1-1000',  -- primary executed set
    '3E11FA47:1-950'    -- replica executed set
) AS missing_gtids;
-- Returns: 3E11FA47:951-1000 (50 transactions behind)

Key Takeaways

GTID replication eliminates binlog position tracking — failover becomes a single command instead of manual coordinate lookup.
MySQL 8.4 supports online GTID mode switching without a full replication rebuild for the first time.
Use SOURCE_AUTO_POSITION=1 instead of SOURCE_LOG_FILE/LOG_POS for all new replica setups.
Audit your DDL patterns before enabling enforce_gtid_consistency=ON — CREATE TABLE ... SELECT is the most common blocker.

Working with JusDB on MySQL Replication

JusDB migrates MySQL deployments to GTID replication and sets up automated failover with Orchestrator. We handle the compatibility audit, replica rebuilds, and 24/7 monitoring to ensure your replication topology stays healthy after every schema change.

Explore JusDB MySQL Management → | Talk to a DBA

Related reading:

MySQL 8.4 GTID Replication: Setup, Failover, and Monitoring

How GTIDs Work in MySQL 8.4

Enabling GTID Mode

Setting Up GTID Replication

Creating the Replication User

Initializing a New GTID Replica

GTID Failover with MySQL Orchestrator

Monitoring GTID Health

Working with JusDB on MySQL Replication

Share this article

JusDB Team

Need Expert Help?

MySQL Performance Tuning

MySQL Consulting

MySQL Migration

MySQL High Availability

MySQL on Kubernetes

MySQL Support

Related Articles

MySQL Explained (2026): InnoDB, 8.4 LTS, Replication & Production Patterns

MySQL wait_timeout, net_read_timeout & All Timeout Variables (2026 Production Guide)

MySQL binlog Retention, Rotation & Purge: Production Guide (2026)