MySQL5.7配置Pseudo-GTID完整步骤

MySQL5.7配置Pseudo-GTID完整步骤div id navCategory div 在开始配置之前 先简单理解 Pseudo GTID 的工作原理 定期注入唯一标记 在 MySQL 的 binlog 中定期插入一个全局唯一的 SQL 语句 作为定位锚点 这些标记成为 binlog 中的 坐标点 Orchestrator

大家好,我是讯享网,很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     

在开始配置之前,先简单理解 Pseudo-GTID 的工作原理:

  1. 定期注入唯一标记:在 MySQL 的 binlog 中定期插入一个全局唯一的 SQL 语句
  2. 作为定位锚点:这些标记成为 binlog 中的"坐标点",Orchestrator 可以通过它们快速定位数据同步位置
  3. 无需开启 GTID:在传统复制模式下,也能实现类似 GTID 的自动定位能力

首先在每个 MySQL 实例上创建用于存放伪 GTID 相关对象的数据库:

GPT plus 代充 只需 145– 登录 MySQL(所有节点:192.168.56.80、61、60) mysql -uroot -p

– 创建 meta 数据库(如果不存在) CREATE DATABASE IF NOT EXISTS meta;

这是最核心的步骤,需要创建一个定时事件来定期注入伪 GTID 标记:

– 切换到 meta 数据库 USE meta;

– 确保事件调度器已开启 SET GLOBAL event_scheduler = ON;

– 创建伪 GTID 注入事件 DELIMITER $$

CREATE EVENT IF NOT EXISTS create_pseudo_gtid_event ON SCHEDULE EVERY 10 SECOND STARTS CURRENT_TIMESTAMP ON COMPLETION PRESERVE ENABLED COMMENT ‘Inject Pseudo-GTID markers for Orchestrator’ DO BEGIN

GPT plus 代充 只需 145DECLARE lock_result INT; -- 获取锁,确保同一时间只有一个会话执行注入 SELECT GET_LOCK('pseudo_gtid_lock', 0) INTO lock_result; IF lock_result = 1 THEN -- 执行一个会产生 binlog 事件的语句 -- DROP VIEW 即使视图不存在也会记录 binlog DROP VIEW IF EXISTS `meta`.`pseudo_gtid_view`; -- 释放锁 DO RELEASE_LOCK('pseudo_gtid_lock'); END IF; 

END$$

DELIMITER ;

-- 查看事件是否创建成功 SHOW EVENTS FROM metaG -- 查看事件调度器状态(应为 ON) SHOW VARIABLES LIKE 'event_scheduler'; -- 查看事件的具体定义 SELECT EVENT_NAME, STATUS, STARTS, INTERVAL_VALUE, INTERVAL_FIELD, EXECUTE_AT FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'meta'; 

为了确保重启后配置依然有效,需要将相关配置写入 my.cnf:

GPT plus 代充 只需 145# 编辑 MySQL 配置文件 vim /etc/my.cnf

添加以下配置

[mysqld]

确保事件调度器开机自启

event_scheduler = ON

可选:优化 binlog 格式

binlog_format = ROW # 推荐使用 ROW 格式 binlog_rows_query_log_events = ON # 记录原始 SQL,便于调试

重启 MySQL 使配置生效:

systemctl restart mysqld

验证重启后事件调度器状态

mysql -e “SHOW VARIABLES LIKE ‘event_scheduler’;”

方法一:直接查看 binlog 内容
GPT plus 代充 只需 145# 找到最新的 binlog 文件 mysql -e “SHOW MASTER STATUSG”

查看 binlog 中的 Pseudo-GTID 标记

mysqlbinlog /var/lib/mysql/mysql-bin.000001 | grep -A 3 -B 3 “DROP VIEW” | head -20

你应该能看到类似这样的输出:

# at  # 10:00:00 server id  end_log_pos  Query thread_id=123 exec_time=0 error_code=0 SET TIMESTAMP=/!/; DROP VIEW IF EXISTS meta.pseudo_gtid_view/!/; 
方法二:通过 Orchestrator 验证
GPT plus 代充 只需 145# 使用 orchestrator-client 查看集群拓扑 orchestrator-client -c topology -i 192.168.56.80:3306

在 Orchestrator 日志中查看伪 GTID 相关信息

tail -f /var/log/orchestrator.log | grep -i pseudo

如果希望 Pseudo-GTID 标记更明显,可以使用复合语句:

DELIMITER $$

CREATE EVENT IF NOT EXISTS create_pseudo_gtid_event_advanced ON SCHEDULE EVERY 10 SECOND STARTS CURRENT_TIMESTAMP ON COMPLETION PRESERVE ENABLED DO BEGIN

GPT plus 代充 只需 145DECLARE lock_result INT; DECLARE pseudo_gtid_value VARCHAR(50); -- 生成一个唯一值 SET pseudo_gtid_value = CONCAT('pseudo_gtid_', UNIX_TIMESTAMP(), '_', RAND()); SELECT GET_LOCK('pseudo_gtid_lock', 0) INTO lock_result; IF lock_result = 1 THEN -- 创建一个包含唯一值的注释和 DROP VIEW 语句 SET @pseudo_gtid_sql = CONCAT('/* ', pseudo_gtid_value, ' */ DROP VIEW IF EXISTS `meta`.`pseudo_gtid_view`'); PREPARE stmt FROM @pseudo_gtid_sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; DO RELEASE_LOCK('pseudo_gtid_lock'); END IF; 

END$$

DELIMITER ;

创建监控脚本 /usr/local/bin/check_pseudo_gtid.sh

#!/bin/bash

检查事件是否存在且启用

MYSQL_CMD=“mysql -uroot -pYourPassword -e”

EVENT_STATUS=\((\)MYSQL_CMD “SHOW EVENTS FROM meta LIKE ‘create_pseudo_gtid_event’” 2>/dev/null | grep ENABLED)

if [ -z “$EVENT_STATUS” ]; then

GPT plus 代充 只需 145echo "ERROR: Pseudo-GTID event is not enabled or missing" exit 1 

fi

检查最近是否有注入

LAST_INJECT=\((\)MYSQL_CMD “SELECT MAX(STR_TO_DATE(event_time, ‘%Y%m%d %H:%i:%s’))

FROM (SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(event_time, '# at', -1), ' ', 2) as event_time FROM mysql.general_log WHERE argument LIKE '%DROP VIEW%' LIMIT 100) t" 2>/dev/null) 

CURRENT_TIME=\((date +%s) LAST_INJECT_TIME=\)(date -d “$LAST_INJECT” +%s)

if [ $((CURRENT_TIME - LAST_INJECT_TIME)) -gt 30 ]; then

GPT plus 代充 只需 145echo "WARNING: No Pseudo-GTID injection in last 30 seconds" exit 2 

fi

echo “OK: Pseudo-GTID is working properly” exit 0

确保 orchestrator.conf.json 中包含正确的 Pseudo-GTID 配置:

{ “AutoPseudoGTID”: true, “PseudoGTIDPattern”: “DROP VIEW IF EXISTS meta.pseudo_gtid_view”, “PseudoGTIDPatternIsFixedSubstring”: true, “PseudoGTIDMonotonicHint”: “order:asc”, “DetectPseudoGTIDQuery”: “SELECT max(SUBSTRING_INDEX(SUBSTRING_INDEX(event_time, ‘# at’, -1), ‘ ‘, 2)) as pseudo_gtid FROM mysql.general_log WHERE argument LIKE ‘%DROP VIEW IF EXISTS meta.pseudo_gtid_view%’”,

“RecoverMasterBinlogFileLocation”: true, “RecoverMasterClusterFilters”: [“*”], “InstancePollSeconds”: 5 }

现象:Pseudo-GTID 标记没有在 binlog 中出现

排查步骤

GPT plus 代充 只需 145– 检查事件状态 SELECT

EVENT_NAME, STATUS, LAST_EXECUTED, LAST_ALTERED 

FROM information_schema.EVENTS WHERE EVENT_SCHEMA = ‘meta’;

– 手动执行事件测试 CALL meta.create_pseudo_gtid_event();

– 查看是否有锁冲突 SHOW PROCESSLIST; SELECT * FROM performance_schema.metadata_locks;

现象:Orchestrator 无法识别 Pseudo-GTID 标记

解决方案

GPT plus 代充 只需 145– 确保监控用户有足够的权限 GRANT DROP ON meta.* TO ‘orch_topology_user’@‘192.168.56.%’; GRANT SELECT ON mysql.general_log TO ‘orch_topology_user’@‘192.168.56.%’; FLUSH PRIVILEGES;

– 如果不想开启 general_log,可以授予对 binlog 的访问权限 GRANT REPLICATION CLIENT ON . TO ‘orch_topology_user’@‘192.168.56.%’;

Pseudo-GTID 对性能的影响极小,但可以通过以下方式监控:

– 查看事件执行耗时 SELECT

GPT plus 代充 只需 145EVENT_NAME, AVG_EXEC_TIME, MAX_EXEC_TIME, COUNT_EXEC 

FROM performance_schema.events_statements_summary_by_account_by_event_name WHERE EVENT_NAME LIKE ‘%create_pseudo_gtid_event%’;

– 查看 binlog 增长速度 SHOW MASTER STATUS; – Pseudo-GTID 每10秒产生约 200-300 字节的 binlog 事件 – 每天约增加 2-3 MB,影响可忽略不计

  1. 注入频率选择
    • 默认 10 秒是平衡点,故障转移速度和性能影响的**实践
    • 对延迟敏感的业务可以调整为 5 秒
    • 超大集群可以适当延长到 15-20 秒
  2. 监控告警配置
    # 添加 crontab 监控 */5 * * * * /usr/local/bin/check_pseudo_gtid.sh > /dev/null 2>&1 
  3. 版本升级注意事项
    • MySQL 小版本升级不会影响已配置的事件
    • 主从切换后,事件会在新主库上继续运行
    • 建议在事件定义中使用 IF NOT EXISTS,避免重复创建
  4. 备份恢复考虑
    GPT plus 代充 只需 145-- 导出事件定义作为备份 mysqldump --events --no-data meta > meta_events_backup.sql 

通过以上配置,MySQL 5.7 就成功开启了 Pseudo-GTID 功能。这将让 Orchestrator 在不开启原生 GTID 的情况下,依然能够实现接近 GTID 的自动化故障转移能力。

最后验证清单

  • 所有节点都创建了 meta 数据库
  • 所有节点的事件调度器已开启
  • 所有节点的 Pseudo-GTID 事件已创建并启用
  • 监控用户有 DROP 权限
  • 至少观察到一个 Pseudo-GTID 标记写入 binlog
  • Orchestrator 配置文件已更新

如果遇到任何问题,建议先从验证 binlog 中的 Pseudo-GTID 标记开始排查。

到此这篇关于MySQL5.7配置Pseudo-GTID完整步骤的文章就介绍到这了,更多相关MySQL5.7配置Pseudo-GTID内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

小讯
上一篇 2026-03-17 22:34
下一篇 2026-03-17 22:32

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/243086.html