关闭顶部展开顶部

MySQL 5.7增强版Semisync Replication性能优化_MySQL教程

编辑Tag赚U币
教程Tag:暂无Tag,欢迎添加,赚取U币!

推荐:MySQL Index Condition Pushdown(ICP)性能优化方法实例
这篇文章主要介绍了MySQL Index Condition Pushdown(ICP)性能优化方法实例,本文讲解了概念介绍、原理、实践案例、案例分析、ICP的使用限制等内容,需要的朋友可以参考下 一 概念介绍 Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用

   这篇文章主要介绍了MySQL 5.7增强版Semisync Replication性能优化,本文着重讲解支持发送binlog和接受ack的异步化、支持在事务commit前等待ACK两项内容,需要的朋友可以参考下

  一 前言

  前文 介绍了5.5/5.6 版本的MySQL semi sync 基础原理和配置,随着MySQL 5.7 的发布,新版本的MySQL修复了semi sync 的一些bug 并且增强了功能。

  支持发送binlog和接受ack的异步化;

  支持在事务commit前等待ACK;

  在server层判断备库是否要求半同步以减少Plugin锁冲突;

  解除binlog dump线程和lock_log的冲突等等。

  本文重点分析 第1,2个改进项,因为原来的模式的确会影响系统的tps,新的异步模式可以提高半同步模式下的系统事务处理能力。

  二 优化

  1、支持发送binlog和接受ack的异步化

  通过前面的介绍,我们知道Semisynchronous Replication模式下,app在主库上提交一个事务/event,MySQL将每个事务写入binary并且同步到到slave ,master会等待至少一个slave通知:slave 已经接收到传过来的events并写入relay log,才返回给回话层 写入成功,或者直到传送日志发生超时,系统自动将为异步复制模式。

  整体流程的逻辑图

MySQL 5.7增强版Semisync Replication性能优化

  5.5 版本semi sync 设计的缺点:

  从原理以及上图来看,旧版本的semi sync 受限于dump thread ,原因是dump thread 承担了两份不同且又十分频繁的任务:传送binlog 给slave ,还需要等待slave反馈信息,而且这两个任务是串行的,dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈在高并发业务场景下,这样的机制会影响数据库整体的TPS .

  为了解决上述问题,在5.7.4版本的semi sync 框架中,独立出一个 ack collector thread ,专门用于接收slave 的反馈信息。这样master 上有两个进程独立工作,可以同时发送binlog 到slave ,和接收slave的反馈。整体流程的逻辑图

MySQL 5.7增强版Semisync Replication性能优化

  大体的实现思路是:

  备库IO线程使用TCP协议和主库交互,读写socket可以同时进行,在开启主库semisync时,启动一个后台线程,使用select监听备库连接socket;

  dump线程不再等待备库ACK;在ack reciver线程等待ACK时,dump线程还能继续发送下一组group commit的binlog,进而提升TPS.

  2 支持在事务commit前等待ACK;

  新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。

  该参数有两个值:

  AFTER_SYNC (默认值):master 将每个事务写入binlog ,传递到slave,并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下,所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash,所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库,可以保障最小的数据损失。

  AFTER_COMMIT: master 将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log),然后在主库提交事务。master在提交事务后等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master将结果反馈给客户端。

  在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash,系统failover到slave,app将发现数据出现不一致,在master提交而slave 没有应用。

分享:MySQL order by性能优化方法实例
这篇文章主要介绍了MySQL order by性能优化方法实例,本文讲解了MySQL中order by的原理和优化order by的三种方法,需要的朋友可以参考下 前言 工作过程中,各种业务需求在访问数据库的时候要求有order by排序。有时候不必要的或者不合理的排序操作很可能导致数据库系统崩

来源:模板无忧//所属分类:MySQL教程/更新时间:2015-05-30
loading.. 评论加载中....
相关MySQL教程
闂佹眹鍩勯崹閬嶆偤閺囶澁缍栭柛鈩冪⊕閳锋帗銇勯弴妤€浜惧銈忕秶閹凤拷
濠电偛顕慨顓㈠磻閹炬枼妲堥柡鍌濇硶婢ф稒淇婇懠顒夆偓婵嬫煟閵忊晛鐏查柟鍑ゆ嫹
濠电姷顣介埀顒€鍟块埀顒勵棑缁辩偛顓兼径瀣閻庣懓瀚竟鍡欐崲娑斾線鏌i姀鈺佺伈闁瑰嚖鎷�
濠电姷顣介埀顒€鍟块埀顒勵棑缁辩偛顓兼径濠勵吋闂佽鍨庨崟顓фК闂佽閰eḿ褍螞濞戙垺鍋夐柨鐕傛嫹
闂備胶枪缁绘劙骞婃惔銊ョ劦妞ゆ帒鍊哥敮鍫曞箹鐎涙ḿ鐭掔€规洘绻堥弫鎾绘晸閿燂拷
闂備胶枪缁绘劙骞婃惔銊ョ劦妞ゆ巻鍋撻柛姘儑缁﹪鏁傞崜褏鐓撻柣搴岛閺呮繈鎯屽▎鎴犵=濞撴艾锕ョ€氾拷
闂備浇銆€閸嬫挻銇勯弽銊р槈闁伙富鍣i弻娑樷攽閹邦亞鑳虹紓浣靛妽濡炶棄顕i妸鈺婃晬婵炲棙鍨电粭锟犳⒑閸濆嫬鈧骞婇幘鑸殿潟闁跨噦鎷�
闂備礁鎼崯鐗堟叏妞嬪海绀婂鑸靛姈閻擄綁鎮规潪鎷岊劅婵炲眰鍊曢湁闁挎繂妫欑粈鈧梺鍛娚戦悧鐘茬暦閹扮増鏅搁柨鐕傛嫹
婵犵妲呴崹顏堝礈濠靛棭鐔嗘俊顖氬悑鐎氱粯銇勯幘瀵哥畺閻庢熬鎷�
濠电姷顣介埀顒€鍟块埀顒勵棑缁辩偛顓奸崶銊ヮ伕濡炪倖鎸荤换鍐偓姘虫珪娣囧﹪顢涘Δ鈧晶鍙夌節椤喗瀚�
婵犵妲呴崹顏堝礈濠靛棭鐔嗘慨妞诲亾鐎规洦鍓熼、娆撳礂閻撳簶鍋撻悽鍛婄厸闁割偅绻勫瓭婵犳鍣幏锟�
婵犵妲呴崹顏堝礈濠靛棭鐔嗘慨妞诲亾闁哄苯鎳橀崺鈧い鎺嗗亾闁宠閰i獮鎴﹀箛闂堟稒顔嗛梻浣告惈鐎氭悂骞忛敓锟�
婵犵妲呴崹顏堝礈濠靛棭鐔嗘慨妞诲亾鐎规洩缍侀獮瀣攽閸偂绱�
濠电姷顣介埀顒€鍟块埀顒勵棑缁辩偛顓兼径濠勭厬闂佺懓鐡ㄧ换鍕敂鐎涙ü绻嗘い鏍殔婢у弶绻濋~顔藉
闂佽楠搁崢婊堝礈濠靛鍋嬮柟鎯版閻鈹戦悩鎻掓殭闁奸潧缍婇弻銈夋嚍閵夈儱顫嶉梺缁樼壄缂嶄礁鐣峰▎鎾存櫢闁跨噦鎷�
UB闂備礁婀辩划顖炲礉濡ゅ懐宓侀柛銉㈡櫆鐎氭岸鎮楀☉娅虫垿锝為敓锟�
闂備浇澹堟ご绋款潖婵犳碍鐒鹃悗鐢电《閸嬫捇鐛崹顔句痪濠电姭鍋撻柨鐕傛嫹
闂佽楠哥粻宥夊垂閸濆嫸鑰块柛銏㈠殰
闂備礁鎲″缁樻叏妞嬪海绀婂璺虹灱閸楁碍绻涢崱妤€顒㈤柛鐐差槹缁绘稓绱欓悩鍝勫帯闂佺ǹ楠忛幏锟�
缂傚倸鍊烽悞锕傛偡閿曞倸鍨傛繝濠傚椤╅攱銇勯幒宥囶槮缂佹彃婀遍埀顒傚仯閸婃繄绱撳棰濇晩闁跨噦鎷�
©2017 www.mb5u.com婵犵妲呴崹顏堝礈濠靛棭鐔嗘慨妞诲亾鐎殿噮鍣i幃鈺呭箵閹烘挸鐦�
闂備浇銆€閸嬫捇鏌熼婊冾暭妞ゃ儻鎷�&闂備礁鎲$敮鎺懳涢弮鍫燁棅闁跨噦鎷�