在MySQL 5.7中，随着GTID (Global Transaction Identifier) 技术的引入，它提供了更强大的复制能力，使得数据同步在分布式环境中更加可靠和灵活。当需要在不停止业务的情况下，将传统基于file-pos（基于文件位置）的复制方式转换为GTID复制时，这是一个重要的技术升级步骤。本文将提供一个具体的实例来展示这个过程。
首先，我们要理解为什么选择GTID复制。GTID复制基于事务标识，而非传统的文件指针，这意味着即使在复制过程中出现网络中断或故障，也能更容易地恢复复制，而且可以实现跨多个数据库服务器的更精确的复制控制。这对于大型分布式系统来说具有显著优势。
在一个传统的M-S（Master-Slave）架构中，我们有master（3301）和slave（3302）实例，它们通过file-pos复制保持同步。在这个场景下，进行不停业务的GTID复制迁移涉及以下步骤：
1. **确认当前状态**：在master上，检查当前的事务日志文件（Master_Log_File）以及读取位置（Read_Master_Log_Pos），确保数据完整。同时，查看slave的状态，确认它是通过Relay_Master_Log_File和相应的Relay_Log_Pos与master保持连接。
2. **启用GTID复制**：在master上，需要设置gtid_mode为ON，并可能需要开启enforce_gtid_consistency以强制使用GTID。这可以通过执行如下命令完成：
```
[zejin]3301> SET GLOBAL gtid_mode = ON;
[zejin]3301> SET GLOBAL enforce_gtid_consistency = 1;
```
3. **更新配置**：更新slave的配置文件（my.cnf或my.ini），将master的信息修改为使用GTID，例如：
```
[slave]
server-id=1
log-slave-updates
replicate-rewrite-db = database_name=old_db,server_id=2
```
注意这里的`replicate-rewrite-db`用于映射旧的数据库名称到新的GTID格式。
4. **重启服务**：重启master和slave服务，使新配置生效。
5. **检查并同步**：重启后，slave会尝试连接到master获取GTID信息，如果一切顺利，它将开始从GTID开始复制，而不是file-pos。可以通过监控 Slave_IO_Running 和 Slave_SQL_Running 来确认复制是否正常运行。
6. **验证数据一致性**：在迁移完成后，可以在slave上检查数据是否与master一致，使用SELECT语句确保表的内容已经正确同步。
在这个实例中，作者可能还会提供进一步的错误处理和故障排查建议，以确保整个过程的成功。总结起来，不停业务将传统复制方式转为GTID复制，是一个涉及更改配置、重启服务和监控同步的过程，旨在提高数据库复制的可靠性和效率。
我的内容管理
展开
