设为首页 收藏本站
查看: 807|回复: 0

[经验分享] 针对MySQL数据库主从延迟的问题

[复制链接]

尚未签到

发表于 2018-9-27 13:31:12 | 显示全部楼层 |阅读模式
  因从库是单进程,采用队列形式应用主库推送过来的binlog日志,当主库写压力较大时,从库就会跟不上,从而产生延迟。
  调整业务:
  1、一些公司的数据库设计,把各种业务的库都放到一个数据库实例里,比如一条update更新语句较慢,那么从库就会卡在那里,出现延迟。
  应拆分不同的业务到不同的服务器里,例如用户登录表、网站首页涉及的表、文章帖子相关表,站内搜索表、LOG日志表,这样就减少了主库的写压力。并且这样的好处很明显,一个环节出现了问题,不会影响所有的应用。
  2、将统计分析类型的SQL语句在单独的BI数据库服务器上做查询,不要在主库和从库上,因为这种类型的SQL都比较复杂,执行的时间也很长。
  3、pt-kill部署线上环境,定义5-10秒,杀死耗时很长的SQL,这样在读写分离时,从库不会因为一条SQL卡在那里,出现延迟。
  4、有计划的进行对大表拆分并迁移,一张大表的DML操作在高并发环境肯定比一张小表的DML操作吞吐量低(可以用sysbench分别压测一千万和一亿条记录,看哪个QPS高),例如订单表,用户一般只关心3个月内的订单,那么就可以通过时间字段,将历史数据拆分出去,并迁移到单独的服务器里,减缓压力。
  5、将MyISAM表批量改为InnoDB,升级数据库版本,改为MariaDB或Percona,这样会有更高的吞吐量。
  6、增加内存,调整InnoDB_Buffer_Pool的大小,将数据和索引更多的缓存在内存里。
  通过以上的调整,可以大大减少主从延迟的问题。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-602861-1-1.html 上篇帖子: crosync + pacemaker + (NFS,DRBD,iSCSI)实现MySQL的高可用 下篇帖子: Linux下C++访问MySQL-Art
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表