主从数据一致篇

MySQL是怎么保证数据不丢

只要redo log和binlog保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复。

binlog的写入机制

binlog写入分两步：

  1. 先把binlog从binlog cache中写到磁盘上的binlog文件；
  2. 调用fsync持久化。

一个事务的binlog是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。

  • 图中的write，指的就是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快。
  • 图中的fsync，才是将数据持久化到磁盘的操作。一般情况下，我们认为fsync才占磁盘的IOPS。

write 和fsync的时机，是由参数sync_binlog控制的：

  1. sync_binlog=0的时候，表示每次提交事务都只write，不fsync；
  2. sync_binlog=1的时候，表示每次提交事务都会执行fsync；
  3. sync_binlog=N(N>1)的时候，表示每次提交事务都write，但累积N个事务后才fsync。

在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成0，比较常见的是将其设置为100~1000中的某个数值。

设置为N风险是：如果主机发生异常重启，会丢失最近N个事务的binlog日志。

redo log的写入机制

MySQL是怎么保证主备一致的

MySQL是怎么保证高可用的

备库为什么会延迟好几个小时

主库出问题了，从库怎么办

读写分离有哪些坑