xiaohanliang
Database
Database
  • review
  • MySQL
    • 0. 索引就是树吗
    • 1. 索引是怎么发挥作用的
    • 2. 聊聊怎么估时间
    • 3. 主键玄学
    • 4. 事务的执行过程@ACD
    • 5. MVCC就是用undolog回退
    • 6. 事务如何彼此隔离@I
    • 7. 如何人为的制造死锁
    • 8. 引擎是干什么的
    • 9. 主从复制怎么做到的
    • 10. 寻找同步起始点GTID
    • 11. 预解析Statement
  • Redis
    • 0. Hash@数据结构
    • 1. ZSet@数据结构
    • 2. 场景与玩法@数据结构
    • 3. 可能的风险点
    • 4. Redis的落盘
    • 5. 关于效率的讨论
    • 6. 主从模式@集群化
    • 7. [WIP]Proxy实现@集群化
    • 8. 标准玩法@集群化
  • KV/Distributed
    • 0. 面临的问题
    • 1.Raft@原理
    • 2. LSM@原理
    • 3. [WIP]分布式事务@原理
Powered by GitBook
On this page
  • Introduction
  • 你有可能因为什么导致主从不一致

Was this helpful?

  1. MySQL

10. 寻找同步起始点GTID

Introduction

想象一个问题, 如果现在从节点短暂的挂了一会儿, 那么等它恢复的第一件事就应该是去主节点那里, 拉来之前缺失的数据, 那么从哪儿开始拉呢? 它怎么知道自己是从哪儿开始缺失的呢?

  • 主机更新数据时会产生GTID，一起记录到binlog日志中

  • 从节点的I/O线程拉来binlog，写入到本地的relaylog中

  • SQL线程从relaylog中获取GTID, 然后对比备机自己的Binlog查看一下自己有没有执行过这个语句

  • 如果有记录，说明该GTID的事务已经执行, 忽略

  • 如果没有记录, 说明这个GTID还没有执行过, 执行一下并记录到备机自己的binlog里

因此我们可以发现所谓寻找binlog的问题, 现在已经变成了寻找GTID的问题了

你有可能因为什么导致主从不一致

  1. 主从复制过程中，主库异常宕机

  2. 异步复制本身就不保证从库能接受到这些日志, 即使半同步也可能导致一部分备机无法同步到日志

  3. 全同步在主机记录binlog+redolog,但是没及时同步到备机就挂掉, 重启后主备不一致

Previous9. 主从复制怎么做到的Next11. 预解析Statement

Last updated 4 years ago

Was this helpful?