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

说到MySQL主从复制，这是一个老话题了。
我已经熟悉这项技术很多年了。
每当我和人聊天时，我总是能聊很多。

说实话，刚开始做数据库维护的时候，我对主从复制是持怀疑态度的。
当时我们公司有一个很大的项目，数据库压力很大。
这显然在单机上不行，所以我们开始思考如何实现主从复制。
当时我们采用的是最简单的“一主一从”模型，即一台主服务器负责写操作，一台从服务器负责读操作，所以压力很低。

有趣的是，当时在论坛上看到一个案例，说是一家公司采用了主多从模式。
导致从服务器太多，管理起来很头疼。
这就像开车一样。
一辆车可以顺利行驶，但车太多就会变得混乱。

从原理上来说，其实很简单。
主服务器将所有操作记录在二进制日志（binlog）中。
从服务器通过I/O线程和SQL线程读取这些日志，然后执行相同的操作，从而实现数据同步。

配置也很特别。
例如server_id，这是每个服务器的唯一标识符，用于防止同步循环。
还有binlog_format，要根据实际需要来设置，是记录语句还是行数据，直接影响复制的效率和数据的一致性。

当然，问题是不可避免的。
延迟、数据丢失，这些都是令人头疼的问题。
记得有一次，我们公司的主从复制因为网络问题出现了延迟。
当时很担心，不过最终通过优化网络配置解决了。

现在回想起来，主从复制虽然是个好东西，但是也不能盲目地去做。
应该根据实际情况，比如业务需求、硬件配置、网络环境等。
就像开车一样，你必须先了解路况，然后再决定走哪条路。

总的来说，MySQL主从复制是一项非常实用的技术，特别是对于高并发、大数据量的应用场景。
不过，在使用时也应该注意一些细节。
毕竟，技术并不全是好或坏。
最主要的是如何使用它。

mysql 自动同步数据到另外一台服务器上

上周，我朋友的公司完成了MySQL数据库迁移。
他们主要采用了三种解决方案：主从复制、双主架构、数据库集群。

首先是主从复制。
它们在主服务器上启用二进制日志并设置唯一的 server_id。
在从服务器上配置主节点的IP和端口，并设置复制账户权限。
在监控复制状态时，发现Slave_IO_Running和Slave_SQL_Running均为yes，说明数据同步良好。

然后是双主架构。
他在两台服务器上都开启了binlog，设置了唯一的server_id，同时也解决了自动增加ID的偏移问题。
它们还启用了半同步复制，以确保至少有一个从节点确认写入，这不仅保证了数据可靠性，还减少了延迟。

最后是数据库集群。
他们使用GaleraCluster，部署集群管理节点，配置节点间通信端口，并启用自动故障转移。

他们还使用了第三方工具和云服务，例如TungstenReplicator和腾讯云TencentDB for MySQL。
云服务用户可以直接使用云数据库MySQL或TBase通过控制台配置同步规则。

在复制机制选择上，根据业务需求区分了同步复制、异步复制、半同步复制。
选择了。

在监控和排查方面，他们定期检查主从节点的状态和复制延迟，并处理网络中断和节点宕机等问题。

但是，我刚刚想到的另一件事是他们可能还需要考虑数据备份和恢复策略。
这取决于你。

MySQL主从复制虽好，能完美解决数据库单点问题吗？

是的，主从复制无法防止单点崩溃。
就是数据同步。
如果主服务器坏了，则需要手动更换从服务器，但这会耽误事情。

手动更改所有者并停止业务是不可能的。
数据同步不实时，如果master挂掉，可能会导致数据丢失。

单从库无法工作，两个主库都宕机了，一切都没用了。
再多的后续行动也无法挽救局面，不计划也是徒劳。

解决招儿？ 使用自动切换工具，例如MHA，速度更快。

半同步复制比较好，但是开关还是坏了。

集群比较可靠，Galera或者InnoDBCluster，读写都是不间断的。

总结就是主从复制是一种备份。
如果你真的想要高可用性，你需要添加其他技术。
一般场景使用MHA，高要求使用集群。
你自己看看吧。