mysql的高可用性

前言

mysql的高可用性

mysql的两个日志系统 binglog和redo-log的

mysql是如何保证主从一致的

msyql是这么保证高可用的？

说到高可用性其实就是通过binlog和redo-log两个日志系统和一主多从来实现的。

binlog的写入机制

binlog写入的时候有一个自增id，比如要写入一个新的事务，那么就会在这个id上加上这个事务的长度。由于binlog的写入过程是需要保证一致的，因此无论事务多大都要一次写入。

如果在chche中写入不了就会先写入到磁盘中暂时存储。然后提交到文件系统的page，然后在sync到磁盘中，

binlog中有一个同步的参数 sync-binlog = 0时每次事务不会sync到磁盘

sync-binlog = 1 时每次都会写入到磁盘

sync-binlog = N时， N次事务之后会一起写入磁盘

redo-log的写入机制

redo-log的写入机制是会先写入到redo-log的buffer中，然后写入到文件系统的page cache中然后再写入到磁盘

同理也有参数可以控制

innodb-fluse** = 0 时只保留在redo-log buffer中，

= 1 时每次都写入到磁盘

= 2 时只保留在文件系统的page cache

一般情况下都会设置成双1

那么你可以会问这样不就导致写磁盘的次数多了吗为什么还会提高效率

redo-log还有一个提交机制就是等到

1 如果buffer中的内存即将达到一半就会触发写入磁盘

2 如果有其它事务写入磁盘，会顺带把准备好的数据写入到磁盘

主要是使用了binlog，binlog是mysql高可用中非常重要的一环。

从库通过读取binlog，然后写入到从库中，保证了数据的一致性。

binlog的日记有三种格式

statement 这种格式会原封不动的记录sql文件，但是会有问题，比如delete from t where c >4 limit 1,在从库执行的时候可能会因为原则的索引不一样，导致排序之后的数据不一样，导致删除的数据不一致。
row会详细的记录每一行的结果，定位到具体的表具体的操作，以及操作哪一行。所以不会出现上面的问题，但是有一个缺点就是记录非常详细，会导致内存压力和性能压力，比如我要删除10w行数据，如果用sql记录就一行命令，但是如果使用row就会有不止是10w的binlog日志了。
mixed mixed是statement和row的混合，就是为了解决row的缺点，mysql会自己判断使用statement还是row来存储

循环写入问题：

A，B互为备库即 mm型。那么是否会出现A写入B之后，B又重新写入A呢？

不会，mysql是通过binlog中的server id来确定每条数据的唯一性的。

A生成的binlog文件的server id，如果是读的B的那么生成的server id还是原来的，这样A读完之后生成的binlog给B，B发现是自己的server id就不写入了

一般保证高可用的方式就是主从切换，一主多从等。

主备延迟：主备延迟是指，备库同步主库的延迟时间。

造成主备延迟的原因有

主从切换的过程是主库先变成可读状态，然后备库追上主库，之后备库变成可读写状态，

也可以不等同步完成就切换，但是会导致数据库不一致，如果binlog是row的情况下，会直接报错停止同步。不推荐

主库掉电可不可以直接切从库？

不可以，因为切从库会导致数据不一致，并且有些事务还没有返回，连接从库之后会以为没有成功，但是在主库已经执行成功了