MySQL8.0 redo log优化概述和线程模型简介
发布时间:2022-01-18 13:59:40 所属栏目:MySql教程 来源:互联网
导读:本篇内容介绍了MySQL8.0 redo log优化概述和线程模型介绍的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成! 1 MySQL redo_log简要回顾 在MySQL 5.7中写
本篇内容介绍了“MySQL8.0 redo log优化概述和线程模型介绍”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成! 1 MySQL redo_log简要回顾 在MySQL 5.7中写性能将受限于redo_log的同步操作,特别是在多cpu,存储设备很快的情况下,MySQL 5.7 redo_log的设计无法有效利用存储设备性能,因此需要重新设计。MySQL 5.7瓶颈在于mtr将在把log写到log buffer时加log_sys_t::mutex锁,之后该mtr把dirty page加入flush list中时,为了保证全局有序,会加 log_sys_t::flush_order_mutex锁。如果其他用户线程的mtr要把log写到log buffer,需要等待log_sys_t::mutex,同时为了保证全局lsn有序,其他用户线程的mtr即使要往其他flush list中加数据也需要等待log_sys_t::flush_order_mutex锁,这两把锁是MySQL 5.7中redo_log的主要性能瓶颈。 2 redo log优化概述 log_writer:负责将日志从log buffer写入磁盘,并推进write_lsn(原子数据) log_flusher:负责fsync,并推进flushed_to_disk_lsn(原子数据) log_write_notifier:监听write_lsn,唤醒等待log落盘的用户线程(根据flush_log_at_trx_commit设置,用户commit操作会等待write_lsn推进) log_flush_notifier:监听flushed_to_disk_lsn,唤醒等待log fsync的用户线程。 log_closer:1、在正常退出时清理所有redo_log相关lsnlog buffer相关数据结构;2、定期清理recent_closer的过老数据(recent_closer所用之后详述) log_checkpointer:定期做checkpoint检查,根据flush list刷dirty page情况推进check point,释放log buffer等 1 线程同步数据结构 异步线程之间通过2种数据结构进行数据同步:原子读写(atomic )和Link_buf。原子读写是c++11针对多核cpu的一个新特性,在不加锁的情况下,对一个64位数据的原子读写。 Link_buf是MySQL新实现的数据结构,逻辑上是循环数组,数组下标表示start lsn,数据内容是lsn长度,数据类型为原子类型,如果数据内容(lsn 长度)为0表示这个slot为空 。每个通过合理的std::atomic_thread_fence(std::memory_order_release) / std::atomic_thread_fence(std::memory_order_acquire)操作,保证对里面不同slot的lsn读写的无锁并发。 (编辑:台州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |