上一篇讲了mysql主从延迟的坑。关于这个陷阱，我想多说几句。我以前见过这样的例子，我知道这是不可能的。写完马上更新，实际开发的时候还是没有注意到这一点。每个人都知道真相，但他们仍然会犯错误。只有亲身经历过错误，才能真正把握真相。在经历了一次mysql主从延迟之后，我开始思考，什么是主从复制？它是如何实现的？它的原理是什么？于是开始查阅资料和文章，现在把自己理解的总结到这里，加深印象。为什么要做主从复制？1、在复杂的业务系统中，有一种情况是SQL语句需要锁表，导致读服务暂时无法使用，对业务的运行会造成很大的影响。采用主从复制，让主库负责写，从库负责读。这样即使主库被锁，也可以通过读取从库来保证业务的正常运行。2、做数据热备份3、扩展架构。业务量越来越大，I/O访问频率过高，单机无法满足。这时使用多库存储来降低磁盘I/O访问频率，提高单机I/O性能。mysql主从复制的原理是什么？binlog：二进制日志，更新事件日志的二进制文件保存在主库中。主从复制的基础是主库将数据库的所有变化记录到binlog中。Binlog是数据库中的一个文件，它保存了配置中过期时间内所有修改过的数据库结构或内容。如果过期时间是10d，那么就是最近10d的数据库修改记录。MySQL主从复制是一个异步复制过程。主库向从库发送更新事件，从库中读取更新记录，并执行更新记录，使从库的内容与主库保持一致。在主库中，只要有update事件，就会依次写入binlog，这是从库连接到主库时从主库拉取复制的数据源。binlog输出线程。每当从库连接到主库时，主库都会创建一个线程，将binlog内容发送给从库。对于每一个即将发送到从库的sql事件，binlog输出线程都会对其进行锁定。一旦事件被线程读取到，即使事件已经完全发送到从库，锁也会被释放。在从库中，当复制开始时，从库会创建两个线程进行处理：从库I/O线程。从库执行STARTSLAVE语句时，从库创建一个I/O线程，连接主库，请求主库将binlog中的更新记录发送给从库。从库I/O线程读取主库binlog输出线程发送的更新，并将这些更新复制到本地文件，包括relaylog文件。来自库的SQL线程。从库中创建一个SQL线程。该线程从库I/O线程读取并执行写入中继日志的更新事件。可以知道每个主从复制连接有3个线程。主库有多个从库，为每个连接到主库的从库创建一个binlog输出线程，每个从库都有自己的I/O线程和SQL线程。通过创建两个独立的从库线程，在拷贝时从库读写分离。因此，即使执行线程运行缓慢，读取更新语句的线程也不会变慢。比如从库有一段时间没有运行，这里启动时，虽然它的SQL线程执行的慢，但是它的I/O线程可以很快从主库读取所有的binlog内容。这样，即使在SQL线程执行完所有读取语句之前从库停止运行，I/O线程至少已经完整读取了所有内容，并安全地备份到从库的本地relaylog中，准备下次启动从库时执行该语句。查看主从复制状态当主从复制进行时，如果想查看从库中两个线程的运行状态，可以在从库中执行“showslavestatusG”语句。以下字段可以给你你想要的信息：Master_Log_File—最后从主库复制的binlog文件Read_Master_Log_Pos—主库的binlog文件被复制到从库的中继日志中的位置Relay_Master_Log_File—中继日志文件currentlybeingprocessedbytheSQLthreadExec_Master_Log_Pos--当前正在执行的binlog文件整个主从复制过程可以通过下图理解：第一步：主库db的更新事件（update、insert、delete）是写入binlog第二步：从库发起连接，连接到主库第三步：此时主库创建一个binlogdump线程，将binlog的内容发送给从库。第四步：从库启动后，创建一个I/O线程，读取主库传递过来的binlog内容，写入中继日志第五步：也会创建一个SQL线程，从中继读取内容log，从Exec_Master_Log_Pos位置执行读取更新事件，将更新内容写入slave的db注意：上面的解释是为了说明每一步都做了什么，整个mysql主从复制是异步的，不执行按照上面的步骤。其他主从复制架构的搭建，可以参考网上更多的文档。文字有限，就不多做介绍了。作为一个开发者，这些基本的mysql知识还是需要学习很多的。参考资料什么是MySQL复制及其工作原理？复制实施细节
