1.1.复制解决的基本问题是让一台服务器的数据与其他服务器保持同步
1.2.在源服务器（sourcsrvr）上，任何数据修改和数据结构变更的事件（vnt）都会被写入日志文件中
1.3.副本服务器从源服务器上的日志文件中读取这些事件并在本地重放执行
1.4.一个异步处理的过程
1.4.1.不能保证副本服务器上的数据是最新的
1.4.2.复制延迟（副本数据和最新数据之间的时间差）也并没有上限
1.5.MySQL复制是其内置的一把“瑞士军刀”
1.6.MySQL的复制基本上是向后兼容的
1.6.1.新版本的服务器可以作为老版本的服务器的副本
1.6.2.老版本的服务器作为新版本的服务器的副本通常是不可行的
1.7.通过复制可以将读操作指向副本来获得更好的读扩展性
1.7.1.并不适合通过复制来扩展写操作
1.8.在一主库多副本库的架构中，写操作会被执行多次，这时候整个系统的性能取决于写入最慢的那部分
1.9.在复制架构中，读取和重放日志事件是解耦的
1.9.1.允许读取日志和重放日志异步进行
1.9.2.I/O线程和SQL线程都是可以独立运行的
2.用途2.1.数据分发
2.1.1.不会对带宽造成很大的压力
2.1.2.基于行的复制会比传统的基于语句的复制模式的带宽压力更大
2.1.3.如果为了保持很低的复制延迟，最好有一个稳定的、低延迟连接
2.2.读流量扩展
2.2.1.可以将读操作分布到多台服务器上，实现对读密集型应用的优化
2.2.2.对于小规模的应用，可以简单地对机器名做硬编码或使用DNS轮询
2.3.备份
2.3.1.一项有助于备份的有价值的技术，但副本不是备份，也不能够取代备份
2.4.分析与报告
2.4.1.为报告/分析（在线分析处理，OLAP）查询使用专用的副本是一项很好的策略
2.4.2.可以很好地隔离此类查询产生的压力，以避免对满足外部客户需求的在线业务产生影响
2.5.高可用性和故障切换
2.5.1.有助于避免MySQL成为应用程序中的单点故障
2.5.2.一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间
2.6.MySQL升级测试
2.6.1.先使用一个更高版本的MySQL作为副本，确保查询能够在此副本上按照预期执行，再升级所有的实例
3.步骤3.1.源端把数据更改记录到二进制日志中，称之为“二进制日志事件”（binarylogvnts）
3.2.副本将源上的日志复制到自己的中继日志中
3.3.副本读取中继日志中的事件，将其重放到副本数据之上
4.原理4.1.复制格式
4.1.1.基于语句的
4.1.1.1.通过记录所有在源端执行的数据变更语句来实现的
4.1.1.2.简单且紧凑
4.1.1.3.一条更新了大量数据的SQL语句，在二进制日志中可能仅仅需要几十字节存储
4.1.1.4.“不确定性”的SQL语句问题
4.1.1.4.1.如果在源和副本上，记录的排序不同，这条SQL语句在源和副本上删除的条记录就会不同，这将导致数据不一致
4.1.1.5.除非某些场景下明确需要临时使用基于语句的复制
4.1.2.基于行的
4.1.2.1.每条被改变的记录都会作为事件被写入二进制日志
4.1.2.2.让二进制日志的大小发生巨大的增长
4.1.2.3.建议坚持使用基于行的复制
4.1.2.3.1.提供了最安全的数据复制方法
4.1.3.混合模式
4.1.3.1.thmixdmthod
4.1.3.2.事件的写入，默认使用基于语句的格式，仅在需要时才切换到基于行的格式
4.1.3.3.在写入每个事件时会有很多的判断条件，以确定使用哪种格式，而这也会导致二进制日志中出现不可预测的事件
4.1.3.4.不使用
4.2.全局事务标识符
4.2.1.GTID
4.2.2.使用GTID，源服务器提交的每个事务都被分配一个唯一标识符
4.2.3.由srvr_uuid和一个递增的事务编号组成的
4.2.4.当事务被写入二进制日志时，GTID也随之被写入
4.2.4.1.当SQL线程提交事务时，它也会将GTID标记为执行完成
4.2.5.GTID解决了运行MySQL复制的一个令人痛苦的问题：处理日志文件和位置
4.2.6.强烈建议在数据库中启用GTID
4.3.崩溃后的复制安全
4.3.1.innodb_flush_log_at_trx_