专栏首页「3306 Pai」社区大话MySQL之爱恨情仇

大话MySQL之爱恨情仇

在数据库的发展过程中,安全-->稳定-->高效-->低成本四个有序的要点一直如影随形,后者离开前者就是空谈。10月19日晚上MySQL发布了8.0.22版本,其中一个新功能(Automatic connection failover for Async Replication Channels)引起我的注意,也很感兴趣,作为一个DBA老兵,百感交集,在过去的20多年,故障切换功能一直是三方后娘工具在主导,是几代DBA的痛,互联网最流行的数据库,在这块一直为人诟病。此功能还没有测试,不管如何,至少在这块官方终于开始出手解决了。夜深人静,整理了一下思路,对于MySQL产品截至目前的发展情况,做了一下总结,基本走以下几个方向发展:

  1. 主从同步方向:异步同步到半同步,再到增强半同步,再到组复制;走同步的安全策略,到提升同步的效率,走单线程复制到并行复制,致力于降低主从延迟问题,但相对的同步绝对的延迟伴随其发展全过程至今。
  1. 性能优化方向:多线程,线程池(原版MySQL的企业版支持,社区版不支持);各种日志各种独立,截止8.0.22版本,保证安全与问题记录的日志基本全部独立了,可以动态调整参数单独控制关闭和打开;重构核心引擎Innodb,优化各种锁,独立锁,优化事务操作等。各种的一顿骚操作优化,使得最新版的MySQL性能也达到了前所未有的高度。
  2. 多模数据库方向:关系型数据、JSON半结构化数据、对象数据、内存型以及全文检索引擎等等多个数据引擎,走支持OLTP业务开始拓展至OLAP业务(Oracle云上支持的Analytics Service),虽然只有它自己的云上支持。
  3. 借鉴其他数据库方向:最大的借鉴为ORACLE数据库,现在的各种语法和一些用法越来越ORACLE了;借鉴了MongoDB的一些功能,如MIC(MySQL innodb cluster)中的相关设置、自动搭建从节点的克隆功能等,不过在使用中确实有点复杂。
  1. 智能化运维方向:支持各类在线DDL,对业务几乎无感知,这个为以后智能自助动态优化索引打下坚实的基础;重点的性能参数差不多都支持在线修改;支持持久化动态调整参数,保证重启后参数与重启前一致;关闭MySQL时可以把内存的热数据持久化到硬盘,启动时重新由硬盘加载到内存,减少了数据库预热,使数据库重启后快速进入之前的战时状态;SQL语句的重写功能,不变更业务代码情况下重写SQL;可以支持根据硬件配置,启动时自动调整部分参数配置,虽然可自动调整的参数有限,结合前几项,为未来MySQL在智能参数调优与自我优化方面、自治数据库的发展奠定了基础。
  2. 提升安全性方向:健全的日志,保证在各种异常状态下不丢失数据,这也是数据库最基本的要求,MySQL也一直在努力增强再增强,努力打造金融级数据库;增强的用户验证方式caching_sha2_password,强化认证模式,增加用户认证串被暴力破解的难度。但最大的安全功能failove却一直没有。
  3. 降低成本方向:这个路线进度有点慢,目前在innodb的压缩上有所发力,压缩比有所改进;在增强用户使用体验,简化使用操作等人力成本上一直在努力,不过有些操作比较畸形,操作配置使用复杂,比如MIC的配置。

固然MySQL深受广大人民喜爱,装机量也很大,其本身也特别优秀,但爱之深恨之切,依然有许多不足:

  1. 在自动创建从节点,组复制刚自动增加新节点竟然必须要有数据库初始化开始全部的Binlog日志才行(感觉设计这个方案的产品脑仁有点小),否则就需要使用mysqldump手动搞定,至今增加新节点的操作依然很骚,依然不方便,操作依然复杂,反观MongoDB就简单多了,不管是操作还是运维成本都很低。
  2. MySQL经过20多年的发展,至今故障切换依然依赖三方工具,故障自愈方面好好改进一下,不过至今为止,不是很理想。其实在MySQL的JDBC中很早就类似MongoDB支持链接多数据库多节点配置,但是自身没有故障自动检测和切换功能,这个功能一直是个摆设。MySQL8.0.22版本终于支持故障启动切换,走配置参数来看,节操碎一地,估计差MongoDB的这个功能不是一星半点。期待官方在这块投入更多的人力物力,使MySQL结束这种原始操作状态,提升一下运维人员SLA和业务的不可用时间。
  3. drop table/database删除操作的优化,目前删除大表和库的时候对数据库性能影响巨大,甚至能把数据库给干挂了。
  4. 假删除或延时删除库表,做数据库的删除回收站,给数据库定制后悔药。
  5. MIC目前是个鸡肋,估计也没啥人用,router和shell组件完全可以集成进MySQL中,组件越多运维等成本越高,这种管理模式用中间件不也挺好,还能私人订制(毕竟修改中间件的成本没有MySQL源码的高),配置管理复杂,向MongoDB复制集看齐不香嘛?
  6. 每个产品都有其核心竞争力,MySQL现在的产品有忘记初心(安全、稳定、高效、低成本)的嫌疑,花活太多,想做的东西太多,想要参考其他数据库功能也很多,all database in MySQL行的通嘛?真的能一统数据库江湖唯吾独尊嘛?

传说中的MySQL存储与计算分离官方是否会支持?

数据库的存储与计算分离架构这两年很火,这也是数据库发展的一个方向,一方面硬件技术的进步,支持弹性伸缩,合理利用资源,降低成本,二来高并发大数据量的业务需求,特别是万物皆为云的当下,这种架构的出现确实应时应景。MySQL如果支持这种架构,必然要对MySQL-Innodb的存储引擎做大量的修改,而且还要有自己对应的分布式文件系统,当前的MySQL架构可能要做大量的调整。MySQL官方为了进一步降低主从同步延迟,可能会支持物理复制来优化延迟问题。至于存储与计算分离个人感觉官方不会支持,至少在在短时间内不会支持,也许在MySQL 13中会支持,因为我河南老乡王守义说过十三香^-^

集多种数据库优点之大成,不忘初心,海乃百川,有容乃大,感觉MySQL还是不够包容和开放。很多现成的成功案例和方案思路,借鉴过来即可,何况官方的研发人员也是全球顶级的,咋就学不会呢?很多事情咱也看不懂,咱也不知道,咱也不敢问,谁知道哪,说不定明天一觉醒来MySQL来个华丽转身,穿个新娘装跑步进入智能化、自治化数据库时代呢?

全文完。

Enjoy MySQL :)

本文分享自微信公众号 - 3306pai(pai3306),作者:王伟

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-10-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 大话MySQL之爱恨情仇

    在数据库的发展过程中,安全-->稳定-->高效-->低成本四个有序的要点一直如影随形,后者离开前者就是空谈。10月19日晚上MySQL发布了8.0.22版本,其...

    MySQLSE
  • Maven的爱恨情仇

    在如今的互联网项目开发当中,特别是Java开发中,可以说Maven是随处可见。Maven的仓库管理、依赖管理、继承和聚合等特性为项目的构建提供了一整套完善的解...

    xcbeyond
  • pytorch和tensorflow的爱恨情仇之张量

    pytorch和tensorflow的爱恨情仇之基本数据类型:https://www.cnblogs.com/xiximayou/p/13759451.html

    西西嘛呦
  • 我与 Kotlin 的爱恨情仇之浅谈 block

    用户1907613
  • 大数据下的帝都魔都的爱恨情仇

    作者:茅明睿 世界互联网大会举办期间,由DF数据竞赛平台(DataFountain,DF)承办的形式多样的“双创热土”生态对接会暨“共创大数据生态 共赢数字经...

    钱塘数据
  • 大数据下的帝都魔都的爱恨情仇

    会议期间,城市象限 CEO、前北京市城市规划设计研究院规划信息中心副主任茅明睿所做的《大数据下的帝都魔都的爱恨情仇》报告吸引了很多嘉宾的关注。现将报告PPT分享...

    华章科技
  • 我对“Hello World”30年的爱恨情仇

    我最近在4月1日的那一周休了一个假,因此有时间来回顾我的职业生涯。令我震惊的是,我已经写了近30年的代码了!于是,我决定好好利用这段额外的休息时间来创作一篇怀旧...

    哲洛不闹
  • 程序员与网站的爱恨情仇

    二十一世纪互联网的兴起,网站开发技术蓬勃发展,门槛也随之降低。 程序员在自己电脑上比划着鼠标装了几个软件, 打开IDE, 新建一个页面, 点一下运行按扭,网站跑...

    用户1608022
  • pytorch和tensorflow的爱恨情仇之参数初始化

    当然还有一些像:torch.zeros()、torch.zeros_()、torch.ones()、torch.ones_()等函数;

    西西嘛呦

扫码关注云+社区

领取腾讯云代金券