MySQL-主从/集群架构
mysql主从同步方案
1 复制（Replication）
Replication(复制)使来自一个MySQL数据库服务器（称为源（Source））的数据能够复制到一个或多个 MySQL 服务器（称为副本（Replica））优势：
高可用：通过配置一定的复制机制，MySQL 实现了跨主机的数据复制，从而获得一定的高可用能力，如果需要获得更高的可用性，只需要配置多个副本，或者进行级联复制就可以达到目的。 性能扩展：由于复制机制提供了多个数据备份，可以通过配置一个或多个副本，将读请求分发至副本节点，从而获得整体上读写性能的提升 异地灾备：只需要将副本节点部署到异地机房，就可以轻松获得一定的异地灾备能力。实际当中，需要考虑网络延迟等可能影响整体表现的因素 交易分离：通过配置复制机制，并将低频、大运算量的交易发送至副本节点执行，就可以避免这些交易与高频交易竞争运算资源，从而避免整体的性能问题缺点：
没有故障自动转移，容易造成单点故障可能造成数据丢失 主库从库之间有主从复制延迟问题，容易造成主从数据不一致 从库过多对主库的负载以及网络带宽都会带来很大的负担应用场景：
电子商务平台： 在电商平台中，主从复制可以用于实现读写分离，提高并发处理能力，同时确保数据的一致性。 社交网络： 在社交网络应用中，可以利用主从复制来提供快速的读取服务，同时将数据变更复制到从数据库以备份数据。 实时监控和报警系统： 在监控系统中，主从复制可以用于实现数据的分布式存储和快速数据查询。 新闻和媒体网站： 在高访问量的新闻网站中，可以使用主从复制来提供高可用性和快速的内容访问。 金融服务： 在金融行业，数据的安全性和可用性至关重要，主从复制可以用于数据备份和高可用性的实现。1.1 复制的方式：
基于binlog位点同步的主从复制
指从库通过指定主库的 binlog 文件名 + 位点（position），主从设备基于这两个值定位同步起点位置。主从复制过程：
1、事务提交时，主库将变更信息写入 二进制日志（binlog）。 2、从库的 I/O 线程 请求主库的 binlog 文件名 和 位点 。（例如 mysql-bin.000003:1540） 3、主库启动 Dump 线程，从指定位点开始推送 binlog 事件 4、从库 IO 线程接收到数据 → 写入中继日志（relay log）。 5、从库将得到的 binlog 写到本地的 relay log (中继日志) 文件中。 6、从库的 SQL 线程读取解析 relay log 并回放relay log中命令，实现数据同步。缺点：
1：首次开启主从复制的步骤复杂 2：恢复主从复制的步骤复杂基于全局事务标识符（GTID）复制**
为每个提交的事务生成一个全局唯一且不会重复的标识符，从库通过 GTID 协助主库自动定位同步起点，无需手动指定 binlog 文件名和位点，实现主从切换自动化复制。 基于 GTID 的复制是完全基于事务的，所以很容易确定源和副本是否一致; 只要在源上提交的所有事务也在副本上提交，就可以保证两者之间的一致性。GTID组成与格式：
格式为： source_id:transaction_id source_id：标识source服务器，即源服务器唯一的server_uuid transaction_id：一个从 1 开始的递增整数，按事务提交顺序单调增加 如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5工作原理：
主库计算主库 GTID 集合和从库 GTID 的集合的差集，主库推送差集 binlog 给从库。主从复制过程
从库 指定主库 ，基于主备协议建立连接。 从库 把自己的GTID集合发给主库 A。 主库 计算出自己与从库GTID集合差集。 主库 从自己的 binlog 文件里面，根据所得到的差集，找到第一个差集集合中的事务 GTID. 主库从这个GTID事务开始，往后读 binlog 文件，按顺序取 binlog，然后发给 B。 从库的 I/O 线程读取 binlog 文件生成 relay log，SQL 线程解析 relay log，然后执行 SQL 语句。GTID 同步方案和位点同步的方案区别
位点同步方案是通过人工在从库上指定哪个位点，主库就发哪个位点，不做日志的完整性判断。 GTID 方案是通过主库来自动计算位点的，不需要人工去设置位点，对运维人员友好。1.2 数据同步类型
异步复制（默认使用）
提交事务和复制这两个流程在不同的线程中执行，互相不会等待，可能存在主从延迟，如果主节点宕机，可能会丢数据 主库完全不关心从库是否收到数据，即使从库宕机或网络中断，主库照常提供服务。 适用于：对性能要求极高，可容忍少量数据丢失场景半同步复制
主节点在收到客户端的请求后，必须在完成本节点日志写入的同时，还需要等待至少一个从节点完成数据同步（写入 relay-log 并完成刷盘）的响应之后（或超时），才会响应请求 主库必须等待至少1个从库确认，才能认为事务提交成功。 适用于：对数据一致性要求高，金融、支付等重要参数
-至少等待数据复制到几个从节点再返回：rpl_semi_sync_master_wait_slave_count（8.0.26之后改 rpl_semi_sync_source_wait_for_replica_count）值越大，丢数据的风险越小，但集群性能越差。 -主库线程是在提交事务之前还是在提交事务之后等待复制：rpl_semi_sync_master_wait_point（8.0.26之后改为rpl_semi_sync_source_wait_point）默认是AFTER_SYNC，也就是先等待复制，再提交事务，这样就不会丢数据（加强半同步）半同步复制的超时与降级
当从节点响应超时时，主节点会将同步机制退化为异步复制。在至少一个从节点恢复，并完成数据追赶后，主节点会将同步机制恢复为半同步复制。性能与数据一致性
异步复制：主库提交即成功，整体上集群对于客户端的响应性高但可能丢数据 半同步复制：主库等待从库确认后再提交，速度慢但提高了数据的安全性2 组复制（Group Replication）
Mysql GroupReplication(简称MGR)，基于Paxos分布式共识协议、真正实现数据强一致性和自动故障转移的高可用集群方案。–
MGR本身不是一个主节点单向“推送”日志的复制工具，而是一个由多个节点基于Paxos协议进行协商、达成“多数派共识”的分布式状态机。 传统复制是一个主节点，多个从节点，主节点负责写入，从节点通过执行主节点的 binlog来同步数据，可能有延时。所有写操作都必须经过主节点。 MGR采用整组写入的方式，提交一个事务需要整个组的多数节点来共同决定是否提交，会在所有节点上同时提交。数据在组内是强一致的。多主模式下，任意节点都能处理写请求，不会像传统模式那样所有写操作都必须经过主节点（分布式写入）。 全局事务认证机制 -> 事务必须被集群中超过半数的节点成功接收并写入日志后，才算提交成功。 故障转移机制->集群内有一个内建的成员管理系统，能自动检测节点故障。如果主节点宕机，剩余节点会自动发起选举，在几秒到几十秒内选出新主。单主模式
单主模式下(group_replication_single_primary_mode=ON)，组中只有一个主服务器，该主服务器被设置为读写模式。组中的所有其他成员都被设置为只读模式(super_read_only=ON)。多主模式
在多主模式下(group_replication_single_primary_mode=OFF)，没有成员具有特殊的角色。任何组成员加入组时都被设置为读写模式，并且可以处理写事务，即使它们是并发发布的。组复制问题
组复制本身只解决了数据同步和高可用问题，它不负责将客户端请求从故障节点自动转移到新主节点。需要搭配MySQL Router等中间件来实现对应用的透明故障转移3 MySQL InnoDB Cluster
MySQL 官方出品的一站式高可用解决方案，它将多个 MySQL 服务器实例整合成一个集群，提供自动故障转移、数据强一致性和透明路由等功能。支持主从模式，多主模式。包含以下组件
MySQL Group Replication
简称MGR,是MySQL的主从同步高可用方案,包括数据同步及角色选举。 每个节点都运行 Group Replication，至少需要 3 个节点，以保证多数投票机制。Mysql Shell 管理工具
InnoDB Cluster的管理工具,用来创建和管理集群Mysql Router （路由中间件）
业务流量入口,无需关心实际数据节点。自动感知 主节点切换，更新路由规则 ，可以配置不同的端口分别对外提供读写服务,实现读写分离。–
MySQL Router与组复制和MySQL Shell高度整合，只有将其与组复制和MySQL Shell共同使用，才能够称为InnoDB Cluster。
InnoDB Cluster将三个MySQL数据库实例构成一个高可用集群。其中一个实例是具有读/写能力的主要成员，其他两个实例是具有只读能力的次要成员。组复制将数据从主要成员复制到次要成员。MySQLRouter将客户端应用程序连接到集群的主要成员。
搭建InnoDB Cluster需要满足如下条件
必须开启二进制日志，并且日志格式为ROW，即--log-bin和binlog_format=row（默认）； 必须开启副本更新日志，即log_replica_updates=ON（默认） ； 必须开启GTID，即gtid_mode=ON和enforce_gtid_consistency=ON。 存储引擎只能使用InnoDB。最好禁用其他存储引擎。