Shadowserver Foundation在5月31日发布了一份全网的MySQL扫描报告，共发现了暴露在公网的360万个MySQL实例。因为这份报告基数够大，而且信息也非常完整，从数据库专业的角度来看，里面是有很多非常有意思，且可以量化的数据和结论的。之前网上的一些分析都是基于安全角度来分析，这里我们一起再看看这份报告里面隐含的一些数据库信息吧。

另外，这里的“暴露在公网”，是指其端口在公网可以被访问且响应握手信息，并不是可以被登录，并没有什么安全隐患。原报告的文章链接可以在文章结尾处查看。

数据说明

该数据由Shadowserver的SCANNING PROJECT收集，总计扫描到537.8万个打开的3306端口，其中IPv4协议的395.7万个，IPv6协议142.1万个。这些端口中反馈了握手信息的共360万个，其中IPv4协议的228万个，IPv6协议134.4万。

返回握手信息的360万实例，因为握手信息包含了版本等信息，加上Shadowserver的地域等信息，就构成了一份较为完整的MySQL实例版本和实例分布数据。

Shadowserver并没有公布完整的数据详细信息，但依旧公布了多个维度的数据供分析。

全球共有800万MySQL实例在运行？

根据一些公开数据和部分经验数据，这里对全球MySQL运行实例个数做一个预测。在这份报告中，共探测到约538万开放的3306端口，其中约360万返回了握手信息。那么，全球一共有多少MySQL在运行呢? 这里基于以下信息做一个猜测：

• 根据帕累托法则，即2/8原则，约仅有20%的因素影响80%的结果
• 诸如Google、Amazon、微软、阿里巴巴、腾讯、字节跳动等大型企业保有大量实例，且不可以被扫描
• 还会有大量实例运行在AWS、Azure、阿里云、GCP等云环境的VPC之中，如果没有开启公网IP，通常也无法被扫描到，这部分根据一些经验数据，预计为200万个
• 根据IDC数据，全球服务器2021年出货量为1350万台

那么，扫描到538万再加上200万，则有约738万个"闲散"实例。根据2/8原则，诸如Google、Amazon、阿里巴巴等这些大型企业(非云部分)中依旧可能保有着20%的实例（738万为80%部分），也就是约为184.5万个实例。那么预计：全球整体MySQL实例数量可能在922万这样的数量级。另外，我们再从全球服务器出货量角度做一个验证。根据IDC数据，2021年全球服务器出货量约为1350万台，这里假设（该假设基于一些历史的经验）10台服务器对应一个数据库实例，那么2021年服务器出货量就对应了135万个实例，按照服务器平均5年折旧计算，总保有则约为675万个实例，这里与922万有一定的偏差。折中取这两个数据的平均值，所以这里预测：

全球MySQL实例数在800万左右

当然，这只是一个超大颗粒度的、不可验证的预测，如果有更好的预测模型或者数据支持，欢迎回复公众号讨论。

MariaDB在某些细分市场份额很大

从这份数据来看，MariaDB是拿下了非常大的市场的。从IPv4 top 10版本统计信息来看，MariaDB占比为14.3%；如果，单从IPv6的统计数据来看，MariaDB占比为86.2%，实例数量超110万。

这里在IPv6环境中，部署量最大的版本为：5.5.5-10.5.12-mariadb-cll-lve，这是一个cPanel在Lightweight Virtual Environment的发行版本，而对应的MariaDB 10.5.12版本为2021年8月发布。从这个点看到，MariaDB是获得了更多的开源社区的信任，作为其发行版的默认数据库版本。甚至在一些细分的场景中，MariaDB甚至可以说可能成为了主流。

但，另一方面，根据在中国的实际感受来看，MariaDB的市场现状并没有以上数据展示的那么乐观，原因如下：

• 一是MySQL品牌依旧非常强大，虽然安装的MariaDB，但是实际使用的客户端依旧可能是mysql命令行，所以，用户依旧当做MySQL来使用。
• 另外，目前，大型企业全面使用MariaDB支撑核心业务的公司还比较少，大部分依旧是使用MySQL，并基于MySQL去进行优化，而不是MariaDB。

当然，从这个数据角度来看，MariaDB的这个部署量依旧会给其带来很多优势：

• 提升用户认知基础，虽然命令行依旧使用mysql，但是登录后依旧会看到MariaDB版本号信息和功能
• 产品会在各种环境中被使用，对其整体的稳定性会有较大的保障
• 相比MySQL，MariaDB已经获得更多Linux发行版的信任，这可能是进一步获得扩大市场的最重要的机会点之一

49%的实例启用了TLS/SSL加密

从所有IPv4环境的实例数据来看，有49%启用了TLS/SSL加密。因为MySQL 5.7之后的版本，都已经默认开启了传输加密，这与前面的MySQL 5.7占比数据是基本吻合的，大部分用户在使用5.7或8.0的时候，都会使用其默认自带的加密能力。所以，你的实例开启了传输加密吗？延伸阅读：

• 开启TLS传输加密对数据库性能的影响
• 是时候开启数据库的加密传输了

[......]

Read more

在上周，SQL Server 2022版本（16.x）正式进入公测状态，大家都可以下载并安装了。当前只支持Windows，被称为CTP 2.0版本（community technology preview ），包含了企业版的所有功能，可以试用180天。于是第一时间下载并进行了体验，一起来看看，新版本有哪些新的功能吧。

全面建立与Azure云的联系

通过Azure Synapse Link for SQL（公测） 支持将SQL Server 2022版本与云端Azure Synapse Analytics无缝集成，从而实现分析、BI和ML等数据处理能力：参考。还可以通过Azure S[......]

Read more

在上周的Google I/O大会上，GCP（Google云平台）正式对外发布了数据库AlloyDB（Preview版本）。这里对AlloyDB的架构也做一个较为深入的分析，看看与当前的云原生数据库PolarDB、Aurora有哪些异同。01AlloyDB 整体架构图

AlloyDB是GCP上的一个全托管的云数据库服务，当前完全兼容PostgreSQL 14，提供企业级的性能、扩展性与可用性。声称是标准PostgreSQL性能的4倍，AWS同类服务的两倍（应该是指RDS PostgreSQL和Aurora PostgreSQL），如果是分析查询，则可能有100倍的性能加速。另外，在介绍时，还特别提到，价格非常透明，这应该是针对当前AWS数据库大多数都对IOPS独立并按量计费而说的。

[......]

Read more

在4月底，阿里云RDS Serverless正式公测发布。第一时间申请了公测资格，并进行了测试验证。测试完成后，整体上，还是非常值得期待的，值得开发者们去了解和小范围（例如开发测试环境）尝试。测试中，该Serverless版本的升/降配速度非常快，约10秒完成压力检测与变配，升配时性能表现非常平稳，降配时性能比较平稳。只是目前只支持基础版（单节点实例），应用场景还比较有限，不过对于开发测试环境这类，可用性要求没那么高，且性能峰谷明显的场景，是可以轻松节省超过50%成本的，而且在需要的时候，性能还会非常不错。

整体测试结论概述

• 在系统压力突增时，阿里云RDS Serverless的响应也非常快，约10秒内就可以完成变配；在之前的Aurora Serverless v2测试中，升配的时间是差不多的，都是10秒以内。
• 在系统压力下降时，阿里云RDS降配的速度也非常快，在系统压力降低之后，10秒就完成了降配。另外，当前的版本，因为降配非常快，也导致降配后，性能出现了一些波动，持续约10秒，波动幅度从约8毫秒的响应时间增长到30~50毫秒，在两次降配之后，都出现这个小波动。
• Aurora降配更加“保守”，观测了50秒，之后才开始降配。但这50秒应该是有一些讲究的，在降配之后，Aurora的性能依旧非常平稳，没有任何波动。也就是，降配过程中清除出内存池的数据页都是确确实实不再使用的，这里可能需要深入的观测InnoDB的Buffer Pool收缩时的表现，避免将可能使用数据页清理出内存。
• 当然，现在阿里云Serverless还是刚刚公测，作为尝鲜和测试使用，甚至在开发测试环境尝试使用，都是非常合适和推荐。而且，在公测阶段，可免费创建2个实例体验，最大8RCU，即约8c16g内存的实例，免费周期3个月：云数据库 RDS Serverless版公测申请 。

[......]

Read more

Aurora自2014年发布以来，一直是AWS的最核心数据库产品，而Serverless则是这个产品最重要的功能之一了。在2018年08月，Serverless功能刚刚GA，当时做过一次测试（参考）。在2020年底的re:Invent上，Andy Jassy宣布Aurora发布Serverless v2，时隔一年半，终于GA，一起来看看实际效果怎样吧。

在最近看到该功能的介绍文章中，使用了"几分之一秒内扩展"、" scales instantly and nondisruptively "等描述，对此，我是保持怀疑的，这也要实测一下的原因，从一个用户感受的角度，看看一次升级(scaling)需要多长时间。

测试结果概述

• 在这次实际测试中，新的Serverless v2，可以将scaling up的时间降低到10秒级别。系统压力上来后，首次升级(scaling up)花了13秒，之后的几次升级分别花了7秒、4秒、10秒等。在这几秒内，Aurora需要完成监控采集、分析与决策，变配动作完成等动作。于用户侧，系统压力突增时，10秒内Aurora就会完成升级，这是非常实用和强大的。
• 相比4年前GA版本数分钟级别的升级(scaling)，新的版本提升非常大。不过，与宣传的亚秒级( in a fraction of a second )还有差距的。当然，一种猜测是，"亚秒内"完成的是变配动作本身，不包括监控、决策与命令下发等过程。
• Scaling down是逐步阶梯式完成的，每次间隔约1分钟，这是符合预期的。
• 新的版本与旧版本有非常好的兼容性，可以作为旧版本的replica，然后切换为主节点，也就可以完成平滑的升级。新的版本，支持MySQL 8.0和PostgreSQL 13版本。
• 该功能的客户价值是非常明显的：在更多的业务场景中，可以帮助用户降低成本，同时也可以帮助应对更多的突发流量。另外，云计算的"使命"之一是通过统一的底层资源调度，提升资源利用率，降低资源使用成本，而该功能，在交易数据库的场景，把这个"使命"的粒度降低到了"秒"级别。用好了该功能，在很多场景中，降低50%的数据库成本应该是容易的。

[......]

Read more

去年11月，Amazon RDS推出的新的形态：Multi-AZ Cluster（三可用区三节点）。相比“原来的多AZ”（两个可用区）架构，新的Cluster模式是三节点架构，提供了更低的事务延迟，同时有更好的读扩展能力。国内的云厂商中，阿里云和腾讯云很早就有了三节点形态，一起看看，他们有哪些异同，在实际的业务场景中，哪些情况可以选择这种形态。

AWS RDS三节点（Multi-AZ Cluster）是什么？

这里将其主要特点概括如下：

• 这是一种3*AZ部署模式，而原来的Multi-AZ是2AZ部署或者单AZ部署。
• 使用了数据库的逻辑复制，而原来的双AZ使用的是EBS层的复制，这就使得Cluster的副本节点都可以直接提供读能力，有更好的读扩展能力。
• 使用了类似MySQL半同步的复制技术，事务日志网络到达其中任意一个副本主节点事务就可以提交，所以主节点上的事务延迟会降低，性能会提升（对比基于EBS的两节点）。
• 支持Graviton 2的规格和NVMe-based SSD存储，可以提供更好的性能。
• 同时支持MySQL和PostgreSQL两个引擎。

与阿里云、腾讯云数据库三节点的区别

阿里云RDS提供的“三节点企业版”，支持MySQL引擎，通过Paxos协议（或其变种）同步。相比Amazon的方案，其中一个节点使用了日志存储，成本可以更低；三个节点，只有一个节点提供服务。腾讯云MySQL也支持三节点版本，使用了半同步复制，可以选择异步、半同步或者强同步三种模式，也只有一个节点可以提供服务。

相比AWS，阿里云与腾讯云的三节点模式都可以由用户自由选择可用区分布，即可以都在一个可用区，也可以分布在两个或三个可用区，给了客户更强的灵活性。

[......]

Read more