testing-04

技术细节

  • MySQL在上个月正式EOL,意味着官方不会再发布新版本去修复Bug或者安全漏洞。一般来说,云厂商对老版本支持要更就一些,那么一起来看看各个云厂商对5.7的支持情况。概述:

    • AWS:首先,AWS RDS MySQL将提供额外的、免费的半年标准支持,期间提供bug修复、漏洞修复等;2024年2月后,AWS RDS将提供付费的扩展支持。届时,如果不选择付费扩展支持的实例,将会自动(可以理解为“强制”)被升级到8.0版本,“付费”的扩展支持应该持续3年。(注:Aurora的免费支持时间会更长一些,到2024年11月)
    • 阿里云:目前,对于5.7还没有看到正式的说明。但,对于5.6版本,阿里云数据库曾发通告,将提供额外的三年维护时间。不过鉴于5.7实例体量巨大(因为8.0版本拖的时间太长),对于5.7版本支持的时间可能会更长。
    • 其他云厂商:目前都比较模糊,可以理解为不会有任何动作,用户可以正常使用。

    AWS对MySQL 5.7的支持

    AWS有Aurora MySQL 5.7(即Aurora 2.x系列)、RDS MySQL 5.7两个版本。在Oracle MySQL官方到达EOL后,AWS额外提供了半年(Aurora约一年)的免费标准支持,以及三年的付费支持。即,AWS RDS将免费支持5.7到2024年02月底,Aurora到2024年11月底;另外,还将提供三年的付费支持,约到2027年。是的,要收费的(参考)。这段时间,AWS将继续提供安全相关的Bug修复、以及重要的功能Bug修复。

    这个收费策略应该是开了云厂商对于旧版本数据库支持的先河。维护老的版本,需要额外的技术人员投入,维护一个过期的版本的投入从长时间来看,是低效的,所以,用户是需要为这部分服务付费的。

    AWS 扩展支持的收费方式与费率

    收费方式是按照vCPU * HourACU * Hour计费,不同的区域会有不同,不同的时间也会不同,离官方EOL时间越长,费用会越贵。不过,在官方版本到达EOL之后,AWS预留了4个月~一年的免费时间,让用户安排升级。以RDS MySQL 5.7为例,自2024年2月底之后,以新加坡地区为例,前两年付费扩展支持价格为 $0.12/(vCPU * Hour),第三年的费用为$0.24/(vCPU * Hour)。以一个4c16g(db.m5.xlarge)的实例计算,一个月费扩展支持费用约为$345。而该实例本身的价格约为(两节点高可用):$677 = 0.47*24*30*2。所以,AWS的策略是,价格摆在这里了,升不升级,由用户自己定夺。

    (more…)
  • 最近,Google Cloud SQL(Google云上的RDS)做了一次大的产品调整与发布:将原来的Cloud SQL分为了两个版本,分别为”Enterprise”和”Enterprise Plus”版本。本文概述了两个版本的异同,以帮助大家更好的了解Google Cloud SQL。

    关于”Enterprise”和”Enterprise Plus”版的Cloud SQL实例

    整体上:

    • Google Cloud SQL相当于AWS或阿里云平台的RDS,Cloud SQL for MySQL就相当于AWS RDS for MySQL
    • 这次调整之后,原来的Cloud SQL for MySQL/PostgreSQL全部变更为Enterprise版本,价格和产品本身没有什么改动,只是名称发生了变化
    • 新增的Enterprise Plus版本提供了更高的产品能力,例如通过硬件/软件优化提供的Data Cache能力,可以提升MySQL的读取和写入性能;Enterprise Plus还提供了更大的规格、更灵活的CPU/内存配比等能力
    • Enterprise Plus资源的价格比Enterprise版本贵约30%,Data Cache空间是额外计费的
    • 本质上,猜测,Enterprise Plus使用了更新更强的机型,具备非常强的本地存储能力(本地可能使用NVMe SSD或者其他存储设备),在数据库层则利用该能力使得用户获得更好的读与写的能力
    • 从产品发布节奏来看,今年GCP(Google云)增加了在Cloud SQL上的投入,这一点与阿里云现在应该是比较类似的。而在以前,在Google数据产品体系中,Spanner、AlloyDB或者BigTable才是投入最大的产品,而Cloud SQL似乎不受重视。现在大概发现,无论Spanner、AlloyDB架构多领先,最简单的Cloud SQL才一直都是更多用户的首选。
    • 这次更名调整,感觉是比较混乱的。对于Cloud SQL for MySQL来说,”Enterprise”和”Enterprise Plus”之间的区别还是比较明显,一个有Data Cache、另一个没有。但对于PostgreSQL来说,两者的区别更像是对资源多少的使用的一种简单限制(最大规格、cpu内存比、PITR的时间限制等)。另外,当前SQL Server又并不区分这两个类型。所以,整体给人感觉比较混乱。而像AWS Aurora新增一个I/O-Optimized选项的做法可能会更简单一点。GCP这种”化简为繁”做法,也许和业务的压力有一定的关系,更像是为了概念而做的产品决策,最终让用户对混乱的产品名称和定位买单,这种事情在大公司的企业级产品中,还是经常出现的。事情做不了什么突破,那么就在产品名称上做一些突破吧(这是一段不负责任的“臆断”,谨慎参考)。
    (more…)
  • 博客老早就长满了草,最近在锄草。

    发现问题

    最近总有人告诉我,说博客不能访问了。开始只是直接去重启一下httpd,恢复了就不管了。不过最近有点频繁出现不能访问的情况,甚至Google给我发邮件说”Increase in “404” pages on http://orczhou.com/”:

    Snip20160427_25

    于是,打算探究一下原因。 (more…)

  • Amazon RDS价格一瞥

    ·

    本文尝试通过一些直观的数据和表格,来看看Amazon某个规格的RDS实例到底是什么价格以及如何计费。

    亚马逊RDS计费分为两个主要的部分,一个是“实例费用”(CPU和内存),另一个是“存储费用”(磁盘容量和IOPS)。这两类资源的费用,又细分为单可用区和多可用区,另外,还可以选择“按小时计费”、又或者是“包年计费”的方式购买,这些对价格都有很大影响。本文分多个部分细致介绍了亚马逊如何计算一个RDS实例的价格。

    “实例费用”

    “基本规格”

    基本规格根据CPU和内存使用来划分,Amazon RDS有如下基本规格:

    Snip20150319_9 (more…)

  • 在上上周给下厨房做过一次数据恢复(故障回顾:故障发生的技术总结 致歉信),恢复使用了开源工具Percona Data Recovery Tool for InnoDB(后面简称PDRTI),这里分享一下期间的注意事项,和遇到MySQL数据丢失的一些应对。

    本文主要介绍在使用Percona Data Recovery Tool for InnoDB时候的一些注意事项,并不包括具体的step by step的使用步骤,使用文档可以参考:Reference Manual and Documentation(more…)

  • 前面以案例的形式介绍了什么是index merge,以及它的使用场景。本文将介绍index merge实现的主要数据结构以及MySQL如何评估index merge的成本。在开始本文之前,需要先理解Range访问相关的数据结构介绍:SEL_ARG结构SEL_TREE结构(more…)