1. 概念
MySQL主从复制指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点
2. 用途
读写分离：主库负责写，从库负责读
数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
高可用HA：high availablility，减少系统不能提供服务的时间
架构扩展：可以通过主从复制增加多个数据存储节点，负载分布在多个从节点上，提高IO性能
3. 形式
一主一从
一主多从：提高系统读性能，实现高可用
多主一从：可以将多个mysql数据库备份到一台存储性能比较好的服务器上
双主复制：任何一方所做的变更，都会通过复制应用到另外一方的数据库中
级联复制：主-从-从，缓解主节点压力
4. 原理
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个（I/O thread，SQL thread）运行在从节点，如图所示
主节点binary log dump线程
当从节点连接主节点时，主节点会创建一个log dump线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放
从节点I/O线程
当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump进程发来的更新之后，保存在本地relay-log中
从节点SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性
复制的基本过程如下：
从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在主节点上实际执行过的操作，并在本数据库中执行。
5. 主从复制模式
异步模式：有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地
半同步模式：主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时然后切换成异步模式再提交
全同步模式：主节点和从节点全部执行了commit并确认才会向客户端返回成功
6. binlog记录格式
MySQL主从复制有三种方式：基于sql语句的复制，基于行的复制，混合模式复制。对应的binlog（失效转移）文件格式也有三种：STATEMENT,ROW,MIXED
STATEMENT：优点是只需要记录sql语句，减少了日志量，节约I/O，提高性能；缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）
ROW：优点是不会出现某些特定情况下存储过程、函数、trigger的调用或者触发无法被正确复制的问题；缺点是会产生大量日志
MIXED：对于一般复制使用STATEMENT，对于STATEMENT无法复制的操作使用ROW
7. GTID复制模式
基于GTID复制实现的工作原理
主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
从节点的I/O线程将变更的bin log，写入到本地的relay log中。
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。
如果有记录，说明该GTID的事务已经执行，从节点会忽略。
如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。
与pos的区别
不同从节点pos点是不同的，在一开始从节点向主节点复制的过程中是可以复制的，但是一旦主节点宕机需要主从切换，那么从节点就很难找到当前主节点对应的复制点
而GTID在所有节点都是相同的，也就方便复制了
类似于全局变量和局部变量的区别
