复制状态机 + TCP/IP
复制状态机的原理：全量快照 + 增量日志可以恢复到任意历史状态（数据）
具体到MySQL的一主多从架构，主节点负责读写请求，从节点只负责接收读请求, master将写操作的变更同步到各个从节点。应用于读请求大于写请求的场景。 → 通用
MySQL主从之间通过binlog来同步数据，从节点启动的时候，可以指定从主节点binlog的哪个位置开始重放，达到同步或者恢复数据的目的。
MySQL主节点和从节点数据同步过程：
从库通过执行 change master to 命令连接主库，并提供了连接的用户的一切条件：username、password、主节点IP、port、binlog文件和读取位置
从库根据binlog文件名和position，由IO线程(Slave_IO)向主库建立获取binlog的连接
主库dump线程根据从库的请求，将本地的binlog以events的形式发给从库
获取binlog events，并存放到本地的relay-log中，传送过来的信息回放到master.info中
从库SQL线程应用relay-log，并且把应用记录到relat-log.info中去按顺序得到主节点上的写操作和数据，然后写到自己的中继日志里，再向主节点返回ack并由SQL线程(Slave_SQL)从中读取并执行binlog，更新数据，使得主从之间的数据同步。
查看主节点的 /var/lib/mysql/ 下的binlog及其大小，对比一下从节点执行 show slave status\\G 的结果就可知道binlog大概的原理
各个从库上可以查看binlog的文件名和当前读取到的位置，所有从库的这两个值都相等。但是这个从库的Relaylog的文件名和offset就未必相等了。
Relaylog：从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。