怎么理解MarriDB/MySQL的binlog group commit技术
这篇文章主要介绍“怎么理解MarriDB/MySQL的binlog group commit技术”,在日常操作中,相信很多人在怎么理解MarriDB/MySQL的binlog group commit技术问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”怎么理解MarriDB/MySQL的binlog group commit技术”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
我们知道,操作系统使用页面缓存机制来填补内存访问速度和磁盘访问速度之间的差距。通常情况下,对磁盘文件的写都会先写入到页面缓存中,
然后由操作系统来决定何时将修改过的脏页刷新到磁盘上。如果想确保修改已经持久写到了磁盘,必须调用fsync或fdatasync。在关系数据库中,
为了满足ACID中的持久化属性,也就是说事务提交并成功返回给客户端之后,必须保证该事务的所有修改不能丢。无论是在数据库程序崩溃的情况下,
还是在数据库所在的服务器发生宕机或断电的情况下,都必须保证数据不能丢,这就要求数据库在事务提交过程中调用fsync或fdatasync将数据持久化
到磁盘。fsync是一个昂贵的系统调用,对于普通的磁盘,每秒只能完成几百次的fsync操作,很明显,fsync将会限制每秒提交的事务数,成为关系
数据库的瓶颈。
对于MarriDB/MySQL来说,这种情况变得更加糟糕。在开启binlog的情况下,为了保证主库和从库之间数据的一致性,MarriDB/MySQL使用了事务的
两阶段提交协议。在这种情况下,为了满足数据的持久化需求,一个事务的提交最多会导致3次fsync操作。
为了提高MarriDB/MySQL在开启binlog的情况下单位时间内的事务提交数,就必须减少每个事务提交过程中导致的fsync的调用次数。MarriDB从5.3版本开始,
引入了binlog group commit技术来解决这个问题。MySQL从5.6版本开始也加入了binlog group commit技术。
binlog group commit的基本思想是多个并发提交的事务之间共用一次fsync操作来实现事务对binlog修改的持久化。
到此,关于“怎么理解MarriDB/MySQL的binlog group commit技术”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341