MySQL 主从，5 分钟带你掌握

我记得有一次，我在一家创业公司面试数据库工程师，面试官问我：“你有没有实际操作过MySQL的主从复制？能详细讲讲主从延迟的原因和解决方法吗？”我那时候正好负责一个电商网站的后端数据库，所以对这个话题比较熟悉。

我回答道：“当然有，我之前在项目中用到了一主多从的模式。
主从延迟的原因主要是由于从库的I/O性能不如主库，或者从库的SQL线程处理能力有限，导致从库落后于主库。
解决方法呢，一方面可以提升从库的硬件性能，另一方面可以优化从库的配置，比如调整缓冲池大小、减少日志文件数量等。
”
面试官听了之后，又问：“那如果从库的硬件性能已经足够好了，但延迟还是存在，你会怎么处理？”我稍微一愣，然后回答：“如果是这种情况，我可能会考虑调整主库的写入策略，比如增加写入缓冲，减少单条SQL的执行时间，从而降低主从延迟。
”
面试官满意地点了点头，说：“很好，你对这个问题的理解很到位。
”后来，我顺利通过了面试。
不过，我心里也在想，如果再遇到类似的问题，我可能会更详细地介绍一些具体的优化技巧，比如使用GTID来确保主从同步的一致性，或者利用性能分析工具来定位延迟的具体原因。
等等，我还突然想到，主从复制中，如果出现数据不一致的情况，是不是还得考虑时区设置的问题呢？毕竟，不同地区的服务器可能会因为时区差异而导致数据同步出现问题。

如何区分mysql主从复制、异步复制、半同步复制和gtid

哈，你这总结写得挺全面啊，把MySQL复制那些花样都捋清楚了。
不过说实话，直接念下来有点像看说明书，咱们换个方式聊聊？
记得去年我在上海一家公司搞项目，他们那个MySQL集群就出了点幺蛾子。
主库突然挂了，数据没同步过去，结果从库也跟着受影响，整个业务差点瘫痪。
当时运维小哥急得满头大汗，最后还是靠切换到从库救了场。
这事儿之后，我对MySQL复制才有了真切的体会。

要说复制吧，最基础的还是主从复制。
主库负责写，从库负责读。
这样好处是明显的：一是从库可以做备份，主库坏了还能接着用；二是可以把读操作分散到从库上，减轻主库压力。
但要注意啊，默认的异步复制模式，数据同步是有延迟的。
比如你主库删了条记录，可能要过几分钟甚至更久才反映到从库上。
这要是做金融系统，那可不行，钱没了谁负责？
后来MySQL出了全同步复制，听起来挺牛掰，主库写数据必须等所有从库都同步完才行。
这样确实实时性高，数据强一致，但性能是真的受影响。
我试过在一个测试环境跑全同步复制，感觉主库写个简单的插入语句都得等半天，根本没法用。
所以现在主流的还是半同步，就是等一个从库同步了就行，折中一下，大部分场景下都够用。

再来说说GTID，这个确实方便多了。
以前搞复制，最烦的是什么？是记那些binlog文件名和position啊。
搞错了就同步不了，或者同步不全。
GTID直接用一个全局ID标识每个事务，主库发给从库，从库收着，一目了然。
记得有一次我调参，忘了改GTID同步配置，结果从库一直卡在那儿等主库发数据，急死个人。
现在有了GTID，至少找问题方便多了。

不过啊，GTID也不是万能的。
你还得注意GTID状态同步，就是主库要把自己的GTID信息发给从库。
如果这个过程中断了，从库可能就不知道该同步到哪了。
我见过一个案例，就是网络波动，导致从库重启后GTID没同步好，结果数据丢了块。
所以这个也得定期检查。

反正你搞MySQL复制，得根据自己业务需求来选。
要是对实时性要求高，就用全同步；要是对性能要求高，就用半同步或者异步。
GTID是好东西，但别把它当万能药。
搞懂了这些，至少能避免不少坑。
不过说到底，具体怎么用，还得你自己多实践，多看看实际案例。

看完这篇还不懂 MySQL 主从复制，可以回家躺平了

MySQL主从复制这东西啊，说实话挺重要的。
你想想，就一台服务器写读都扛着，肯定不行啊。
宕了数据还丢了，谁受得了。

主从复制就是让一台主服务器干写活的活儿，另一台或几台从服务器干读活的活儿。
这样主服务器压力小了，读也快了。

复制形式有几种啊：
一主一从：简单，够用。
我之前那个小项目就是这种。

一主多从：主服务器写，多个从服务器读。
并发高的时候用得上。

多主一从：多个主服务器都写，数据传到一个从服务器。
这个比较少见，搞复杂了。

双主复制：俩主互为从，同步数据。
这个用的人少。

级联复制：从接从，绕一圈。
主要是为了减轻主压力。

原理很简单，主服务器有个二进制日志（binlog），记录所有改动的操作。
从服务器跑个I/O线程去主服务器拉binlog，然后SQL线程把binlog转成操作执行。
这样数据就同步了。

复制过程分几步： 1 . 从服务器开两个线程，I/O线程和SQL线程。
2 . I/O线程去主服务器要binlog，写到本地叫relaylog的文件里。
3 . 主服务器有个logdump线程，给I/O线程传binlog。
4 . SQL线程读relaylog，转成操作，执行。

复制类型有：
异步复制：主干完事就回客户端，不管从服务器。
快，但数据可能丢。

同步复制：主等所有从都复制完才回客户端。
慢，但数据不丢。

半同步复制：主等至少一个从收到binlog才回客户端。
安全，有延迟。

延迟复制：人为定个延迟时间。
用的人不多。

复制方式分三种：
语句复制：记录SQL语句。
简单，但有时不够精确。

行数据复制：记录每行改动。
精确，但压力大。

混合复制：默认用语句复制，不行就转行数据复制。

配置要点：
server_id：每个服务器得有唯一ID，不然自己复制自己了。

binlog_format：设为STATEMENT、ROW或MIXED。

sync_binlog：多少次事务提交刷一次磁盘。
设大点安全，设小点快。

innodb_flush_logs_at_trx_commit：事务提交后日志刷盘频率。
设高安全，设低快。

skip_slave_start：从服务器坏了别自动启动复制，等修复。

log_slave_update：把从服务器同步的事件也存起来。

expire_logs_days：日志过期时间，别占太多盘。

问题有延迟和数据丢失：
延迟：主服务器写多线程，从服务器读单线程，跟不上。
解决方法：优化网络、加硬件、用内存操作、并行复制。

数据丢失：主服务器坏了数据没了。
解决方法：用半同步复制。

注意事项：
复制得监控，出错了或延迟了系统会受影响。

复制有问题是肯定的，按需加增强功能。

好处：
数据安全：做了冗余，不会一台服务器挂了就丢数据。

性能提升：一主多从，读快了。

扩展性好：流量大了加从服务器，不影响用。

负载均衡：分担主服务器任务。

应用场景：
横向扩展：把负载分到从服务器上。

数据安全：从服务器备份数据。

数据分析：从服务器做分析，不拖慢主服务器。

远距离数据分布：远程备份数据。

拆分访问：不同业务用不同从服务器。

就这样吧。

整理归纳五大常见的MySQL高可用方案

选MySQL高可用方案，先看需求： 1 . 主从/主主半同步复制：简单，成本低，但数据一致可能有问题。
2 . 半同步复制优化：数据一致性强，但内核改不了，问题还在。
3 . 多节点集群：降低故障，但资源大，排查难。
4 . 共享存储：强一致，成本低，但SAN贵，DRBD影响性能。
5 . 分布式协议：强一致，无单点，但配置复杂，节点多。

挑一个吧，看你对一致性和成本怎么权衡。