标签：主从复制

共 8 篇相关文章

IT 累计浏览 1,074

SLAVE为什么一直不动了

这篇讲的是MySQL复制延迟中一种“假死”现象的排查。作者从一次延迟超大（超过3小时）但SQL线程却“无事可做”的报警出发，展示了如何一步步定位。初步检查显示，主从IO和SQL线程都在正常运行，但从`show slave status`看，Relay Log的执行位点（Exec_Master_Log_Pos）却纹丝不动。关键的突破点在于检查主库的Binlog内容。作者发现，从卡住的位点（294959）开始，整个事务是一个巨大的`DELETE`操作——它来自Bacula备份系统的自动清理任务，一次性删除过期数据，事务提交耗时超过2000秒，产生的Binlog数据量接近3.9G，几乎填满了整个Binlog文件。根因就在于此：这个超大事务在主库执行完毕并生成Binlog后，从库需要将其“重放”一遍。由于事务过于庞大，应用这个DELETE操作本身就需要极长时间，导致复制位点看起来一直“卡住”。文章不仅点明了直接原因，还提醒了这类大事务的潜在危害：除了延迟，还可能长时间锁住数据行，引发连锁的锁等待。对于通用应用，作者给出的解决方案很务实：在代码层面控制事务粒度，比如每删除几千条记录就提交一次，避免生成这种“一镜到底”的巨型事务。这比直接修改第三方软件的源码更可行。

IT 累计浏览 6,269

MySQL 5.6 测试之 Replication(主从复制)

在深入测试了MySQL 5.6的性能之后，作者将目光转向了它的Replication（主从复制）功能，探究其在5.6版本中的表现是否同样令人兴奋。这篇测评的核心是将MySQL 5.6的主从复制与更早的版本（如5.5）进行对比。作者重点测试了5.6引入的关键改进，例如真正的多线程复制（基于组提交）、基于GTID的复制拓扑管理，以及崩溃安全的特性。文章会详细拆解这些新机制如何运作，并通过实际的测试数据来展示它们带来的延迟降低和运维便利性提升。通过对比测试，文章旨在回答一个关键问题：MySQL 5.6的主从复制在吞吐量、延迟和可管理性上，相比前代有了多大程度的飞跃？测试结果将揭示这些改进在实际负载下的表现，帮助读者判断是否值得升级。

IT 累计浏览 3,260

MySQL闪回方案讨论及实现

这篇讲的是如何为MySQL数据库实现类似Oracle的“闪回”功能，以应对主从复制环境下无法阻止的误操作，比如误删表或全表更新。作者从一个实际痛点出发：即使搭建了主从，实时备份也无法恢复逻辑误操作。文章核心方案是利用row-based格式的binlog来实现闪回，因为只有在这种格式下，binlog才会记录数据变更前后的完整行信息。对于常规的增删改操作，思路很巧妙：通过反转binlog事件的类型和内容——把INSERT事件变成DELETE，把DELETE事件变成INSERT，再把UPDATE事件中的新旧行数据对调——就能生成可以“逆操作”的闪回日志。而对于ALTER TABLE、DROP TABLE这类DDL操作，仅靠binlog的语句记录则无能为力。文章提出的补充方案是，在执行这类可能删除数据的DDL前，先将原表数据备份到一个历史表中，并自定义一种FLASHBACK_EVENT事件来记录恢复步骤。最终，通过修改mysqlbinlog工具并添加这种事件类型，就能按表、按时间点反向执行这些操作，安全地恢复数据。方案最大的优点是，这些修改不会影响原生的binlog工具使用，也不会对线上正常操作的性能带来额外负担。

IT 累计浏览 2,778

在 Percona 中配置主从的 MY SQL

这篇讲的是如何利用Percona的innobackupex工具，为Percona MySQL配置高效、可靠的主从复制。文章从实际生产环境的需求出发，指出标准MySQL的主从配置在备份恢复环节可能面临效率问题。作者推荐使用Percona分支及其标志性的xtrabackup（innobackupex）工具来解决。其核心优势在于能生成具有强一致性的备份，并自动切分、输出日志文件及精确位置，这为从库（slave）的初始化提供了极大便利，省去了很多手动处理二进制日志的麻烦。文中特别强调了innobackupex的两个关键特点：它能同时支持MyISAM和InnoDB引擎，确保了备份的完整性；同时锁表时间极短，非常适合生产环境的高可用要求。作者也提到，虽然Percona的某些恢复操作与标准MySQL有差异，主要依赖自身工具链，但这套方案同样适用于标准的MySQL实例。总结来说，这篇文章为DBA和后端开发者提供了一个在Percona（或标准MySQL）上构建主从架构的实战方案，其核心建议是利用专业工具链来保障数据一致性、简化运维流程并提升整体系统的稳定性。

IT 累计浏览 4,401

MySQL复制的概述、安装、故障、技巧、工具

这篇文章以MySQL复制的复杂性为核心，作者首先将其与MongoDB和Redis等NoSQL数据库的复制机制进行对比。由于关系型数据库对数据一致性和事务完整性的严格要求，MySQL复制在实现上确实比NoSQL的异步或最终一致性模型更显繁复，但这也使其在传统业务场景中更具可靠性。文章系统性地梳理了MySQL复制的各个方面：从复制原理的基本概述，到不同版本下的安装配置指南，再到主从同步延迟、数据丢失等常见故障的排查与解决。作者还分享了复制过滤、半同步复制等实用技巧，并推荐了如MySQL Workbench、Orchestrator等工具来简化运维管理。通过对比和案例，文章帮助读者理解在不同应用场景中如何选择合适的复制策略，例如在高并发OLTP系统中如何平衡性能与一致性。对于需要部署或维护MySQL复制环境的开发者与DBA来说，这篇文章提供了从入门到进阶的实践路线，让复杂的复制机制变得清晰可操作。

IT 累计浏览 2,228

数据库使用的规划

这篇讲的是作者在制定2010年技术规划时，对数据库部分所做的梳理与部署。在那个时期，企业应用对数据存储和查询的需求日益增长，数据库选型与架构设计直接关系到系统的稳定性和扩展效率。作者从实际业务场景出发，系统回顾了当时主流数据库技术的特点与适用边界。规划的核心在于如何匹配不同的业务模块与数据特征。例如，对于事务性要求高的核心交易系统，作者倾向于采用成熟的商用关系型数据库以保证强一致性；而对于日志分析、用户行为等非结构化数据场景，则开始评估更灵活的存储方案。同时，规划也考虑了运维成本、团队技术栈延续性以及未来数据量增长带来的扩容压力。文章并未停留在理论对比，而是将技术选型与具体的业务发展阶段结合，提出了分阶段的落地路径。这种从需求倒推技术方案的思路，为后续几年数据库基础设施的平稳演进提供了清晰的路线图，也体现了技术规划中前瞻性与务实性的平衡。

IT 累计浏览 2,799

mysql同步出错问题

这是一篇典型的故障排查类文章，核心场景是处理 MySQL 主从同步出现的报错。作者从一个最常见的排查动作“SHOW SLAVE STATUS”入手，展示了如何从这条命令的输出中定位问题。文章没有停留在展示错误代码，而是进一步剖析了几个典型的错误原因，例如网络抖动导致的连接断开、主库大事务引起的延迟、甚至由于服务器时间不同步造成的校验问题。更重要的是，它针对每种情况给出了具体的检查命令和解决步骤，比如如何查看 `Last_IO_Error`，如何调整 `slave_net_timeout` 参数，以及如何处理误操作的数据修复。这篇分享的价值在于，它把排查同步问题的过程结构化了，不是单纯罗列报错，而是提供了一套从发现问题到分析根因再到操作解决的完整排查思路。对于经常和 MySQL 主从架构打交道的工程师来说，这种结合具体输出的实战讲解，比干巴巴的理论文档更直接有用。

IT 累计浏览 3,953

mysql主从热备配置(含innodb)终极版

这篇讲的是如何为MySQL搭建一套稳定可靠的主从热备环境，尤其是在使用了InnoDB存储引擎的场景下。文章开篇就点明了主从热备存在两种核心配置思路：一种是明确指定要同步某些特定的库，另一种则是反过来，指定忽略某些库的同步。作者明确建议采用后一种“白名单忽略”的策略。作者深入阐述了这么选择的根本原因。对于大多数生产环境，业务库是动态变化的，采用“忽略某些库”的策略（例如忽略测试库或临时分析库）具有更好的维护性和容错性。这样配置后，新建的库默认就会被同步，避免了因疏忽导致新库未及时加入同步的风险，让整个主从架构更加省心和稳固。文章还详细拆解了具体的配置步骤，特别是针对InnoDB引擎的参数调优，确保数据在复制过程中的完整性和高性能。整个方案从原理到实践，最终指向一个明确结论：采用“忽略列表”模式配合恰当的InnoDB配置，是构建高可用MySQL架构中一个更优雅、更不易出错的选择。