MySQL Replication是官方提供的主从同步方案，也是用的最广的同步方案。Replication(复制)使来自一个MVSQL数据库服务器(称为源(Source))的数据能够复制到一个或多个 MSQL服务器(称为副本(Repica))。默认情况下，复制是异步的;副本不需要永久连接即可从源接收更新。根据配置,您可以复制所有数据库、指定数据库，甚至某个数据库中的指定表。
复制的优势:
- 高可用:通过配置一定的复制机制，MSQL实现了跨主机的数据复制，从而获得一定的高可用能力，如果需要获得更高的可用性，只需要配置多个副本，或者进行级联复制就可以达到目的。
- 性能扩展:的于复制机制提供了多个数据备份，可以通过配置一个或多个副本，将读请求分发至副本节点，从而获得整体上读写性能的提升。
- 异地灾备:只需要将副本节点部署到异地机房，就可以轻松获得一定的异地灾备能力。实际当中，需要考虑网络延迟等可能影响整体表现的因素。
- 交易分离:通过配置复制机制，并将低频、大运算量的交易发送至副本节点执行，就可以避免这些交易与高频交易竞争运算资源，从而避免整体的性能问题。
缺点:
- 没有故障自动转移，容易造成单点故障
- 主库从库之间有主从复制延迟问题，容易造成最终数据的不一致。
- 从库过多对主库的负载以及网络带宽都会带来很大的负担
应用场景
- 电子商务平台: 在电商平台中，主从复制可以用于实现读写分离，提高并发处理能力，同时确保数据的一致性。社交网络:在社交网络应用中，可以利用主从复制来提供快速的读取服务，同时将数据变更复制到从数据库以备份数据
- 实时监控和报警系统: 在监控系统中，主从复制可以用于实现数据的分布式存储和快速数据查询。
- 新闻和媒体网站: 在高访问量的新闻网站中，可以使用主从复制来提供高可用性和快速的内容访问
- 金融服务: 在金融行业，数据的安全性和可用性至关重要，主从复制可以用于数据备份和高可用性的实现。
MySQL 8.0支持多种复制方式:
- 传统的方法是基于从源的二进制日志(binlog)复制事件，并要求日志文件及其中的位置在源和副本之间进行同步。作为源(数据库更改发生的地方)的 MYSQL 实例将更新和更改作为“事件"写入二进制日志。根据所记录的数据库更改，二进制日志中的信息以不同的日志格式存储。副本配置为从源中读取二进制日志，并在副本的本地数据库上执行二进制日志中的事件。
- 基于全局事务标识符(GTID)的方式。基于 GTID 的复制是完全基于事务的，所以很容易确定源和副本是否一致:只要在源上提交的所有事务也在副本上提交，就可以保证两者之间的一致性。
基于全局事务标识符(GTID)复制
GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务!D，它由服务器!D以及事务ID组合而成。这个全局事务!D不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。
- 一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
- GTID用来代替传统复制方法，不再使用MASTERLOGFILE+MASTERLOG POS开启复制，而是使用MASTER AUTO POSTION=1的方式开始复制。
- 在传统的replica端，binlog是不用开启的，但是在GTID中replica端的binog是必须开启的，目的是记录执行过的GTID(强制)。
GTID 的优势
- 更简单的实现 failover，不用以前那样在需要找位点(log file 和 log pos)。
- 更简单的搭建主从复制，
- 比传统的复制更加安全
- GTID 是连续的没有空洞的，保证数据的一致性，零丢失。
GTID结构
GTID表示为一对坐标，由冒号(:)分隔，如下所示
1 GTID =source_id:transaction_id
复制的数据同步类型
MYSQL 中的复制支持不同类型的同步。同步的原始类型是单向异步复制，其中一个服务器充当源，而一个或多个其他服务器充当副本。在 MYSQL 8.0中，除了内置的异步复制之外，还支持半同步复制。使用半同步复制，在返回执行事务的会话之前，对源执行提交，直到至少有一个副本确认它已经接收并记录了事务的事件。MySQL8.0还支持延迟复制，以使副本故意落后于源至少指定的时间。
异步复制
默认情况下，MySQL 采用异步复制的方式，执行事务操作的线程不会等复制 Binlog 的线程。
MYSQL主库在收到客户端提交事务的请求之后，会先写入Binlog，然后再提交事务，更新存储引擎中的数据，事务提交完成后，给客户端返回操作成功的响应，同时，从库会有一个专门的复制线程，从主库接收Binlog，然后把Binlog写到一个中继日志里面，再给主库返回复制成功的响应。从库还有另外一个回放Binlog的线程，去读中继日志，然后回放Binlog更新存储引擎中的数据。
提交事务和复制这两个流程在不同的线程中执行，互相不会等待，这是异步复制。异步复制的劣势是，可能存在主从延迟，如果主节点宕机，可能会丢数据。
半同步复制
- MYSQL 从5.7 版本开始，增加一种半同步复制(Semisynchronous Replication)的方式。这种机制与异步复制相比主要有如下区别:·主节点在收到客户端的请求后，必须在完成本节点日志写入的同时，还需要等待至少一个从节点完,成数据同步的响应之后(或超时)，才会响应请求。
- 从节点只有在写入 relay-og 并完成刷盘之后，才会向主节点响应。
- 当从节点响应超时时，主节点会将同步机制退化为异步复制。在至少一个从节点恢复，并完成数据追赶后，主节点会将同步机制恢复为半同步复制。
可以看出，相比于异步复制，半同步复制在一定程度上提高了数据的可用性，在未退化至异步复制时，如果主节点宕机，此时数据已复制至至少一台从节点。同时，由于向客户端响应时需要从节点完成响应，相比于异步复制，此时多出了主从节点上网络交互的耗时以及从节点写文件并刷盘的耗时，因此整体上集群对于客户端的响应性能表现必然有所降低。
半同步复制有两个重要的参数:
- rpl_semi_sync_master_walt_slave_count(8.0.26之后改为rpl_semi_sync_source_wait_forreplica_count):至少等待数据复制到几个从节点再返回。这个数量配置的越大，丢数据的风险越小，但是集群的性能和可用性就越差。
- rpl_semi_sync_master_wait_point(8.0.26之后改为rol_semi_svnc_source_wait_point):这个参数控制丰库执行事务的线程，是在提交事务之前(AFTER SYNC)等待复制，还是在提交事务之后(AFTERCOMMIT)等待复制。默认是AFTER SYNC，也就是先等待复制，再提交事务，这样就不会丢数据。
