MySQL企业版线上专场 | 三合一精华版
MySQL企业版线上专场 | 三合一精华版
2020年4月7~9日，MySQL团队与3306π社区联合举办大型线上活动，为广大MySQL的爱好者和使用者带来一场MySQL技术盛宴。活动期间，叶金荣老师每晚迅速整理会议内容并将其广播，为活动尽心尽力，实在是MySQL社区的楷模。我在这里厚起脸皮，坐享其成，实在有些惭愧。今天这篇的内容全部来自叶老师的公众号“老叶茶馆”和“3306pai"公众号，我将三天的内容合而为一，供小伙伴们阅读。再次感谢叶老师的付出。下面内容全部为转载内容：
第一天的活动总报名超过200人，最高在线110多人，在工作日能有这样的出席率，挺超预期的，谢谢各位小伙伴们的热情参与。
首场由Ivan Tu（杜修文）老师分享MySQL 8.0的发展近况，主要介绍了8.0版本的一些新特性，以及MySQL企业版在数据加密、认证、授权、防火墙、审计、脱敏等方面所做的增强。
此外，杜老师还详细介绍了企业版的商业技术支持方面的优势，对企业版有兴趣的同学可以联系我们，也可以直接联系本次分享的几位嘉宾老师，或相关销售。
在本次分享中，我作为与会者代表来提问，杜老师也都相应认真地做了回复。
针对大家比较关心的几个问题，再次和大家分享下：
- MySQL目前约有将近400位专职开发者，而且在InnoDB引擎、优化器、Server层等各子团队的人员规模也都很大，这个团队规模相信其他开源数据库软件都无可比拟，更让我对MySQL充满了信心。
- 每个MySQL大版本号的生命周期通常是8年左右，按照这个周期推算，MySQL5.6也将于今年“寿终正寝”，还是尽快升级到5.7或者8.0吧。当然，想要继续使用旧版本也没问题，只不过相应的支持（不管是商业支持，还是bug修复等）可能就没有了。
- MySQL 8.0起，开始采用CDM软件开发模型（持续交付，Continuous Delivery），这使得每个发布的子版本都更加可靠，相对以往也拥有更多新特性。
- 想升级到MySQL 8.0的话，建议直接使用最新的8.0.19版本，不过在该版本中新增的特性可以等再过2 ~ 3个子版本后再使用，会更可靠一些。也就是，往回推算，8.0.16版本新增的功能，在8.0.19基本上可以放心使用了。
- MySQL企业版基本上可以符合国内三级等保要求（四级等保要求是国产软件才可以），还是相当可靠的。需要做等保业务的小伙伴们可以放心了。
第二天活动
「3306π」MySQL企业版线上活动的第二场，本次活动总报名人数相对昨天又增加了几十人，今天最高在线106人，比昨天略少了一丢丢，还是超出预期挺多。
今天由徐轶韬老师分享面面俱到的MySQL安全方案，详细介绍了MySQL企业版在数据加密、认证、授权、防火墙、审计、脱敏等方面所做的增强。
数据库作为存储企业数据的重要资产，数据库的安全也不容忽视。
每年都会出现几次比特币勒索事件，以及删库跑路甚至删库导致破产的事故，好好好保护珍贵的企业数据。
我们一起看看MySQL 8.0企业版在数据安全、信息安全方面都有哪些给力的方案，以及如何给MySQL加上一把可靠的防火墙。
企业级应用中，MySQL数据库通常面临下面的安全风险：
- 缺乏配置
- 更改默认配置和控制
- 特权账户管理
- 权限策略
- 访问控制薄弱
- 专用管理账户
- 认证薄弱
- 强制实施“强”密码
- 审计薄弱
- 合规性和审计策略
- 缺少加密
- 数据、备份和网络加密
- 备份不安全
- 对备份进行加密
那么该如何保证数据库安全呢，有几个建议：
- 定期风险评估和漏洞修复。
- 使用加密算法，用户控制，访问控制预防
- 使用审计，监控 告警等手段预防
- 保证服务不会中断，主库要能够持续提供服务。
MySQL 8.0企业版在安全方面有以下增强特性：
- 支持TLSV1/3
- SSL的动态选项
- 动态链接
- TDE方式除了能加密用户表空间、系统表空间，还能加密redo、undo log，以及binlog，大大增强数据安全性
- 管理专用端口
- 撤销部分权限
- 引入角色权限控制
- 默认使用sha256_caching机制
- 双重密码
- 完善的密码策略
- keyring API秘钥管理
- 数据屏蔽和反识别功能 （重点）
- 审计功能完善 多种输出结果
- 支持LDAP认证
- SQL防火墙，阻止SQL注入攻击，入侵检测系统
关于MySQL企业版更多诱人特性，可以先看看下面的视频介绍。
视频内有彩蛋，如果能发现，说明您具备成为优秀MySQL DBA的潜质哦。
第三天活动
今天是「3306π」MySQL企业版线上活动的第三场，亦是最后一场。本次活动总报名人数接近300人，今天最高在线130多人，在线互动超过40多个问题，果真还是高可用话题最热。今天由Ivan Ma（马楚成）老师分享《新世代MySQL高可用方案InnoDB Cluster》，简称MIC。一开始，马老师就又给大家安利了一波MySQL 8.0，当然了，主要还是因为就连5.7版本，也计划将于2020年10月停止常规支持了。
也就是说，除非你买企业版商业支持，否则到今年10月份，5.7版本就没有更新版本出来了，（注：我来说明一下，今年10月份，5.7版本进入延长支持阶段，补丁不会像之前那样频繁发布，只会发布安全方面的补丁，2023年10月之后，5.7停止发布任何补丁）无论是遇到bug，还是想用8.0里优秀的新特性，都统统没戏...所以，还是升级了吧。
言归正传，基于MySQL社区版上的高可用方案，真可谓五花八门、八仙过海的感觉，例如drbd、lvs、haproxy、keepalived、mysql-mmm、mha、pxc，真的是眼花缭乱。
自从MySQL官方推出Group Replication后，MySQL原生的高可用方案发展路线愈发明确，那就是先实现读节点扩展，再实现写节点扩展（MGR的multi primary模式），然后再推出配套的高可用管理套件，就是MySQL InnoDB Cluster（MIC）了。
MySQL 8.0.17开始推出Clone Plugin，在8.0.19推出ReplicaSet功能，这个意图也很清楚了，基于Clone Plugin即可快速部署出一个MGR集群，很大程度降低了InnoDB Cluster的使用门槛，提高部署效率，也更方便我们开发配套的管理系统了。
只不过，MGR也不是银弹，不能解决一切高可用的需求。
先简单发几页马老师分享的PPT内容以飨各位读者吧。
下面放几个现场的互动问题：
Q1. 基于当前8.0.19版本，官方是否建议mgr使用多主模式
A1. 单主模式是一个通用的方法。多主模式有规范，有要求，所以主张用单主。单主问题比较少，还很轻松，方便用上MySQL Inno DB cluster。
Q2. mysql router可以只做HA切换，不做读写分离吗？
A2. 可以支持读写分离的。参考文档：https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-deploying-basic-routing.html参考配置：[routing:primary]bindaddress = localhostbindport = 7002destinations = foo.example.org:3306,bar.example.org:3306routing_strategy = first-available这时候 7002 端口就是可以进行读写的
Q3. ndb cluster业务连续性更高，为什么不建议用ndb cluster呢
A3. MGR和单机都采用InnoDB引擎，比较简单。另外，ndb cluster对于硬件环境要求比较高，而且不能跨IDC。NDB有特殊场景，适用于并发高，小事务。
Q4. mgr切换方式，采用中间件路由的方式，还是客户端connector方式，哪种方式官方更支持一点？
A4. 我们推荐使用MySQL router，一个轻量级中间件。
Q5. MySQL router作用就是个代理层，能人工干预客户端请求权重不？还有就是mgr架构改变了，添加节点什么的要重新配置mysql router不像proxysql那样方便。
A5. 使用innodb cluster时会自动获得当前最新状态，不需要手动配置。InnoDB Cluster中router会读在数据库中的innodbclustermetadata_schema的配置信息，会自动知道结构的变化。
Q6. 这个innodb cluster与pxc 、MHA等高可用集群有什么区别呢。
A6. PXC和MHA都不是官方出品，有问题官方无法支持。另外MHA已经不适用8.0版本，PXC的发展速度最近也不是很快，PXC和Innodb cluster的实现也不太一样。MHA架在传统复制上,只是多了客户端自动故障移转,不保障数据在节点中一致性,MySQL InnoDB Cluster则能。MHA是基于主从结构的高可用，主要工作在非GTID的时代。PXC是基于InnoDB引擎的复制， InnoDB Cluster是在Server， engin之间利用group replicaiton 这个plugin 构建，可以理解为并行复制的改良版。
Q7. router 能使用一个port 自动读写分离吗？还是必须使用不同的端口？
A7. 读写分离需要2个端口，给RO和RW指定不同的端口。
Q8. mgr能做两地三中心的方案吗？
A8. 同城可以，异地由于网络原因，只能使用异步复制。
Q9. mgr对数据量有没有什么限制吗，相对NDB Cluster 而言，后续如果做分表分库，mgr有什么好的建议吗？
A9. 自动的分库分表，是innodb cluster将来发展的方向。请期待。
Q10. 组复制有单个事务的最大限制？最大的事务限制是多少啊？
A10. 不建议单个的大事务，会引起超时，踢出节点。跟你的超时配置有关系。5.7时建议不要大于200M行,或大于5秒的处理时间,8.0可设定超过一定大小会自动切,理论上没有限制。
好吧，就先放出这10个大家比较关心的话题，更多的话题需要后面看视频回放了。
至此，三天的线上直播分享活动完美收官，再次感谢大家的支持。本次活动相关的资料以及获得礼品的列表我们会在后续的推送中尽快发布，敬请期待。