通用三合一mysql_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个大家比较关心的话题，更多的话题需要后面看视频回放了。

至此，三天的线上直播分享活动完美收官，再次感谢大家的支持。本次活动相关的资料以及获得礼品的列表我们会在后续的推送中尽快发布，敬请期待。

活动预告，「3306π」上海站因为YQ的原因，也计划改为线上直播分享，具体方案我们还在筹备中，请大家持续关注我们公众号的最新发布。

全文完。关于「3306π」社区围绕MySQL核心技术，将互联网行业中最重要的数据化解决方案带到传统行业中；囊括其他开源技术RadonDB、ClickHouse、Redis、MongoDB、Hbase、Hadoop、ElasticSearch、Storm、Spark等；分享干货知识，即便是赞助商，也要求如此，拒绝放水