MySQL数据库技术体系介绍

1、技术创新，变革未来MySQL数据库技术体系介绍01 MySQL简介与主流分支版本01MySQL 之父Michael “Monty” Widenius1、开源MySQL数据库的创始成员2、MySQL AB公司的首席技术官3、MySQL数据库第一行代码的作者4、MySQL数据库命名人5、MariaDB创始人兼首席技术官；6、独自完成撰写MySQL数据库服务器端95%的代码。MySQLMaxDBMariaDB01MySQL 介绍1999成立MySQL AB公司2000公布源码，采 用GPL协议， 正式进入开源 世界2008.1.16Sun收购 MySQL2019MySQL5.6 MySQL5.7 M

2、ySQL8.0（2016.8.25DMR、2018.4.8 GA）2005.10里程碑，发布 MySQL5.0，奠 定了迈向高性 能数据库基础2009.4.20Oracle收购Sun（MySQL5.5）1979 TcX UNIREG1995 Sun Solaris01MySQL 主流分支MySQLEnterprisePercona ServerMariaDBDrizzleMySQL官方MySQL号称最接近MySQL Enterprise发行版的 产品XtraDBMonty团队迭代更干净、快速的MySQL不兼容MySQL01MySQL 行业前景01全球最大网站Top2001国内MySQL行业应用

3、 互联网行业数据库MySQL市场第一 甲骨文公司的两款数据库（Oracle+MySQL）共占据着全世界的数据库市场份额的60%以 上，在中国（Oracle+MySQL）的使用更占到80%左右 中国前100个大企业/国有企业有99个以上使用Oracle为主MySQL为辅，中国前100个互 联网行业公司有95%以上使用MySQL为主Oracle/NoSQL为辅 MySQL数据库在互联网行业90%以上的使用比例，最典型的就是BAT了，近2年开始MySQL扩展到金融、通信、生产制造、快速消费品零售、物流运输、医疗、政府等行业01MySQL 介绍Oracle VS MySQL ： 企业服务软件的开源与闭

4、源之争01MySQL 介绍Oracle VS MySQL ： 企业服务软件的开源与闭源之争Oracle： 功能强大保障体系充分，MOS成熟度高BUG更新较快并发机制粒度细，并发高软件成本高运维成本依赖数据规模，小规模数据库 运维成本远高于MySQL，大规模数据库 运维成高低于MySQL。传统行业的霸主技术掌控度低MySQL：功能略有不足保障体系成熟度不如Oracle BUG更新不如Oracle并发机制较粗，比Mongo类NoSQL要强， 并发性总体不如Oracle软件成本低运维成本依赖数据规模，小规模数据库 运维成本低于Oracle，大规模数据库运维 成高低于Oracle。互联网行业技术掌控度

5、高02 浅谈MySQL架构05阿里去O的背景淘宝、阿里巴巴B2B和支付宝等公司，98%以上的软件系统和业务都是采用Oracle数据库提供数据服务07年开始阿里巴巴IT开销史无前例，有着国内之最的趋势，一度成为IBM、Oracle的中国标杆客户09年淘宝更是上了全球排名Top N的大RAC集群，亚洲第一，有20个节点那么，问题来了，千万级甚至上亿的Oracle产品+服务无法支撑阿里发展的速度，how to ？ 传统的关系型数据库在扩展方面没一家解决得好的 DB层已无法独自承载互联网社区业务的高速发展，架构开始受到重视 由一家服务商绑定，风险高 阿里选择MySQL背后主要考虑的是成本，以及开源可以

6、定制05阿里去O的背景05阿里云POLARDB05阿里云POLARDB05熟悉的Oracle/MSSQL基础架构Oracle/MSSQL有哪些常用的架 构呢？Oracle/MSSQL架构中不同节点 如何保证数据的强一致性？那么，MySQL又有哪些常用的架 构呢？05一个原则两个理论ACID原则CAP理论BASE理论05ACID原则-RDBMS理论基础05ACID原则-RDBMS理论基础ACID四大基本特性原子性（Atomicity）：事务是不可分割的工作单位，事务中的操作要么都发生，要么都不发生。一致性（Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态

7、。一致性的核心一部分是靠原子性实现，另一部分是逻辑实现。隔离性（Isolation）：事务在正确提交之前，不允许把事务对该数据的改变提供给任何其他事务。四大隔离级别，事务隔离级别越高，高并发场景下产生的问题就越少，同时付出的性能消耗也将越大。持久性（Durability）：事务完成后，对数据库所作的更改便持久的保存在数据库中，并不会被回滚。MySQL默认REPEATABLE-READ:可重复读Oracle默认read committed:读已提交05CAP理论CAP理论是指一个分布式系统不可能同时很好的满足强一致性（Consistency）、可用性（Availability）、分区容错性（Pa

8、rtition tolerance）这3个要求，通常最多只能同时较好的满足其中的两个。强一致性系统在执行过某项操作后仍处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应 该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。可用性每一个操作总是能够在一定的时间内返回结果，一定时间指的是在可以容忍的范围内返回结果，结果 可以是成功或者失败。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求分区容错性指当出现网络分区的情况时（即系统中的一部分节点和其他节点进行通信）分离的系统也能够正常运行。理解 为在存在网络分区的情况下，仍然可以接受请

9、求。节点crash或者网络分片都不应该导致一个分布式系统停止 服务。05CAP理论CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强。 CP：满足一致性，分区容错的系统，通常可用性不是特别高AP：满足可用性，分区容错性的系统，通常可能对一致性要求低05BASE理论BASE理论是为了解决关系型数据库强一致性引起的可用性降低而提出的解决方案。核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性。BASE理论来源于下列三个特征：基本可用（Basically Available）基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。在无法通讯时 选

10、择可用性。软状态（soft state）软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份 数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。用镜像读代替强一致性读。最终一致性（Eventual Consistency）最终一致性是指系统中所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致 性相反，最终一致性是弱一致性的一种特殊情况。用异步方式确保完成数据更新。思考：BASE与CAP、ACID的区别和联系？05熟悉的MySQL基础架构 Distributed Replicated Block Device MySQL R

11、eplication MySQL Group Replication MySQL Innodb Cluster MySQL NDB Cluster Master Master MySQL Master High Availability Galera Cluster for MySQL Percona Xtradb ClusterDRBD、MR、MGR、MIC、MNC、MMM、MHA、MGC、PXC、PhxSQL、AliSQL、DRDS你能说出几种呢？05DRBD（Distributed Replicated Block Device）构成要素DRBD模块包drbd84-utils、 kmod

12、-drbd84物理/虚拟磁盘（存储）或者分区MySQL数据库（软件安装于本地）Corosync（集群通信）Pacemaker（资源管理）Crmsh（资源配置，用CRM交互工具实现）模式单主模式：典型的高可靠性集群方案双主模式：需要采用共享cluster文件系统， 需要特别配置，drbd8.0之后版本DRBD（Distributed Replicated Block Device），由内核模块及脚本组件构成，以组建高可用架构。实现方式， 是用软件实现的、无共享的、服务器之间通过网络来镜像块设备内容的存储复制（ /dev/drbd0 ），可以 将DRBD理解为一种基于网络的RAID105DRBD（

13、Distributed Replicated Block Device）优势架构简单，同步模式下，保证数据的强一致性无单点故障实现高可用无集群脑裂（Corosync+Pacemaker来自第三方）劣势主机资源未充分利用无法取代备份05MR（ MySQL Replication ）ABABC1.经典复制架构，1对1AB2.级联复制3.经典复制架构，1对多05MR（ MySQL Replication ）4.双主复制ABAB5.双主级联复制ABC6.双主循环复制05MR（ MySQL Replication ）AB7.多源复制C05MR（ MySQL Replication ）优势架构简单，无单点

14、故障确保高可用技术门槛低，运维简单查询类业务可实现负载均衡，分担主节点压力劣势写业务扩展性较差不支持同步复制，数据强一致性较差05MR（ MySQL Replication ）async（Asynchronous Replication，异步）MySQL复制中传输日志的一种模式，叫做异步复制，MySQL默认支持的就是这种模式， 最为通用，在不影响主库性能的前提下尽可能地保证数据的安全。主库在执行完一些事务后，不知道备库的进度。如果备库落后，并且此时主库又出 现Crash（例如宕机），这时备库中的数据就是不完整的。semi-sync（Semisynchronous Replication，半同步

15、）跟async一样，是MySQL复制中传输日志的另外一种模式，叫半同步复制，仅保证事务 已经传递到备库上，但是并不确保已经在备库上执行完成了。在MySQL5.5中引入并支持。 在这种模式下数据的一致性得到最大保障，但会损失一定的写入性能。05MR（ MySQL Replication ）异步复制05MR（ MySQL Replication ）半同步复制在经典的复制架构中，哪一种复制模式更适合用于部署自动化切换脚本呢？05MR（ MySQL Replication ）利用该架构如何实现对前端的透明？如何实现高可用？常用的负载均衡器有哪些？Load BalancerMySQLRouterMySQ

16、L ProxyProxySQLLVSKeepAlivedHAproxyNginxAtlas05MMM（ Master Master MySQL）05MMM（ Master Master MySQL）优势存在双主节点，没有主机宕机后的选主问题，直接切换即可架构比较简单，使用原生半同步复制作为数据同步的依据劣势完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证需要额外考虑HAProxy、Keepalived的高可用机制至少3个节点05MHA（ Master High Availability ）05MHA（ Master High Availability ）05MHA（

17、Master High Availability ）优势故障自动检测和转移扩展性较好，根据需要扩展MySQL的节点数量和结构相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低master crash 不会导致主从数据不一致由Perl语言开发的开源工具劣势至少需要3个节点，相对于双节点需要更多的资源逻辑较为复杂，发生故障后排查问题，定位问题更加困难可能因为网络分区发生脑裂现象需要基于SSH免认证配置，存在一定的安全隐患需要编写脚本或利用第三方工具来实现VIP的配置05MGR（MySQL Group Replication）Ref：/doc/refman/5.7/en/g

18、roup-replication-summary.html了解一规则：分布式先提交获胜规则由MySQL基于Paxos所开发的，基本复制理念05MGR（MySQL Group Replication）单主模式05MGR（MySQL Group Replication）单主模式05MGR（MySQL Group Replication）多主同步模式05MGR（MySQL Group Replication）多主同步模式05MGR（MySQL Group Replication）（N/2+1）高容错度05MGR（MySQL Group Replication）优势单主模式，查询类业务可实现负载均衡，

19、分担主节点压力，无延迟复制，能保证数据强一致性多主模式，多节点写入，无延迟复制，能保证数据强一致性数据一致性保障：确保集群中大部分节点收到日志多节点写入支持：多写模式下支持集群中的所有节点都可以写入Fault Tolerance: 确保系统发生故障（包括脑裂）依然可用，双写对系统无影响劣势只支持Innodb存储引擎，且每张表一定要有一个主键目前一个MGR集群最多支持9个节点COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set05MNC（ MySQL NDB Cluster ）MySQL Cluster是一

20、个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。05MNC（ MySQL NDB Cluster ）Data节点组内采用同步复制，以保证组内节点 的数据一致性，通过两阶段提交协议实现A： 我 要 提 交 了 ， 发 送 事 务 给 B B： 我 准 备 好 了 ， 并 反 馈 给 A A：好的没问题，你提交吧，发送指令给B B： 我 提 交 好 了 ， 并 反 馈 给 A A：报告该事务提交/回滚，继续进行下一个事务 处理同步复制共需要4次消息传递，减慢响应时间，消 耗部分性能，数据节点之间是走网络的，强烈建 议MySQL Cluster运行在

21、千兆以上的局域网内。05MNC（ MySQL NDB Cluster ）节点节点组分区数据副本05MNC（ MySQL NDB Cluster ）配置冗余，实现Data节点高可用05MNC（ MySQL NDB Cluster ）Defining NDB Cluster Data Nodes（管理节点config.ini）ndbd default NoOfReplicas=2The default value for NoOfReplicas is 2. This is the recommended value for most production environments.ImportantWhile the maximum possible value for this parameter is 4, setting NoOfReplicas to a value greater than 2 is not supported in production.WarningSetting NoOfReplicas to 1