乐趣区

关于java:高级程序员必知必会一文详解MySQL主从同步原理推荐收藏

1. MySQL 主从同步实现形式

MySQL 主从同步是基于 Bin Log 实现的,而 Bin Log 记录的是原始 SQL 语句。

Bin Log共有三种日志格局,能够 binlog_format 配置参数指定。

参数值 含意
Statement 记录原始 SQL 语句,会导致更新工夫与原库不统一。<br/> 比方 update_time=now()
Row 记录每行数据的变动,保障了数据与原库统一,毛病是数据量较大。
Mixed Statement 和 Row 的混合模式,默认采纳 Statement 模式,波及日期、函数相干的时候采纳 Row 模式,既缩小了数据量,又保障了数据一致性。

常见的主从同步架构有一主多从、双主多从。

2. MySQL 主从同步的作用

  1. 读写拆散,晋升数据库性能
  2. 容灾复原,主服务器不可用时,从服务器提供服务,进步可用性
  3. 冗余备份,主服务器数据损坏失落,从服务器保留备份

一主多从架构:

个别是主库负责所有读写申请,而从库只负责容灾复原和冗余备份。

如果做了读写拆散的话,主库负责写申请,从库负责读申请,能够晋升数据库性能。

双主多从架构:

个别是主库 1 负责所有读写申请,主库 2 不对外提供服务,只用来容灾复原。

相比一主多从架构,双主多从架构能够缩小宕机工夫,更快复原数据库可用状态。

3. 被动同步的原理

  1. 当主库数据产生变更时,写入本地 Bin Log 文件
  2. 从库 IO 线程发动 dump 主库 Bin Log 文件的申请
  3. 主库 IO 线程推送 Bin Log 文件到从库中
  4. 从库 IO 线程把 Bin Log 内容写入本地的 Relay Log 文件中
  5. 从库 SQL 线程读取 Relay Log 文件内容
  6. 从库 SQL 线程从新执行一遍 SQL 语句

4. 主从同步提早问题

主从同步最常遇到的问题就是主从同步提早,能够通过在从库上执行 show slave status 命令查看延迟时间,Seconds_Behind_Master示意提早的秒数。

主从同步提早的起因有哪些?

  1. 从库机器性能较差

    主库负责所有读写申请,从库只用来备份,会用性能较差的机器,执行工夫天然较慢。

  2. 从库压力更大

    读写拆散后,主库负责写申请,从库负责读申请。

    互联网利用个别读申请更多,所以从库读压力更大,占用更多 CPU 资源。

  3. 网络提早

    当主库的 Bin Log 文件往从库上发送时,可能产生网络提早,也会导致从库数据跟不上。

  4. 主库有大事务

    当主库上有个大事务须要执行 5 分钟,把 Bin Log 文件发送到从库,从库至多也须要执行 5 分钟,所以这时候从库就呈现了 5 分钟的提早。

主从同步提早的解决方案?

  1. 从库机器性能较差

    把从库换成跟主库等同规格的机器。

  2. 从库压力更大

    多搞几台从库,分担读申请压力。

  3. 网络提早

    分割运维或者云服务提供商解决。

  4. 主库有大事务

    把大事务宰割成小事务执行,大事务岂但会产生从库提早,还可能产生死锁,升高数据库并发性能,所以尽量少用大事务。

5. 如何晋升主从同步性能

1. 从库开启多线程复制

就是在主从同步的最初两步应用多线程,批改配置 slave_parallel_workers=4,代表开启 4 个复制线程。

2. 批改同步模式,改为异步

主从同步共有三种复制形式:

  1. 全同步复制

    当主库执行完一个事务,并且所有从库都执行完该事务后,才给客户端返回胜利。

  2. 半同步复制

    至多有一个从库执行实现后,就给客户端返回胜利。

  3. 异步复制

    主库执行完后,立刻返回胜利,不关怀从库是否执行实现。

如果对数据安全性要求没那么高,能够把同步模式改成半同步复制或者异步复制。

3. 批改从库 Bin Log 配置

批改 sync_binlog 配置:

sync_binlog=0,示意写 binlog 不立刻刷新磁盘,由零碎决定什么时候刷新磁盘。

sync_binlog=1,每次写 binlog 都刷新磁盘,安全性高,性能差。

sync_binlog=N,写 N 次 binlog 才刷新磁盘。

从库对数据安全性要求没那么高,能够设置 sync_binlog=0。

批改 innodb_flush_log_at_trx_commit 配置:

innodb_flush_log_at_trx_commit=0,每隔一秒钟,把事务日志刷新到磁盘。

innodb_flush_log_at_trx_commit=1,每次事务都刷新到磁盘。

innodb_flush_log_at_trx_commit=2,每次事务都不被动刷新磁盘,由零碎决定什么时候刷新磁盘。

从库对数据安全性要求没那么高,能够设置 innodb_flush_log_at_trx_commit=2。

知识点总结:

文章继续更新,能够微信搜一搜「一灯架构」第一工夫浏览更多技术干货。

退出移动版