盐亭做网站,简单网站开发实例教程,规模以上工业企业名单,旅游最新消息一、MySQL 主从复制概述
#xff08;一#xff09;定义与作用
MySQL 主从复制是一种允许在多个 MySQL 数据库服务器之间进行数据同步的技术。简单来说#xff0c;就是可以把数据从一个 MySQL 服务器#xff08;主服务器、主节点#xff09;复制到一个或多个从节点#…一、MySQL 主从复制概述
一定义与作用
MySQL 主从复制是一种允许在多个 MySQL 数据库服务器之间进行数据同步的技术。简单来说就是可以把数据从一个 MySQL 服务器主服务器、主节点复制到一个或多个从节点使得从节点的数据与主节点保持一致。
其作用十分显著首先在提高数据库可用性方面当主服务器出现问题时比如宕机、硬件故障等可以快速切换到从服务器提供服务避免业务中断实现高可用架构。例如在一些电商平台的大促活动期间如果主数据库服务器出现意外从服务器能及时顶上保障用户正常下单、查询订单等操作不受太大影响。
在提升性能上通过主从复制能够实现读写分离将增删改的请求操作发送到主库而查询的请求操作引导至从库。这样可以分担主库的负载尤其是在读取操作频繁的场景下能有效缓解主库压力提升整体数据库的响应速度。像新闻资讯类网站大量用户同时访问查看新闻内容读操作利用从库来处理这些读请求能让用户更快地获取到信息。
另外主从复制对于数据备份恢复也极为重要。可以在从库上执行备份操作避免备份期间影响主库服务并且在遇到数据丢失等情况时利用从库的数据进行恢复保障数据的安全性和完整性。
二常见架构模式
1. 一主一从 / 一主多从
一主一从这是最基础、成本相对较低的主从架构方式。一台服务器作为主服务器M负责写入或读取数据另一台服务器作为从服务器S只负责读取数据并且会从主服务器上下载数据来保持数据同步。它主要是用来做数据的热备也就是当主节点挂掉的话从节点能充当主节点继续提供服务提高程序可用性容灾性较好。不过它的适用场景相对有限不存在数据一致性问题因为只从一个节点中读取但也有不足比如无法做数据备份非高可用如果不小心在主节点执行了如 DROP 这类操作从节点则马上同步这个操作所以也无法在从节点中找回数据。例如一些小型的企业内部管理系统对读写性能要求不是特别高使用一主一从架构就能满足基本的数据备份和容灾需求。
一主多从通常会选取一个节点做主服务器备份如果主服务器挂了则有从服务器马上充当主服务器节点继续进行服务。还可以选取另一个从节点专门用来做慢查询、或统计操作等。这种架构适合写入较少但读取较多的场景能通过将大量的读请求通过负载均衡分布到多个从库上对于实时性要求很高的读请求可以让从主库去读降低主库的读取压力。不过随着从库数量的增加主库的负载以及网络带宽压力也会相应增大因为每个从库都会在主库上有一个独立的 BINLOG Dump 线程来获取数据。比如大型的社交平台用户查看动态、消息等读操作非常频繁采用一主多从架构能更好地应对高并发的读请求。
2. 多主一从
从 MySQL 5.7 开始支持多主一从模式多源主从复制技术Multi-Source Replication这种模式可以将多个库的数据备份到一个库中存储。它的优势在于能够汇聚数据尤其是在分库分表的一些场景中方便进行集中的数据统计分析操作数据集中存放可避免服务器等软硬件资源浪费也方便在一台服务器备份所有已收到的数据库数据还可用于异地备份项目等。例如在一个集团公司内部不同业务部门有各自独立的数据库多个主库需要将这些数据整合起来做统一的数据分析、报表生成等工作就可以采用多主一从的架构将各部门的数据同步到一个从库中进行处理。
3. 双主复制
双主复制的原理是两个 MySQL 服务器互做对方的从也就是双方都可以同时进行读写操作互为主从。它适用于写压力比较大的业务场景例如一些大型的在线游戏平台玩家频繁地进行游戏数据的更新写操作通过双主复制可以分担写的压力。同时在 DBA 做维护需要主从切换时也比较方便只要配置好互为主从的关系切换过程相对简单。不过双主复制也存在一定风险比如可能会出现数据冲突的情况像两个主服务器同时对同一行数据进行修改就需要采取相应的冲突检测和解决策略比如采用最后修改者胜出的策略或者采用合并的方式等。
4. 级联复制
在级联复制模式下部分从节点连接到上一级从节点而不是直接连接主节点。这样做的优点是可以缓解主服务器的压力因为主服务器既要处理写操作又要应对多个从节点的读请求通过级联的从节点进行分压操作能减少主服务器的负担。例如在一个有大量从服务器的架构中让一部分从服务器先连接到几个中间的从服务器上形成多级的结构。但这种模式也存在弊端就是数据同步延迟可能会较大相比于直接从主节点同步数据经过多级传递会花费更多时间来保证数据的一致性。
二、MySQL 主从复制原理
一基于 Binlog 的复制流程
MySQL 主从复制是基于 Binary Log二进制文件简称 bin log来实现的其流程如下
首先在主数据库这边当有写操作例如 INSERT、UPDATE、DELETE 等语句执行发生时这些操作的记录会被按照相应的 binlog 格式记录到二进制日志文件binlog中。这相当于主数据库把自己数据的变更情况都详细记录了下来就好比是在写日记一样把每一笔重要的 “数据操作账” 都记好。
接着从数据库会启动一个 IO 线程这个 IO 线程会负责连接到主数据库然后去请求获取主数据库的 binlog 内容。主数据库收到从数据库 IO 线程的请求后就会把自己记录好的 binlog 信息传输给从数据库的 IO 线程该线程获取到 binlog 内容后会把这些内容先写入到从数据库本地的 Relay Log中继日志里面。
最后从数据库还有一个 SQL 线程它会不断地去监测 Relay Log一旦发现里面有新的内容就会从中读取相关的数据变更记录并在从数据库中执行这些操作把相应的数据变更应用到从数据库上使得从数据库的数据和主数据库的数据保持一致。这样通过这样一套基于 Binlog 的流程就实现了主从数据库之间的数据复制。
二Bin Log 日志格式
1. STATEMENT 格式语句模式
STATEMENT 格式下binlog 记录的是执行的 SQL 语句文本。比如说执行了一条 “UPDATE user SET age 25 WHERE name 张三 ” 这样的 SQL 语句来更新用户表中张三的年龄信息那么这条 SQL 语句的文本就会原原本本地被记录到 binlog 里面。
它有着明显的优点一方面日志文件相对较小因为只是记录了执行的语句而不是详细到每一行数据具体的变化情况这样就节省了一定的存储空间也便于后续查看日志时进行理解和审计工作查看日志就能清楚地知道执行过哪些操作语句了。
然而它也存在缺点。由于不同的数据库环境可能会存在差异例如在使用了非确定性函数像 RAND () 函数生成随机数、SYSDATE () 获取系统时间等、时间戳等情况下当从数据库重放这些记录的 SQL 语句时可能会因为环境不同而导致数据不一致的情况出现。比如主数据库执行时生成的随机数和从数据库执行时生成的随机数不一样那就会让数据出现偏差了。
2. ROW 格式行模式
ROW 格式则是记录每一行数据更改的具体内容。比如在一张包含多条用户信息记录的表中对某一行用户数据进行了修改ROW 格式的 binlog 就会详细记录这一行原来是哪些数据被修改后变成了哪些数据是真正精确到每一行的具体变化情况的。
这种格式的优点很突出它能够精确地记录数据变化不管是在何种复杂的操作或者数据库环境下都可以避免出现像 STATEMENT 格式那样因为环境依赖而导致的数据不一致问题确保在从数据库重放这些数据变更时能够得到和主数据库一致的结果。
但相应地它也有不足之处。由于要记录每一行数据的详细变化所以日志文件通常会比较大尤其是在大量数据更新的情况下会产生海量的日志记录内容这无疑会增加 I/O 开销对存储资源以及读取日志时的性能都会产生一定的影响。
3. MIXED 格式混合模式
MIXED 格式具有独特的特性它可根据具体执行的 SQL 语句和操作自动选择使用 STATEMENT 或 ROW 格式。例如对于一些普通的、不会导致数据一致性问题的简单数据修改语句可能就会采用 STATEMENT 格式进行记录而如果遇到像使用了某些特殊函数、或者涉及到复杂的数据变更情况时它就会切换到 ROW 格式来记录以此保证数据的准确复制。
它的优点在于结合了 STATEMENT 和 ROW 两种格式的长处在保证数据一致性的同时又尽可能地减小了日志文件的大小试图在两者之间达到一种较好的平衡。
不过这种格式也并非完美无缺由于它需要根据不同情况自动切换记录格式所以逻辑相对复杂在实际使用中可能需要更复杂的管理和监控手段。而且在一些特定的复杂场景下可能无法达到最优的性能或者确保完全的数据一致性需要数据库管理员根据实际情况仔细权衡和调整。
三主从复制模式
1. 异步复制
异步复制是 MySQL 主从复制中最常见的一种模式。在这个模式下主服务器会将数据修改操作记录到二进制日志binlog中然后通过相应的机制把这些日志传输给从服务器。这里的关键在于 “异步”也就是说主服务器在把 binlog 传输给从服务器后并不会等待从服务器是否成功应用这些日志来更新数据而是直接继续处理后续的事务操作并且可以立即向使用者返回操作成功的响应这样就保证了主服务器的处理性能不受从服务器的影响能够及时响应使用者的各种请求有着很好的响应及时性。
但这种模式也存在明显的缺点由于主从之间的数据复制是异步进行的所以就会存在一定的数据传输延迟情况从服务器的数据更新可能会落后于主服务器在极端情况下如果主服务器出现故障可能会有部分还没来得及复制到从服务器的数据丢失导致复制过程的可靠性有所欠缺数据的一致性无法时刻得到保证。
2. 半同步复制
半同步复制模式相较于异步复制有其独特之处。在这个模式下主服务器在执行完一个事务并将相关数据修改操作记录到二进制日志binlog后不会像异步复制那样直接返回给客户端操作成功的响应而是会等待至少一个从服务器接收到这个 binlog 并成功将其应用到本地数据库也就是确认从服务器已经把相应的数据变更完成后主服务器才会向客户端返回事务提交成功的消息。
这样做的好处就是在数据一致性方面有了更强的保障相比于异步复制大大降低了主服务器崩溃时数据丢失的风险因为至少有一个从服务器已经保存了最新的事务数据。不过相应地它也有一定的代价那就是写操作的响应时间会有所增加毕竟主服务器需要等待从服务器的确认性能上相比异步复制会略有下降但又比完全同步复制那种需要所有从服务器都确认的模式延迟要小一些它只需要有一个从服务器确认即可。这种模式适用于对数据一致性有一定要求同时又能接受一定程度性能损耗的业务场景。
三、MySQL 主从复制实践操作
一配置主服务器
1. 添加配置参数
在主服务器的配置文件my.cnf中我们需要添加几个关键的参数来实现主从复制功能。首先是设置服务器 IDserver-id例如 “server-id 1”这个 ID 在整个主从复制架构中必须是唯一的它用于区分不同的 MySQL 服务器实例就好比每个人都有独一无二的身份证号码一样服务器通过这个 ID 来识别彼此。
另外要开启二进制日志binary logging通过设置 “log-bin mysql-bin” 参数来实现这里 “mysql-bin” 是二进制日志文件的文件名前缀MySQL 会自动添加数字索引来区分不同的日志文件。二进制日志的作用十分重要它会记录主服务器上所有的数据变更操作像 INSERT、UPDATE、DELETE 等语句执行时产生的数据变化都会被详细记录下来为后续从服务器获取并同步这些变更提供依据。可以说二进制日志是主从复制的核心 “数据源”没有它从服务器就不知道该如何去更新数据来保持和主服务器一致了。
2. 创建复制用户
在主服务器上我们需要创建一个专门用于主从复制的用户。可以通过以下 SQL 命令来完成操作例如创建一个名为 “replication_user”密码为 “password”且允许从指定 IP 地址假设从服务器 IP 为 “192.168.1.100”访问的用户并授予其 REPLICATION SLAVE 权限具体命令如下 CREATE USER replication_user192.168.1.100 IDENTIFIED BY password;
GRANT REPLICATION SLAVE ON *.* TO replication_user192.168.1.100;
FLUSH PRIVILEGES;
这里“CREATE USER” 语句用于创建新用户指定用户名、访问主机即从服务器的 IP 地址以及密码“GRANT REPLICATION SLAVE ON .” 则是授予该用户复制相关的权限“.” 表示对所有数据库和所有表都有复制权限最后 “FLUSH PRIVILEGES” 命令用于刷新权限使刚才设置的权限立即生效。这样从服务器就可以使用这个用户来连接主服务器并获取二进制日志等相关数据进行复制操作了。
3. 查看主服务器状态
配置好上述参数和创建好复制用户后我们需要查看主服务器的状态通过执行 “SHOW MASTER STATUS;” 命令来实现。执行这个命令后会展示出一些关键的信息比如当前二进制日志文件的名称File 值以及在这个文件中的位置Position 值。
例如可能会得到类似如下的结果 File: mysql-bin.000010
Position: 1234
这些值一定要记录下来因为后续在配置从服务器时需要准确地指定从哪个二进制日志文件的哪个位置开始获取数据进行同步它们就像是一个 “数据同步的起点坐标”确保从服务器能准确无误地跟上主服务器的数据变更进度保证主从数据的一致性。
二配置从服务器
1. 添加配置参数
在从服务器的配置文件my.cnf里同样需要添加服务器 IDserver-id参数不过其值要和主服务器的不同比如设置为 “server-id 2”。记住每个主从服务器的 ID 必须唯一否则会导致复制出现问题MySQL 无法准确区分不同的服务器角色。添加好参数后需要重启从服务器使得这个配置生效只有重启后服务器才能按照新的配置参数来运行相关服务就像电脑安装了新的软件或者更新了配置后有时候需要重启才能让这些改变生效一样。
2. 设置主服务器信息
在从服务器的 MySQL 中要执行相应的命令来设置主服务器的相关信息使用 “CHANGE MASTER TO” 语句具体示例如下 CHANGE MASTER TO
MASTER_HOST192.168.1.101, -- 这里替换为主服务器的实际IP地址
MASTER_USERreplication_user, -- 之前在主服务器创建的复制用户
MASTER_PASSWORDpassword, -- 对应的密码
MASTER_LOG_FILEmysql-bin.000010, -- 之前在主服务器查看记录的File值
MASTER_LOG_POS1234; -- 之前在主服务器查看记录的Position值
这里要特别注意将命令中的各个参数都替换为实际准确的值确保从服务器能够正确地连接到主服务器并从对应的二进制日志位置开始进行数据同步操作这样才能保证主从复制流程准确无误地启动起来。
3. 启动复制进程与检查状态
完成上述配置后就可以在从服务器上启动复制进程了通过执行 “START SLAVE;” 命令来开启。启动之后为了确保复制是正常进行的我们需要通过 “SHOW SLAVE STATUS\G;” 命令来检查从服务器的复制状态。在查看结果中重点关注 “Slave_IO_Running” 和 “Slave_SQL_Running” 这两个线程状态的值它们都应该为 “YES”才表示主从复制正在正常工作。
例如正常情况下会看到类似如下展示 Slave_IO_Running: YES
Slave_SQL_Running: YES
如果这两个值其中有一个或者两个都是 “NO”那就说明主从复制出现了问题需要进一步去排查可能是网络连接问题、权限问题或者配置参数错误等原因导致的要及时发现并解决这些问题以保障主从服务器之间的数据能够准确同步。
四、MySQL 高可用架构解析
一高可用架构的重要性
在实际的生产环境中MySQL 高可用架构有着至关重要的意义它是保障业务连续性的关键所在。一旦数据库出现故障对于业务的影响往往是十分严重的。例如对于电商平台而言如果数据库发生故障那么用户将无法正常下单、查询订单以及进行商品浏览等操作这可能导致大量用户流失给企业带来巨大的经济损失又如在线支付系统数据库故障会使支付流程中断严重影响交易的正常进行损害用户体验以及企业信誉。再比如一些大型企业的内部管理系统若数据库不可用员工无法进行诸如考勤、流程审批、资源调配等操作整个企业的运营效率会大幅下降。所以通过构建高可用架构能在数据库面临各种意外情况时确保业务依然可以正常运转最大程度减少对业务的不良影响。
二常见高可用架构方案
1. MMM 架构
MMMMaster-Master replication manager for MySQL架构是一套支持双主故障切换和双主日常管理的脚本程序使用 Perl 语言开发主要用于监控和管理 MySQL 的主主复制拓扑。
在 MMM 架构中虽然是双主模式但业务上同一时刻只有一个主对外提供写入服务另一个则作为备份主可提供部分读服务这有助于在主主切换时刻加速备选主的预热。它具备读写 VIP虚拟 IP使得服务器角色的变更对前端应用来说是透明的也就是应用无需关心后端数据库服务器的角色变化都能正常访问。
从优点方面来看它是完全开源的提供了从服务器的延迟监控功能并且在主数据库故障转移后能方便地实现从服务器对新主的重新同步还很容易让发生故障的主数据库重新上线。然而MMM 架构也存在一些不足比如发布时间比较早不支持 MySQL 新的复制功能像基于 GTID 的复制没有读负载均衡的功能在进行主从切换时容易造成数据丢失而且其监控服务存在单点故障。
总体而言MMM 架构适用于对数据一致性要求不是特别高且读写操作相对不那么频繁、对成本有一定控制需求的场景例如一些小型的企业内部办公系统等。
2. MHA 架构
MHAMaster High Availability是由日本 MySQL 大牛用 Perl 编写的一套 MySQL 故障切换方案旨在保证数据库系统的高可用。它能在宕机事件内通常 10 - 30 秒完成故障转移可避免主从一致性问题还能节约购买新服务器的费用并且不影响服务器性能安装相对容易也不会改变现有部署架构。
其原理是 MHA 会监控 master 节点的故障情况当检测到 master 节点出现故障时它会通过分析各个从节点的中继日志等信息找出拥有最新数据的从节点然后将其提升为新的 master 节点。在此期间MHA 会与其它从节点交互获取额外信息来避免一致性方面的问题。此外MHA 还提供了 master 节点的在线切换功能可按需切换 master/slave 节点。
MHA 的优势较为明显它可以支持 GTID 复制能够选举最合适的从节点成为新的 master 节点自动完成从 master 的监控到故障转移的全部流程当然也可手动执行故障转移可在秒级单位内实现故障转移还具备在多个点上调用外部脚本的功能能应对如电源 OFF 或者 IP 地址变化等故障转移情况而且安装和卸载不用停止当前的 mysql 进程自身不会增加服务器负担也不依赖存储引擎以及二进制文件的格式不论是 STATEMENT 模式还是 ROW 模式。
不过MHA 也存在一定的缺点例如需要自行开发实现 VIP 的配置并且它主要侧重于监控主节点是否可用对于从节点的监控相对不足。MHA 架构比较适用于一主多从的环境尤其是在 MySQL 的主从复制采用异步或是半同步方式且对数据一致性有一定要求、希望能快速进行故障切换的业务场景中比如一些互联网应用的后台数据库系统等。
3. Keepalived 主主复制架构
Keepalived 结合 MySQL 主主复制能够实现高可用的架构模式。在这种架构下MySQL 的双主服务器互做对方的从双方都可同时进行读写操作实现了数据的冗余备份。
Keepalived 在这里起到了关键的监测、自动重启以及流量切换等作用。它可以实时监测数据库服务的状态一旦发现主服务器出现故障比如进程意外终止或者网络连接异常等情况Keepalived 能够自动进行相应的处理例如尝试重启服务若故障无法恢复它会进行流量切换将原本指向故障主服务器的请求引导至正常的服务器上确保业务的连续性。
该架构的优势在于能有效保障数据库的高可用性提升了整个系统应对故障的能力而且配置相对来说不算过于复杂通过合理的设置就能让数据库服务具备较好的容错性。同时在一些对可靠性要求较高、但读写操作压力相对均衡的场景中表现出色比如实时在线 OA 系统、政府部门网站系统等这些场景下虽然流量和压力可能不是特别大但对服务器的可靠性要求极高Keepalived 主主复制架构就能很好地满足需求。
五、总结与展望
一回顾重点内容
在本文中我们详细探讨了 MySQL 主从复制与高可用架构相关的诸多内容。
首先了解了 MySQL 主从复制的概述主从复制是一种能在多个 MySQL 数据库服务器之间进行数据同步的技术其作用体现在提高数据库可用性、提升性能以及便于数据备份恢复等方面。常见的架构模式包含一主一从 / 一主多从、多主一从、双主复制、级联复制等每种模式都有其适用场景与优缺点像一主一从适用于小型企业内部管理系统做简单的数据备份和容灾一主多从适合写入少读取多的场景可应对高并发读请求多主一从便于数据汇聚与集中统计分析双主复制适用于写压力大的业务场景级联复制可缓解主服务器压力但可能存在数据同步延迟问题。
接着深入研究了主从复制原理基于 Binlog 的复制流程涵盖主数据库记录操作到 binlog从数据库通过 IO 线程获取 binlog 并写入 Relay Log再由 SQL 线程将 Relay Log 中的变更应用到从数据库上这几个关键步骤。Bin Log 日志有 STATEMENT、ROW、MIXED 三种格式各有优劣例如 STATEMENT 格式日志文件小但可能因环境差异导致数据不一致ROW 格式能精确记录数据变化但日志文件大MIXED 格式则结合二者长处平衡日志大小与数据一致性。主从复制模式包括异步复制、半同步复制等异步复制响应及时但存在数据丢失风险及传输延迟问题半同步复制保障了数据一致性但会增加写操作响应时间。
在实践操作部分分别介绍了主服务器和从服务器的配置步骤。主服务器配置需添加如设置服务器 ID、开启二进制日志等参数创建用于复制的用户并查看主服务器状态从服务器配置同样要添加服务器 ID 参数、设置主服务器信息、启动复制进程并检查状态确保各个环节准确无误才能保证主从复制正常运行。
关于 MySQL 高可用架构其重要性在于保障业务连续性避免因数据库故障给业务带来严重影响。常见的高可用架构方案有 MMM 架构、MHA 架构、Keepalived 主主复制架构等。MMM 架构适用于对数据一致性要求不高、读写操作不太频繁的场景MHA 架构侧重于一主多从环境且对数据一致性有要求、希望快速故障切换的业务场景Keepalived 主主复制架构则在可靠性要求高、读写压力相对均衡的场景中表现出色。
通过对这些核心知识点的梳理希望能帮助读者更好地理解和掌握 MySQL 主从复制与高可用架构相关内容以便在实际应用中根据具体业务需求进行合理的选择与部署。
二对未来应用的展望
随着业务的不断发展以及数据量的持续增长MySQL 主从复制与高可用架构也将面临更多的挑战与机遇。
一方面在未来业务愈发复杂、数据规模越发庞大的情况下对于数据一致性和实时性的要求可能会进一步提高。现有的主从复制模式或许需要不断优化例如半同步复制模式可能会在保证数据一致性的同时通过技术改进进一步降低写操作的响应延迟以更好地适应对实时性要求严苛的业务场景像金融交易类系统等确保每一笔交易数据能快速且准确地在主从节点间同步避免因数据延迟或不一致带来的风险。
另一方面高可用架构也会朝着更智能、更自动化的方向发展。例如当前的故障切换机制虽然已经能够在一定程度上保障业务连续性但未来可能会结合人工智能、机器学习等技术实现对数据库状态的实时精准监测与预测提前发现潜在故障隐患并自动进行优化调整甚至可以根据业务负载情况动态地调整主从节点的配置比如自动增加或减少从节点数量来应对不同时段的读写压力变化从而提升整个架构的资源利用效率和应对故障的能力。
同时新的技术和需求也可能催生出更多创新的高可用架构方案。就如同从早期的经典主从复制发展到如今集成多种功能的 InnoDB Cluster 等架构一样未来或许会有基于云计算、分布式存储等新兴技术融合的高可用架构出现更好地满足企业在不同业务场景下对 MySQL 数据库高可用性、高性能、易扩展等多方面的需求助力企业在数字化转型进程中保障数据的安全可靠以及业务的稳定运行。
