目录
1.什么是MySQL复制？何时使用MySQL复制？
（1）概念
（2）应用场景
【1】水平横向扩展
【2】商业智能与分析
在正式介绍其用途前，我们先理清两个概念---OLTP和OLAP
2.为什么配置复制不能用socket通信？
3.如何配置复制主服务器
（1）启用TCP/IP网络
（2）启用二进制日志
（3）创建具有复制权限的用户
（4）备份主数据库作为从属服务器开始复制的起点
（5）如果不使用GTID（全局事务唯一标识），则记录日志坐标（一般生产中都会用到）
4.如何配置从属服务器
（1）从主服务器备份恢复
（2）在每个从属服务器上发出CHANGE_MASTER TO语句，包含
（3）执行备份后立即在主服务器上执行SHOW_MASTER_STATUS
（4）若采用多源复制在CHANGE_MASTER TO语句时还应该添加FOR CHANNEL语句区分主服务器的传输通道
5.简要介绍复制过滤规则
6.分析异步复制和同步复制
7.简述二进制日志工作方式
8.什么是故障安全复制
（1）二进制日志是故障安全的
（2）将从属服务器状态日志存储在表中以进行故障安全复制
1.什么是MySQL复制？何时使用MySQL复制？
（1）概念
MySQL复制是指使服务器将更改复制到另一个实例。依靠主服务器（master：将所有数据和结构更改记录到二进制日志中）、从属服务器（slave，从主服务器请求二进制日志并在本地应用其内容）和中继从属服务器（作为一个从属服务器的主服务器）来实现。主/从属服务器是一对多的关系，它可以构建出三种复杂的拓扑结构：双向拓扑、循环拓扑、多源复制。双向拓扑表示在两个主服务器中每个主服务器都是另一个主服务器的从属服务器；循环拓扑结构里任意数量的服务器中每个主服务器且是另一个主服务器的从属服务器、对任何主服务器的更改都将复制到其他主服务器，且并非每个从属服务器都必须是主服务器；多源复制允许一个从属服务器接收来自多个主服务器的事务。对于这种复杂的拓扑结构，存在明显的复制冲突，每个服务器上冲突行的最终值由每个主服务器上应用事件的顺序有关，所以应该尽量避免。
（2）应用场景
【1】水平横向扩展
当服务器需要通过增加更多的节点来分担请求压力，从而提升系统的整体处理能力（吞吐量）时，我们需要采用MySQL复制。并且客户机的写操作应发送到复制主服务器（只有一台服务器接收写操作以避免冲突），读取操作应分布在配置负载均衡的从属服务器之间。
这里你可能会有疑惑：我本来业务都够多了，我还要新增这么多设备，还要同步数据，这工作量不就不减反增了吗？
就比如你开一家奶茶店，一开始你只有1个店员，那么高峰期就会一直排队，假设1个店员每5分钟能处理1个业务，那10个客户就要花费50分钟。但如果你又新开了两家店，每店一个店员，那么50分钟它们能处理30个客户，虽然工作效率没变，甚至可能因为要在后台中同步账单花费更多时间，但整体上能同时处理的业务量更多了，吞吐能力（单位时间内系统能够成功处理的数据量或请求数）更强
【2】商业智能与分析
在正式介绍其用途前，我们先理清两个概念---OLTP和OLAP
高并发与高吞吐之间存在冲突，因为高并发要求快速响应，其实现逻辑可以参照Linux专栏中对于进程管理章节的描述，它适合处理大量短小快速、高交互性、频繁读取IO的请求。但对于单个请求可能扫描几百万行数据进行复杂聚合排序连接的，需要占用大量内存和CPU，计算量要求高，要求尽量短时间处理更多的量。如果让高吞吐任务在高并发系统中运行它会吞走所有CPU和IO资源造成等待甚至卡死，所以高并发和高吞吐之间需要做好协调。对于一个电商系统为了应对白天用户疯狂下单、支付、查询库存等操作需要及时响应，避免卡死造成数据丢失，所以采用高并发场景，这种称为事务型系统（OLTP）。对于夜间查看报表、用户行为分析等高吞吐的复杂查询处理，采用分析型系统（OLAP）。商业智能（BI）查询需要从订单表、商品表、事件维度等多个大表中读取数百万甚至上亿行数据，吞吐量高，全表扫描和复杂连接占用大量资源，容易造成死锁现象。
而MySQL复制技术让主库只处理高并发的交易（写），从库处理高吞吐的分析（读），实现“负载隔离（将不同类型的业务负载分离开来，运行在不同的数据库节点或实例上）”，保证了交易系统的稳定工作。
【3】地理数据分布
使用本地应用程序为本地用户提供服务，用户的数据缓存或存储在本地节点上，这样用户请求时直接访问本地服务器集群（写的是主服务器），减少网络传输距离，降低延迟。并将与位置无关的数据复制到其他地方的从属服务器（数据下发和数据汇总，各地与本部间是多源复制关系）
【4】特定分析
使用BLACKHOLE存储引擎（存储引擎是和表绑定的，该存储引擎特点就是只记录日志修改记录，但是不存储数据，即写入结果你从属服务器要给我存储，但我只记录改了些啥，数据给丢弃了）进行中继服务器上的复制时，中继服务器把业务扔给从属服务器跑但自己只记录修改历史。但如果写过程故障可能导致数据丢失，但从属服务器损坏可以通过迁移日志解决
【5】高可用性
在多台服务器间提供冗余，并实施受控切换（硬件或系统升级期间使用副本代替生产服务器）或滚动升级（从属服务器版本必须比主服务器新）。
2.为什么配置复制不能用socket通信？
套接字socket是用于两个进程间的通信，服务器往往在不同设备上，它们的文件系统不一样，无法实现通信，所以只能用tcp通信
3.如何配置复制主服务器
（1）启用TCP/IP网络
（2）启用二进制日志
在复制过程中，每个主服务器将其日志内容发送到每个从属服务器
（3）创建具有复制权限的用户
第一个*表示任何库，第二个*表示任何表。用户名后面加@和主机名，是因为在数据库中，有些服务器可能用作特殊处理，所以有些用户需要被限制登录，加主机名用户就只能在特定从属服务器上登录
mysql> CREATE USER user@slave_hostname IDENTIFIED BY 'password'; mysql> GRANT REPLICATION SLAVE ON *.* TO user@slave_hostname;（4）备份主数据库作为从属服务器开始复制的起点
这个意思就是你需要确保分配给从属服务器任务前让其同步主服务器的历史数据确保它能知道怎么操作及处理的对象
（5）如果不使用GTID（全局事务唯一标识），则记录日志坐标（一般生产中都会用到）
GTID记录在复杂系统中一个事务到底是在哪个机器上最早执行的，每个服务器都有一个server_uuid标识的UUID（怎么查看？SELECT @@server_uuid\G），加上它的事务编号构成GTID，这样通过GTID用户就能知道复制顺序。同时，设置了GTID的话，进行故障转移时只需在从属服务器上发出单个CHANGE MASTER TO语句即可绕过主服务器，系统会自动判断是否应用事件，能有效减少数据不一致性出现
使用以下选项可以设置GTID：
- gtid-mode=ON：启动GTID复制功能
- enforce-gtid-consistency：所以在主服务器上执行的事务必须是能被正确记录和复制的，不能有非确定操作
- log-slave-updates：将从属服务器接收到的复制事件记录到二进制日志
4.如何配置从属服务器
（1）从主服务器备份恢复
若使用GTID（后面我都只按使用GTID来讨论），验证是否设置了gtid_purged变量
（2）在每个从属服务器上发出CHANGE_MASTER TO语句，包含
【1】主服务器的网络位置：MASTER_HOST和 MASTER_PORT
【2】具有复制权限的用户名及其口令：MASTER_USER和MASTER_PASSWORD
【3】MASTER_AUTO_POSITION=1
（3）执行备份后立即在主服务器上执行SHOW_MASTER_STATUS
查看日志文件及其坐标，确保备份后主服务器上没有用户活动，保证日志坐标是备份前最后一个事件的坐标
（4）若采用多源复制在CHANGE_MASTER TO语句时还应该添加FOR CHANNEL语句区分主服务器的传输通道
5.简要介绍复制过滤规则
当环境中不同服务器有不同目的时，我们会采用过滤规则。例如专用于显示Web内容的服务器不需要从主服务器复制支付记录一样，主服务器要是有300张表有200张表执行过修改，从属服务器复制时只想要与自己业务相关的50张，这样我们就想能不能让通往从属服务器的日志减少。 MySQL使用复制过滤器控制复制范围，过滤器是应用于主服务器或从属服务器的服务器选项，在主服务器是从源头上使用binlog-*过滤器，从属服务器是应用replicate-*过滤器读取中继日志。过滤优先级为：数据库过滤器（replicate-do-db（-do-表示只复制某部分）, binlog-do-db，replicate-ignore-db（-ignore-表示不会复制某部分）, binlog-ignore-db）>表过滤器（replicate-do-table, replicate-wild-do-table（-wild-表示使用通配符要匹配的），replicate-ignore-table, replicate-wild-ignore-table）>使用通配符的数据库或表过滤器；*-do-*过滤器>*-ignore-*过滤器
6.分析异步复制和同步复制
异步复制是master上的bingo转储线程把二进制日志发送给从属服务器，从属服务器上的IO线程接收后放到中继日志中，里面有SQL线程应用，该过程某一环节出故障后会造成数据库的数据不同步，这在生产上需要避免的，因此更常用同步和半同步复制。半同步复制是在异步复制基础上添加了一个插件，只有至少一个从属服务器也和主服务器一样提交事务后不再阻止主服务器。这样能保证数据完整性，但是牺牲了性能
7.简述二进制日志工作方式
二进制日志包含基于行和记录和基于语句从记录，基于行的记录会把修改的所有行插入到从属服务器，它的传输效率低且必须确保主从服务器使用相同的表结构；基于语句的记录是在从属服务器上执行语句去修改行，它的传输效率高且便于审计，但是不能保证非确定性语句在远程机器上正确重放。它的恢复方式是一种是让你恢复到错误发生前任意时间点的方式，一种是从备份时刻到当前时刻的完整数据重建。此外，二进制日志通过轮转的方式自动管理何时应该生成新的二进制日志文件。轮转在MySQL重启、达到max_binlog_size值或发出FUSH LOGS语句时发生。可以通过使用SHOW BINARY LOGS或SHOW MASTER STATUS检查元数据或mysqlbinlog检查内容
8.什么是故障安全复制
它体现在两方面：
（1）二进制日志是故障安全的
MySQL仅记录完成的事务，避免不确定状态发生；同时使用sync-binlog提高安全性。sync-binlog=1，则每次事务后写入文件以持久化；sync-binlog=0，则操作系统根据调优配置集写入文件，这种方式性能最好但风险最高；将该值设为>1的任何数会在该数量的事务后写入文件
（2）将从属服务器状态日志存储在表中以进行故障安全复制
使用master-info-repository和relay-log-info-repository选项把日志存储在表中，表是故障安全的
