MySQL主从复制、高可用集群架构详解

一、复制ReplicationMySQL Replication是官方提供的主从同步方案也是用的最广的同步方案。Replication(复制)使来自一个 MySQL数据库服务器称为源Source的数据能够复制到一个或多个 MySQL 服务器称为副本Replica。默认情况下复制是异步的副本不需要永久连接即可从源接收更新。根据配置可以复制所有数据库、指定数据库甚至某个数据库中的指定表。说明 旧版本的 MySQL 复制将源Source称为主Master将副本Replica称为从Slave。其核心思想是主服务器负责处理写操作增、删、改然后将这些操作记录下來从服务器通过读取这些记录在自己的数据库上重新执行一遍从而保持与主数据库的数据一致性。1、主从模式的工作原理主从复制的核心是基于二进制日志Binary Log, Binlog。整个过程可以简化为三个步骤主库的更改记录Master Side当主服务器上发生数据变更如 INSERT, UPDATE, DELETE时这些变更语句或变更后的数据行会被写入到主服务器的二进制日志文件中。二进制日志就像是主数据库的“操作流水账”。从库的获取与中转Slave Side - I/O Thread每个从服务器都有一个I/O 线程。这个线程会连接到主服务器并请求读取主服务器的二进制日志。主服务器上有一个Binlog Dump 线程负责将二进制日志的内容发送给从服务器的 I/O 线程。从服务器的 I/O 线程将接收到的日志内容写入到本地的中继日志Relay Log中。从库的重放执行Slave Side - SQL Thread从服务器上还有一个SQL 线程。这个线程会读取本地的中继日志并解析出其中记录的 SQL 语句或行数据变更然后在从数据库上逐一执行这些 SQL 语句。这样从服务器上的数据就与主服务器保持同步了。2、主从模式的架构形式根据从库的数量和用途主从模式可以演变成多种架构一主一从最基本的模式用于数据备份或读写分离。一主多从一个主库对应多个从库。适用于读请求远大于写请求的场景通过多个从库分担读负载。双主复制主主复制两个服务器互为主从。任何一方的变更都会同步到另一方。这种架构更复杂需要处理自增ID冲突等问题通常用于需要高可用性的场景。级联复制Master - Slave - Slaves一个从库再作为其他从库的主库。这样可以减轻主库的压力因为主库只需要给一个从库发送日志但这个从库的延迟会影响它下面所有的从库。3、主从模式优缺点复制的优势:高可用通过配置一定的复制机制MySQL 实现了跨主机的数据复制从而获得一定的高可用能力如果需要获得更高的可用性只需要配置多个副本或者进行级联复制就可以达到目的。性能扩展读写分离由于复制机制提供了多个数据备份可以通过配置一个或多个副本将读请求分发至副本节点从而获得整体上读写性能的提升。异地灾备只需要将副本节点部署到异地机房就可以轻松获得一定的异地灾备能力。实际当中需要考虑网络延迟等可能影响整体表现的因素。交易分离通过配置复制机制并将低频、大运算量的交易发送至副本节点执行就可以避免这些交易与高频交易竞争运算资源从而避免整体的性能问题。缺点单点故障如果主库宕机需要手动或借助工具将从库提升为主库并调整应用配置这个过程存在服务中断时间。数据延迟由于复制是异步的默认方式从库的数据相对于主库会有一定的延迟。在高速写入的场景下延迟可能非常明显。对数据实时性要求极高的读操作如查询刚下的订单可能读到旧数据。负载与带宽压力从库过多对主库的负载以及网络带宽都会带来很大的负担数据一致性问题如果网络中断或从库宕机恢复后可能面临数据不一致的风险需要人工干预来修复。4、应用场景电子商务平台 在电商平台中主从复制可以用于实现读写分离提高并发处理能力同时确保数据的一致性。社交网络 在社交网络应用中可以利用主从复制来提供快速的读取服务同时将数据变更复制到从数据库以备份数据。实时监控和报警系统 在监控系统中主从复制可以用于实现数据的分布式存储和快速数据查询。新闻和媒体网站 在高访问量的新闻网站中可以使用主从复制来提供高可用性和快速的内容访问。金融服务 在金融行业数据的安全性和可用性至关重要主从复制可以用于数据备份和高可用性的实现。二、复制的方式MySQL 8.0支持多种复制方式传统的方法是基于从源的二进制日志binlog复制事件并要求日志文件及其中的位置在源和副本之间进行同步。作为源(数据库更改发生的地方)的 MySQL 实例将更新和更改作为“事件”写入二进制日志。根据所记录的数据库更改二进制日志中的信息以不同的日志格式存储。副本配置为从源中读取二进制日志并在副本的本地数据库上执行二进制日志中的事件。#获取binlog文件列表 mysql show binary logs; #查看指定binlog文件的内容 mysql show binlog events in binlog.000003;参考官网https://dev.mysql.com/doc/refman/8.0/en/binlog-replication-configuration-overview.html基于全局事务标识符(GTID)的方式。基于 GTID 的复制是完全基于事务的所以很容易确定源和副本是否一致;只要在源上提交的所有事务也在副本上提交就可以保证两者之间的一致性。参考官网 https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html三、主从复制数据同步类型MySQL 中的复制支持不同类型的同步。同步的原始类型是单向异步复制其中一个服务器充当源而一个或多个其他服务器充当副本。在 MySQL 8.0中除了内置的异步复制之外还支持半同步复制。使用半同步复制在返回执行事务的会话之前对源执行提交直到至少有一个副本确认它已经接收并记录了事务的事件。MySQL 8.0还支持延迟复制以使副本故意落后于源至少指定的时间。1、异步复制默认情况下MySQL 采用异步复制的方式执行事务操作的线程不会等复制 Binlog 的线程。具体的时序你可以看下面这个图主库在收到客户端的事务提交请求写入 Binlog主库提交事务更新存储引擎中的数据主库事务提交完成给客户端返回操作成功的响应从库有一专门的复制线程从主库接收 Binlog从库把 Binlog 写到一个中继日志里面给主库返回复制成功的响应从库还有另外一个回放 Binlog 的线程去读中继日志然后回放 Binlog 更新存储引擎中的数据提交事务和复制这两个流程在不同的线程中执行互相不会等待这是异步复制。异步复制的劣势是可能存在主从延迟如果主节点宕机可能会丢数据。2、半同步复制MySQL 从 5.7 版本开始增加一种半同步复制Semisynchronous Replication的方式。这种机制与异步复制相比主要有如下区别主节点在收到客户端的请求后必须在完成本节点日志写入的同时还需要等待至少一个从节点完成数据同步的响应之后或超时才会响应请求。从节点只有在写入 relay-log 并完成刷盘之后才会向主节点响应。当从节点响应超时时主节点会将同步机制退化为异步复制。在至少一个从节点恢复并完成数据追赶后主节点会将同步机制恢复为半同步复制。可以看出相比于异步复制半同步复制在一定程度上提高了数据的可用性在未退化至异步复制时如果主节点宕机此时数据已复制至至少一台从节点。同时由于向客户端响应时需要从节点完成响应相比于异步复制此时多出了主从节点上网络交互的耗时以及从节点写文件并刷盘的耗时因此整体上集群对于客户端的响应性能表现必然有所降低。半同步复制有两个重要的参数rpl_semi_sync_master_wait_slave_count8.0.26之后改为rpl_semi_sync_source_wait_for_replica_count至少等待数据复制到几个从节点再返回。这个数量配置的越大丢数据的风险越小但是集群的性能和可用性就越差。rpl_semi_sync_master_wait_point8.0.26之后改为rpl_semi_sync_source_wait_point这个参数控制主库执行事务的线程是在提交事务之前AFTER_SYNC等待复制还是在提交事务之后AFTER_COMMIT等待复制。默认是 AFTER_SYNC也就是先等待复制再提交事务这样就不会丢数据。3、基于binlog位点同步的主从复制原理主库会生成多个 binlog 日志文件从库的 I/O 线程请求指定文件和指定位置的 binlog 日志文件位点主库 dump 线程获取指定位点的 binlog 日志主库按照从库发送给来的位点信息读取 binlog然后推送 binlog 给从库从库将得到的 binlog 写到本地的 relay log (中继日志) 文件中从库的 SQL 线程读取和解析 relay log 文件从库的 SQL 线程重放 relay log 中的命令弊端1首次开启主从复制的步骤复杂第一次开启主从同步时要求从库和主库是一致的。找到主库的 binlog 位点。设置从库的 binlog 位点。开启从库的复制线程。弊端2恢复主从复制的步骤复杂找到从库复制线程停止时的位点。解决复制异常的事务。无法解决时就需要手动跳过指定类型的错误比如通过设置 slave_skip_errors1032,1062。当然这个前提条件是跳过这类错误是无损的。1062 错误是插入数据时唯一键冲突1032 错误是删除数据时找不到行不论是首次开启同步时需要找位点和设置位点还是恢复主从复制时设置位点和忽略错误这些步骤都显得过于复杂而且容易出错。MySQL 5.6 版本引入了 GTID彻底解决了这个困难。4、基于全局事务标识符 GTID (Global Transaction Identifiers)复制参考官网 https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.htmlGTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单以及数据库一致性更可靠。一个GTID在一个服务器上只执行一次避免重复执行导致数据混乱或者主从不一致。GTID用来代替传统复制方法不再使用MASTER_LOG_FILEMASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION1的方式开始复制。在传统的replica端binlog是不用开启的但是在GTID中replica端的binlog是必须开启的目的是记录执行过的GTID强制。4.1、GTID 的优势更简单的实现 failover不用以前那样在需要找位点log_file 和 log_pos。更简单的搭建主从复制。比传统的复制更加安全。GTID 是连续的没有空洞的保证数据的一致性零丢失。4.2、GTID结构GTID表示为一对坐标由冒号(:)分隔如下所示:GTID source_id:transaction_idsource_id标识source服务器即源服务器唯一的server_uuid由于GTID会传递到replica所以也可以理解为源ID。transaction_id是一个序列号由事务在源上提交的顺序决定。序列号的上限是有符号64位整数2^63-1例如最初要在UUID为 “3E11FA47-71CA-11E1-9E33-C80AA9429562” 的服务器上提交的第23个事务具有此GTID3E11FA47-71CA-11E1-9E33-C80AA9429562:23GTID集合是由一个或多个GTID或GTID范围组成的集合。来自同一服务器的一系列gtid可以折叠成单个表达式如下所示:3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5源自同一服务器的多个单一gtid或gtid范围也可以包含在单个表达式中gtid或范围以冒号分隔如下例所示:3E11FA47-71CA-11E1-9E33-C80AA9429562:1-3:11:47-49GTID集合可以包括单个GTID和GTID范围的任意组合也可以包括来自不同服务器的GTID。2174B383-5441-11E8-B90A-C80AA9429562:1-3, 24DA167-0C0C-11E8-8442-00059A3C7B00:1-19GTID存储在mysql数据库中名为gtid_executed的表中。该表中的一行包含它所代表的每个GTID或GTID集合的起始服务器的UUID以及该集合的开始和结束事务id。4.3、GTID工作原理主库计算主库 GTID 集合和从库 GTID 的集合的差集主库推送差集 binlog 给从库。当从库设置完同步参数后主库 A 的 GTID 集合记为集合 x从库 B 的 GTID 集合记为 y。从库同步的逻辑如下从库 B 指定主库 A基于主备协议建立连接。从库 B 把集合 y 发给主库 A。主库 A 计算出集合 x 和集合 y 的差集也就是集合 x 中存在集合 y 中不存在的 GTID 集合。比如集合 x 是 1~100集合 y 是 1~90那么这个差集就是 91~100。这里会判断集合 x 是不是包含有集合 y 的所有 GTID如果不是则说明主库 A 删除了从库 B 需要的 binlog主库 A 直接返回错误。主库 A 从自己的 binlog 文件里面找到第一个不在集合 y 中的事务 GTID也就是找到了 91。主库 A 从 GTID 91 的事务开始往后读 binlog 文件按顺序取 binlog然后发给 B。从库 B 的 I/O 线程读取 binlog 文件生成 relay logSQL 线程解析 relay log然后执行 SQL 语句。4.4、GTID 同步方案和位点同步的区别位点同步方案是通过人工在从库上指定哪个位点主库就发哪个位点不做日志的完整性判断。而 GTID 方案是通过主库来自动计算位点的不需要人工去设置位点对运维人员友好。4.5、GTID的配置1 修改主库配置#GTID: #启用全局事务标识符GTID模式 gtid_modeon # 强制GTID的一致性。这意味着在执行事务时MySQL将确保所有涉及的服务器都使用相同的GTID集。 enforce_gtid_consistencyon2修改从库配置#GTID: #启用全局事务标识符GTID模式 gtid_modeon # 强制GTID的一致性。这意味着在执行事务时MySQL将确保所有涉及的服务器都使用相同的GTID集。 enforce_gtid_consistencyon从节点设置主库信息# 从库配置同步参数 mysql CHANGE MASTER TO MASTER_HOST host, MASTER_PORT port, MASTER_USER user, MASTER_PASSWORD password, MASTER_AUTO_POSITION 1; Or from MySQL 8.0.23: mysql CHANGE REPLICATION SOURCE TO SOURCE_HOST host, SOURCE_PORT port, SOURCE_USER user, SOURCE_PASSWORD password, SOURCE_AUTO_POSITION 1;SOURCE_AUTO_POSITION 1 这告诉从服务器使用自动位置跟踪功能以便它可以自动从主服务器获取最新的二进制日志事件而无需手动指定位置。四、组复制Group Replication参考文档 https://dev.mysql.com/doc/refman/8.0/en/group-replication.html1、组复制概念由于传统异步复制的缺陷可能会导致主从数据不一致的问题在主节点异常宕机时从节点可能造成数据丢失。基于这个缺陷Mysql5.7.17推出了一个高可用与高扩展的解决方案Mysql Group Replication(简称MGR)将原有的gtid复制功能进行了增强支持单主模式和多主模式。组复制在数据库层面上做到了只要集群中大多数主机可用则服务可用也就是说3台服务器的集群允许其中1台宕机。Group Replication提供了分布式状态机制服务器之间具有很强的协调性。当服务器属于同一组时它们会自动进行协调。该组可以在具有自动选主的单主模式下运行在这种模式下一次只有一台服务器接受更新。或者对于更高级的用户可以在多主模式下部署该组其中所有服务器都可以接受更新即使它们是并发执行的。与传统复制相比Group Replication有以下大幅改进传统复制的主从复制方式有一个主和不等数量的从。主节点执行的事务会异步发送给从节点在从节点重新执行。而Group Replication采用整组写入的方式避免了单点争用。Group Replication在传输数据时使用了Paxos协议。Paxos协议保证了数据传输的一致性和原子性。基于Paxos协议Group Replication构建了一个分布式的状态复制机制这是实现多主复制的核心技术。Group Replication提供了多写方案为多活方案带来了实现的可能。MGR 能保证数据库服务的连续可用却无法处理如下问题当一个组成员变为不可用时连接到它的客户端必须被重定向或故障转移到其他组成员。此时需要使用连接器、负载均衡器、路由器或某种形式的中间件例如 MySQL Router 8.0 。MGR 本身不提供这些工具。此时便引入了 InnoDB Cluster 后面详述。2、单主模式参考文档https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html组中的每个MySQL服务器实例都可以在独立的物理主机上运行这是部署组复制的推荐方式。在单主模式下(group_replication_single_primary_modeON)组中只有一个主服务器该主服务器被设置为读写模式。组中的所有其他成员都被设置为只读模式(super_read_onlyON)。查找primary的两种方式# 方式1查询performance_schema.replication_group_members的MEMBER_ROLE列 mysql SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members; -------------------------------------- | MEMBER_HOST | MEMBER_ROLE | -------------------------------------- | remote1.example.com | PRIMARY | | remote2.example.com | SECONDARY | | remote3.example.com | SECONDARY | -------------------------------------- # 方式2查看group_replication_primary_member变量状态 mysql SHOW STATUS LIKE group_replication_primary_member;3、多主模式参考文档https://dev.mysql.com/doc/refman/8.0/en/group-replication-multi-primary-mode.html在多主模式下(group_replication_single_primary_modeOFF)没有成员具有特殊的角色。任何与其他组成员兼容的成员在加入组时都被设置为读写模式并且可以处理写事务即使它们是并发发布的。如果一个成员停止接受写事务例如在服务器意外退出的情况下连接到它的客户端可以被重定向或故障转移到处于读写模式的任何其他成员。Group Replication本身不处理客户端故障转移因此需要使用中间件框架(如MySQL Router 8.0)、代理、连接器或应用程序本身来安排。五、MySQL Innodb Cluster(高可用集群架构)MySQL InnoDB Cluster是MySQL官方实现高可用读写分离的架构方案它由下面这几个组件构成MySQL Group Replication简称MGR是MySQL的主从同步高可用方案包括数据同步及角色选举提供DB的扩展、自动故障转移MySQL Router轻量级中间件是业务流量入口支持对MGR的主从角色判断,可以配置不同的端口分别对外提供读写服务,实现读写分离MySQL Shell新的MySQL客户端多种接口模式。可以设置群组复制及RouterX DevAPI一个API通过XProtocol与服务器通信Admin API一个特殊的API通过MySQL Shell使用可以用于对Innodb Cluster进行配置管理MySQL Router与组复制和MySQL Shell高度整合只有将其与组复制和MySQL Shell共同使用才能够称为InnoDB Cluster。InnoDB Cluster将三个MySQL数据库实例构成一个高可用集群。其中一个实例是具有读/写能力的主要成员其他两个实例是具有只读能力的次要成员。组复制将数据从主要成员复制到次要成员。MySQL Router将客户端应用程序连接到集群的主要成员。实际案例参考文档https://note.youdao.com/s/5CZH2GrMhttps://note.youdao.com/s/2EjCTYwRhttps://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html