MySQL 数据库支持单向、双向、链式级联、环装等不同业务场景的复制。在复制过程中,一台服务器充当主服务器(Master),接收来自用户的内容更新,而一个或多个其他的服务器充当从服务器(Slave),接收来自主服务器 binlog 文件的日志内容,解析出 SQL 重新更新到从服务器,使得主从服务器数据达到一致。
应用场景
MySQL 主从复制集群功能使得 MySQL 数据库支持大规模高并发读写称为可能,同时有效地保护了物理服务器宕机场景的数据备份。
应用场景1:从服务器作为主服务器的实时数据备份
主从服务器架构的设置,可以大大加强 MySQL 数据库架构的健壮性。例如:当主服务器出现问题时,我们可以人工或设置自动切换到从服务器继续提供服务,此时从服务器的数据和宕机时的主数据库几乎是一致的。
这类似 NFS 存储数据通过 inotify + rsync 同步到备份的 NFS 服务器,只不过 MySQL 的复制方案是其自带的工具。
利用 MySQL 的复制功能做备份时,在硬件故障、软件故障的场景下,该数据备份是有效的,但对于人为的执行 drop、delete等语句删除数据的情况下,从服务器数据库的备份功能就没有用了,因为从服务器也会执行删除等语句。
应用场景2:主从服务器实时读写分离,从服务器实现负载均衡
主从服务器架构可通过程序(PHP、Java等)或代理软件(mysql-proxy、Amoeba)实现对用户(客户端)的请求读写分离,即让从服务器仅仅处理用户的 select 查询请求,降低用户查询响应时间及读写同时在主服务器上带来的访问压力。对于更新的数据(例如:update、insert、delete语句)仍然交给主服务器处理,确保主服务器和从服务器保持实时同步。
应用场景3:把多个从服务器根据业务重要性进行拆分访问
可以把几个不同的从服务器,根据公司的业务进行拆分。例如:有为外部用户提供查询服务的从服务器,有内部DBA用来数据备份的从服务器,还有为公司内部人员提供访问的后台、脚本、日志分析及供开发人员查询使用的从服务器。这样拆分除了减轻主服务器的压力外,还可以使数据库对外部用户浏览、内部用户业务处理及DBA人员的备份等互不影响。
优点与解决的问题
主从复制的优点
- 如果主库出现问题,可以快速切换到从库提供服务
- 可以在从库执行查询操作,降低主库的访问压力
- 可以在从库进行备份,以免备份期间影响主库的服务
主从复制解决的问题
- 数据分布(Data distribution)
- 负载平衡(Load balancing)
- 数据备份(Backups),保证数据安全
- 高可用性和容错性(High availability and failover)
- 实现读写分离,缓解数据库压力
注意:由于 MySQL 实现的异步复制,所以主库和从库数据之间存在一定的差异,在从库执行查询操作需要考虑这些数据的差异,一般只有更新不频繁和对实时性要求不高的数据可以通过从库查询,实时要求高的仍要从主库查询。