数据库主从复制

附一张架构图以备理解

个人理解：
主从复制 即 master（主任） slave（奴隶、仆人），了解中文后就很好理解了，可以套用在和绅府的身上。

由于和绅一人管理太多仆人导致精力不够，于是引进大管家刘全代为管理仆人，自己的管理操作全部交给刘全即可，同时刘全不再负责其他工作,专心于揣摩上司和管理下人。

这里的 M 就好比和绅，中间的第二层 S就好比大管家刘全，其他的还可以一级一级往下分。
和绅的工作就是负责接收指令（接收update、delete、insert）和发起指令（将指令放入 binlog 中，binlog 全称 binary-log；此处分为异步模式、同步模式、半异步模式，在下面的第二篇文章中皆有详细介绍），然后刘全接收到指令并将之分发到具体的仆人身上（即，管理n个用于 同步的线程 LogDumpThread，翻译日志倾倒线程 ，将自身 relay log 内的数据同步到下面的数据库中）。这样和绅就能专注于增删改操作，至于大量的繁琐的操作（读取数据库）就交道了刘全之下的其它数据库身上了。
那么因为存在大量的slave服务器，而每次进行查询操作都很可能用不同的slave，那么缓存变不好利用了，所以可以在中间加一层，即所有的slave缓存存储到共同的服务器中，memcache服务器。所有的slave数据库公用缓存，大大的提高了缓存利用率。

至于 GTID 模式自己还不怎么理解。大致就是原先的数据库同步操作中， I/O 流同步时同步的文件 是binlog 文件和 binlog_location 偏移量（该slvae上次在binlog文件中读取的位置），而 binlog 中记载同步的操作分为 三种，1、基于sql语句的同步，（Statement-base Replication (SBR) ）2、基于数据同步（Row-based Replication(RBR)）3、混合模式；而GTID是基于事务进行同步的，即每台服务器中的每一个事务都有一个不同的 ID GTID并记录在binlog中，每次同步是根据binlog中的GTID去对binlog解析并同步数据的。

1. 第一篇文章

原文链接：https://www.jianshu.com/p/9300742e0692

这篇文章很好的让我对数据库的主从分离有了个了解。不过这个文章估计也是这个老哥不知道从哪里保存的，因为好多地方都没有图片。

2. 第二篇

深度探索MySQL主从复制原理 - 启迪云的文章 - 知乎
https://zhuanlan.zhihu.com/p/50597960

非常清晰直观的介绍了绝大部分的数据库主从模式的区别，对第一篇文章有了很好的扩展和支持，但是最后说到最后比较新的 GTID复制模式 时过于模糊，导致我又查找了第三次搜索

3. 第三次搜索

MySQL 5.7基于GTID及多线程主从复制 - Wayne的文章 - 知乎
https://zhuanlan.zhihu.com/p/132406857

GTID！MySQL复制中的核武器 - java架构的文章 - 知乎
https://zhuanlan.zhihu.com/p/61060311
这篇说的云里雾里的，似是而非的暂时看不懂

MySQL传统点位复制在线转为GTID模式复制 - 数据库干货铺的文章 - 知乎
https://zhuanlan.zhihu.com/p/93387816