面试题：MariaDB中GTID的工作机制细节

GTID在主从复制环境下的工作机制

主库生成GTID：
- 当主库上执行一个事务时，MariaDB会为该事务生成一个全局事务标识符（GTID）。GTID由两部分组成：服务器的UUID和一个递增的事务序列号。例如，57e18d1d - 4c16 - 11e9 - 81c6 - 525400f99156:1，其中57e18d1d - 4c16 - 11e9 - 81c6 - 525400f99156是主库的UUID，1是事务序列号。
- 生成GTID后，事务被写入二进制日志（binlog），并且GTID会和事务的其他信息一起记录在binlog中。
从库获取GTID及应用事务：
- 从库通过I/O线程连接到主库，请求主库发送二进制日志。主库的二进制日志传输线程（通常称为dump线程）将包含GTID的二进制日志发送给从库的I/O线程。
- 从库的I/O线程将接收到的二进制日志写入到本地的中继日志（relay log）中。
- 从库的SQL线程读取中继日志，解析其中的GTID。SQL线程会检查这个GTID是否已经在从库应用过。如果没有应用过，SQL线程就会应用该事务，并将GTID记录到从库的gtid_executed表中，表示该GTID对应的事务已经在从库执行。

可能遇到的问题及解决办法

GTID不一致问题：
- 问题描述：主从库之间的GTID集合不一致，可能导致数据不一致或复制中断。例如，在主库上手动删除了部分二进制日志，而从库还依赖这些日志中的GTID，就会出现不一致。
- 解决办法：
  - 可以使用SET GLOBAL gtid_purged='<gtid set>'语句，手动设置从库的gtid_purged变量，使其与主库一致。<gtid set>是主库当前已经提交的GTID集合。
  - 重新配置主从复制，使用CHANGE MASTER TO语句指定正确的主库信息和起始GTID，然后重启从库复制。例如：
```
CHANGE MASTER TO
    MASTER_HOST='master_host_ip',
    MASTER_USER='replication_user',
    MASTER_PASSWORD='replication_password',
    MASTER_LOG_FILE='master_binlog_file',
    MASTER_LOG_POS=master_binlog_position,
    MASTER_AUTO_POSITION=1;
START SLAVE;
```
网络故障导致复制延迟：
- 问题描述：网络不稳定或故障可能导致从库接收主库二进制日志延迟，进而使事务应用延迟，造成主从数据不一致的风险。
- 解决办法：
  - 监控网络状况，确保主从库之间网络稳定。可以使用工具如ping、traceroute等检查网络连通性和延迟。
  - 配置合适的复制心跳机制，如设置较短的master_heartbeat_period参数（单位为秒），主库会按照这个时间间隔向从库发送心跳包，从库可以根据心跳来判断主库状态。例如在主库配置文件中添加master_heartbeat_period = 10，表示每10秒发送一次心跳。
  - 增加从库资源，如CPU、内存等，以加快事务应用速度，减少延迟积累。
GTID复制过滤规则冲突：
- 问题描述：如果在主从库上配置了不同的复制过滤规则（如replicate - do - db、replicate - ignore - db等），可能导致GTID不一致和复制问题。例如主库配置了对某个数据库的操作记录到binlog，而从库配置忽略该数据库，就会出现问题。
- 解决办法：
  - 仔细检查主从库的复制过滤规则，确保它们之间不会相互冲突。可以通过查看主从库的配置文件（如my.cnf）来确认规则设置。
  - 如果需要修改过滤规则，应该在主从库上同时进行一致的修改，并在修改后重启复制，确保规则生效。例如先停止从库复制STOP SLAVE;，修改规则后再启动复制START SLAVE;。

星途面试题库

面试题：MariaDB中GTID的工作机制细节

知识考点

面试题答案

GTID在主从复制环境下的工作机制

可能遇到的问题及解决办法