• 杨梅树

    酸甜的杨梅,我是很喜欢吃的。这些年来到浙江后,注意到这里的杨梅比其他地方更多一写。这也算是中国,或者说江南的一大特色吧,北方人大概是吃得少的。不过因为有“望梅止渴”的故事,杨梅在中国的知名度是非常高的。

    根据Wikipeida的信息(参考),杨梅主要分布在中国的东南方地区、日本、菲律宾、朝鲜/韩国等地。在中国,又属浙江特别多,浙江又以仙居杨梅最为有名。

    杨梅酸中带甜,非常好吃。但是,杨梅的运输是非常困难的。从树上采摘下来,最佳的食用时间也就是1~3天,再长时间由于水分的流逝,味道就没那么鲜美了。再者,因为杨梅表面非常松软,而如果运输过程稍有颠簸挤压,则非常容易压坏,影响口感,也容易变质。

    所以,实际的情况就是,杨梅的上市几乎只有一个月时间,也就是说,每年只有一个月时间,也只在中国的东南方的一些城市能够吃到最好的杨梅。

    鲁彦曾经下过一篇散文《故乡的杨梅》,是啊,对于浙江人,身在外地,对于杨梅的怀念,大概就是故乡味道的怀念吧。

    前年底,妈妈离开了我们。当时,有几天闲在家里,我就和爸爸说,来年开春,我打算在后院种一颗杨梅树。去年,我们移植了一颗小的杨梅树,大概是因为种植的时候耽搁了几天。杨梅树没能够活下来。今年,我们又移植了一颗,这次的树更大一些,种植的时候我们也更小心,也了解了很多种植的知识,希望这颗杨梅树能够活下来,过几年能够吃上自己种的杨梅树。

    对于自己,对于孩子们,也希望让故乡,多一份味道。

    2022年,团队outing,在仙居的山上摘杨梅
    后院新种的杨梅树@共青城

  • 最近,使用sysbench测试时,尝试使用参数--skip_trx=on,很快在实际的测试中就遇到了Duplicate entry的报错,详细的报错如下:

    [ 105s ] thds: 64 tps: 845.68 qps: 15226.20 (r/w/o: 11833.15/3393.04/0.00) lat (ms,95%): 82.96 err/s: 0.00 reconn/s: 0.00
    [ 108s ] thds: 64 tps: 828.65 qps: 14846.32 (r/w/o: 11547.73/3298.59/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
    [ 111s ] thds: 64 tps: 811.67 qps: 14705.36 (r/w/o: 11439.69/3265.67/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
    FATAL: mysql_drv_query() returned error 1062 (Duplicate entry '172978' for key 'sbtest4.PRIMARY') for query 'INSERT INTO sbtest4 (id, k, c, pad) V
    ALUES (172978, 743044, '85734897298-37760631172-31656179599-77290009462-94351507893-97022333300-02606364258-99231394161-86310536236-00514105136',
    '50908340877-51595671823-98046322819-52667567569-56801127593')'
    FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:488: SQL error, errno = 1062, state = '23000': Duplicate entry '172978' f
    or key 'sbtest4.PRIMARY'

    也注意到,这个错误的出现有一定的偶发性,但是高并发、长时间压测几乎一定会遇到了(在开启了--skip_trx=on参数后)。因为Sysbench没有对”Duplicate entry”该错误进行处理,测试会退出,也就无法正常完成测试。

    原因分析

    当多个线程并发时,同时没有使用--skip_trx=on,而是使用MySQL默认的auto commit模式,那么在oltp_read_write模型下则一定的概率(小概率)会出现如下的场景:

    时间线线程A线程B
    1生成随机ID X
    2生成随机ID X
    3删除 id 为 X 的记录
    delete from sbtest where id = X
    4删除 id 为 X 的记录
    delete from sbtest where id = X
    5写入 id 为 X 的记录
    insert into sbtest (id…) values ( X …)
    6写入 id 为 X 的记录
    insert into sbtest (id…) values ( X …)

    在上面的场景下,最后一步,线程B再次写入id 为 X 的记录时,则会出现冲突。

    一般来说,即便发生如上情况,也不会出现Duplicate entry的报错。但,组合一些情况,则会出现。例如,在这里,我们使用了--skip_trx=on,那么线程A的如上行为不是在一个事务中,每个操作是一个独立的事务,那么就会出现Duplicate entry报错。

    如果没有使用--skip_trx=on参数,那么在线程2尝试删除记录时,则会遇到锁等待,直到线程1的相关操作全部完成。也就不会出现报错。

    避免该错误

    在开启了–skip_trx=on之后,如果运行时间足够长,且是多线程并发,则几乎一定会遇到如上错误。可以考虑如下方案避免:

    一般来说,因为当表的记录数非常多时,遇到该类冲突的概率比较小,做如上处理并不会影响测试的“一致性”。

    function sysbench.hooks.sql_error_ignorable(err)
      if err.sql_errno == 1062 then -- ER_DUP_ENTRY
        -- do nothing
        -- con:reconnect()
        return true
      end
    end

  • 2024年的期待

    今天是元宵节,姑且还算是春节期间吧,做个总结和展望吧,虽然有点晚。

    • 海拉鲁大陆已经被探索的差不多了,考虑新开一个游戏系列,有什么推荐的吗?《艾尔登法环》、《博德之门 3》?
    • 考虑和家人们一起更多的探索中国、或者国外的一些地方
    • 随着大模型的流行,以及文字内容日渐不受关注,老实说,写博客的动力越来越不足了,是不是考虑把博客转换成视频呢?
    • 把云数据库性能测试持续做下去,2024年计划再测三次
    • 希望把体重能够控制在130以内,这个目标非常不容易
    • 拍更多的照片,家人们的,以及看到的风景的
    • 祝愿TH000早日康复,挺喜欢看他的直播
    • 还有几部电视剧/电影,也计划看掉:
      • 三体(Netflix)、
      • 庆余年2(这是一个“爽”剧)、
      • 真探第四季(HBO)
      • 猩球崛起4:新世界 Kingdom of the Planet of the Apes (2024),虽然前面三部,一部比一部差…
      • 变形金刚:初代 Transformers One
    • 和同事们一起把产品做得更好,同时也探索出可持续的、高效的商业模式

  • 过去的2023年

    我们一家人一起去吃了很多次海底捞,还在那里过了一次生日,哥哥如他说所,尴尬得躲到了桌子底下。不过,吃得依旧非常的欢乐。

    人生第一次去了西安,这个中国古都。是在咸阳机场落地,然后在雁塔区做了一场关于云数据库架构与选型的分享。之后,去秦岭脚下的西北工大,见到了十几年未见的研究生同学,他的生活还是和在学校时差不多,他们学校的烤鱼味道真的不错。

    虽然是江西人,但是这是我们第一次去滕王阁。还有八一纪念馆没有去过、江西省博物馆也没有去过,打算春节期间再去这些地方看看

    一家人一起去了黄山,虽然爬山有点累,但是都很开心。看到了传说中的迎客松、猴子观海、天都峰,黄山的松、石确实奇美,古人诚不欺我:参考

    今年后院的柚子树,依旧结了很多柚子。不过,柚子树有一根非常重要支干被虫子蛀得非常厉害,老爸虽然已经把这部分清理掉了,不知道明年柚子树是否还能够保持健康。今年结的柚子,水份很足,味道很好。

    这一年,经常会在梦中见到妈,妈变得话很少,总是会在远远的地方看着我。每次醒来,都很想回忆起梦中的更多细节,不过,似乎越想去记得清晰,梦中的场景却会变得越模糊。

    爸妈年轻时候的样子

    今年,休假了一次大长假,全家一起去了一趟大西北。看到了似湖似海的青海湖,翻过了葱郁的祁连山,领略了发着金光的岗什卡雪山,经过了杳无人烟的火星公路,见证了石壁上环绕千年敦煌飞天。

    终于玩上了《塞尔达传说:王国之泪》:做好了一刀入魂的斩马刀;帮助渔民赶走了海盗,重建了渔村;解决了哈特诺村传统与时尚的矛盾;运送了无数的呀哈哈;帮助搭建了无数的松达家的广告牌;从人马竞技场进货无数…… 唯独,还没有去救公主

    一起去了人很多很多很多的黄鹤楼,人真的很多。不过,除了黄鹤楼,武汉还有湖北省博物馆、辛亥革命纪念馆、热干面,都不错

    今年,还斥巨资购入了新的相机,佳能R8+RF24-70/F2.8。给拍了很多照片,有家人们、有去过的景点、也有日常生活的记录。右边这张照片,曾被西湖文旅的公众号选中,作为图书馆的宣传照片。哦,今年还去了十次图书馆,希望明年能够去得更多。

    元旦,我们还去了上海。去看了四姨家的小宝宝,去了上海天文馆、航海博物馆。

    公司的业务,有顺利的一面,也有很有挑战的一面。整体的环境比较困难,内力与招式需要双修,才能适应复杂的外部环境。

    今年做了第一次云数据库性能测试,算是给自己挖了一个大坑,希望后续能够持续关注云数据库发展,持续的进行性能测试。

    多年的老同事从澳洲回杭州,借机会也把附近的原淘宝DBA的同事聚了起来,多年不见,再次相聚,非常开心

  • 在MySQL社区的帮助下,终于成功开通了Oracle Cloud,于是,第一时间测试了一下在Oracle Cloud上托管MySQL,看看Oracle MySQL原厂的性能表现如何。

    关注我朋友圈的应该知道,在国内自助的注册Oracle Cloud真的非常不容易。所以,特别感谢Oracle MySQL原厂工程师徐轶韬的帮助,他也是《MySQL高可用解决方案-从主从复制到InnoDB Cluster架构》的作者,他的公众号是“MySQL解决方案工程师”,感兴趣可以关注他的公众号。

    回到正文,Oracle Cloud的全称是”Oracle Cloud Infrastructure”,也经常被简称为”OCI”。在OCI上提供的MySQL服务,相较于AWS、阿里云来说,产品形态也比较简单。首先,托管MySQL在分类“Databases->MySQL HeatWave->DB Systems”这个类目下,在实例创建过程中,涉及的选项不算多,但是因为名词/定义与其他云厂商有一些不同,所以这里做一些解释。Oracle Cloud上的托管MySQL主要选项为:

    • 高可用类型(单节点/standalone、三节点/HA)
    • 规格大小
    • 主可用区选择
    • 空间大小(IOPS/吞吐量与此相关)

    在本次测试中,一共进行了三组测试。规格大小统一为:2 OCPU(Oracle CPU)32GB,100GB存储(对应的7500 IOPS),规格代码为MySQL.VM.Standard.E4.2.32GB。三组测试对比项分别为:单节点 vs 三节点和同可用区 vs 跨可用区。三组测试具体为:跨可用区的三节点测试、同可用区的三节点测试、同可用区的单节点测试。详细参数表如下:

    整体性能趋势图

    整体上,OCI上的MySQL高可用版本(MGR三节点)性能要比单节点低约20%。在三节点的两次测试下,跨可用区与同可用区有着几乎相同的性能表现,从延迟上来看,也非常接近,可用区之间的延迟约为百微秒级别。

    相比于其他云厂商,OCI上的MySQL性能表现,并不算高的。从架构层面,Oracle MySQL是唯一一个选择了MGR来实现高可用、跨可用区数据一致性的。

    OCI上的区域与可用区

    在MySQL的实例创建过程中,会有一些诸如:AD、FD(Fault Domins)等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念,Oracle Cloud与其他云厂商虽然都是相同的概念,但是用了完全不同的名称,也是非常容易让人困惑的。

    在Oracle中,分了几层概念:Region->Availability Domains->Fault Domains。

    • Region与其他云厂商区域概念相同;
    • Fault Domains则与其他云厂商的“可用区”对应;
    • 在OCI中,通常三个为一组的Fault Domains会组成一个“Availability Domains”。大部分的Oracle Region中只有一个Availability Domains,也有部分region有3个Availability Domains(参考),所以在MySQL的配置选项中会有AD、FD等缩写词语。

    Oracle Cloud上MySQL实例的数据可靠性架构

    OCI上的MySQL使用的MGR来实现高可用、高可靠(参考:High Availability@Oracle Cloud Infrastructure DocumentationGroup Replication@MySQL Documentation)。三个不同的MySQL节点分布在三个不同的FD,每个节点使用的存储是OCI上的Block Volume(参考),以iSCSI方式使用,类型是“Higher Performance”(此外,还有Balanced、Ultra High Performance、Lower Cost三种Block Volume)。

    根据参数配置来看,Oracle Cloud提供的MySQL三节点是通过MGR实现的,使用的是group_replication_single_primary_mode模式。

    mysql> show variables like '%group_replication_single_primary_mode%';
    +---------------------------------------+-------+
    | Variable_name                         | Value |
    +---------------------------------------+-------+
    | group_replication_single_primary_mode | ON    |
    +---------------------------------------+-------+
    1 row in set (0.00 sec)

    其他说明

    • Oracle Cloud的MySQL没有提供两节点选项
    • 产品规格,Oracle Cloud使用的是OCPUs(Oracle CPU,可以理解为core),详细参考:vCPU and OCPU pricing information。相比于其他云厂商的vCPU(大部分时候为超线程)是明显不同的。

    性能测试的原始数据

    oracle@2024-01-14 Cloud MySQL Performance Testing
    data on 10.0.0.13
    instance configuration
    host : 10.0.0.13 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : ha 
    same_az : 1 
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.13
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|       95033| 1900660|300.01|       6.31|       7.56 
          4|      148751| 2975020|300.01|       8.07|      10.27 
          8|      214974| 4299480|300.01|      11.16|      13.70 
         16|      262105| 5242100|300.01|      18.31|      30.81 
         24|      253583| 5071660|300.03|      28.39|      47.47 
         32|      272755| 5455100|300.03|      35.20|      54.83 
         48|      269370| 5387400|300.04|      53.46|      77.19 
         64|      286891| 5737820|300.06|      66.93|     102.97 
         96|      276749| 5534980|300.12|     104.08|     161.51 
        128|      287452| 5749040|300.13|     133.61|     183.21 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    data on 10.0.0.74
    instance configuration
    host : 10.0.0.74 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : ha 
    same_az :  
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.74
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|       90638| 1812760|300.01|       6.62|       7.84 
          4|      147270| 2945400|300.01|       8.15|      10.09 
          8|      215078| 4301560|300.01|      11.16|      13.70 
         16|      242713| 4854260|300.02|      19.78|      33.72 
         24|      260072| 5201440|300.02|      27.68|      45.79 
         32|      273703| 5474060|300.03|      35.07|      56.84 
         48|      283811| 5676220|300.06|      50.74|      73.13 
         64|      287176| 5743520|300.06|      66.86|     102.97 
         96|      283113| 5662260|300.09|     101.74|     158.63 
        128|      285210| 5704200|300.12|     134.66|     189.93 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    data on 10.0.0.224
    instance configuration
    host : 10.0.0.224 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : standalone 
    same_az : 1 
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.224
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|      102033| 2040660|300.00|       5.88|       7.56 
          4|      186602| 3732040|300.01|       6.43|       8.90 
          8|      281464| 5629280|300.01|       8.53|      12.30 
         16|      333418| 6668360|300.02|      14.40|      31.94 
         24|      345463| 6909260|300.02|      20.84|      47.47 
         32|      359902| 7198040|300.03|      26.67|      56.84 
         48|      353246| 7064920|300.06|      40.77|      78.60 
         64|      370118| 7402360|300.07|      51.88|      99.33 
         96|      380647| 7612940|300.09|      75.67|     134.90 
        128|      372683| 7453660|300.12|     103.05|     164.45 
        192|           0|       0|  0.00|       0.00|       0.00 
    

    参考

    1. High Availability@Oracle Cloud Infrastructure Documentation
    2. Group Replication@MySQL Documentation
    3. vCPU and OCPU pricing information

  • 最近,在ACMUG(中国MySQL用户组)的年度活动中,较为详细对之前的云数据库 RDS MySQL性能测试做了分享。如下为分享的PDF,供参考:

    (more…)