-
酸甜的杨梅,我是很喜欢吃的。这些年来到浙江后,注意到这里的杨梅比其他地方更多一写。这也算是中国,或者说江南的一大特色吧,北方人大概是吃得少的。不过因为有“望梅止渴”的故事,杨梅在中国的知名度是非常高的。
根据Wikipeida的信息(参考),杨梅主要分布在中国的东南方地区、日本、菲律宾、朝鲜/韩国等地。在中国,又属浙江特别多,浙江又以仙居杨梅最为有名。
杨梅酸中带甜,非常好吃。但是,杨梅的运输是非常困难的。从树上采摘下来,最佳的食用时间也就是1~3天,再长时间由于水分的流逝,味道就没那么鲜美了。再者,因为杨梅表面非常松软,而如果运输过程稍有颠簸挤压,则非常容易压坏,影响口感,也容易变质。
所以,实际的情况就是,杨梅的上市几乎只有一个月时间,也就是说,每年只有一个月时间,也只在中国的东南方的一些城市能够吃到最好的杨梅。
鲁彦曾经下过一篇散文《故乡的杨梅》,是啊,对于浙江人,身在外地,对于杨梅的怀念,大概就是故乡味道的怀念吧。
前年底,妈妈离开了我们。当时,有几天闲在家里,我就和爸爸说,来年开春,我打算在后院种一颗杨梅树。去年,我们移植了一颗小的杨梅树,大概是因为种植的时候耽搁了几天。杨梅树没能够活下来。今年,我们又移植了一颗,这次的树更大一些,种植的时候我们也更小心,也了解了很多种植的知识,希望这颗杨梅树能够活下来,过几年能够吃上自己种的杨梅树。
对于自己,对于孩子们,也希望让故乡,多一份味道。
-
最近,使用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 = X4 删除 id 为 X 的记录
delete from sbtest where id = X5 写入 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之后,如果运行时间足够长,且是多线程并发,则几乎一定会遇到如上错误。可以考虑如下方案避免:
- 修改sysbench使用MySQL的
INSERT ... ON DUPLICATE KEY UPDATE
(参考)替换原始的INSERT
语句 - 尝试文档sysbench 1.0: teaching an old dog new tricks中使用hook尝试处理
一般来说,因为当表的记录数非常多时,遇到该类冲突的概率比较小,做如上处理并不会影响测试的“一致性”。
function sysbench.hooks.sql_error_ignorable(err) if err.sql_errno == 1062 then -- ER_DUP_ENTRY -- do nothing -- con:reconnect() return true end end
- 修改sysbench使用MySQL的
-
今天是元宵节,姑且还算是春节期间吧,做个总结和展望吧,虽然有点晚。
- 海拉鲁大陆已经被探索的差不多了,考虑新开一个游戏系列,有什么推荐的吗?《艾尔登法环》、《博德之门 3》?
- 考虑和家人们一起更多的探索中国、或者国外的一些地方
- 随着大模型的流行,以及文字内容日渐不受关注,老实说,写博客的动力越来越不足了,是不是考虑把博客转换成视频呢?
- 把云数据库性能测试持续做下去,2024年计划再测三次
- 希望把体重能够控制在130以内,这个目标非常不容易
- 拍更多的照片,家人们的,以及看到的风景的
- 祝愿TH000早日康复,挺喜欢看他的直播
- 还有几部电视剧/电影,也计划看掉:
- 三体(Netflix)、
- 庆余年2(这是一个“爽”剧)、
- 真探第四季(HBO)
- 猩球崛起4:新世界 Kingdom of the Planet of the Apes (2024),虽然前面三部,一部比一部差…
- 变形金刚:初代 Transformers One
- 和同事们一起把产品做得更好,同时也探索出可持续的、高效的商业模式
-
我们一家人一起去吃了很多次海底捞,还在那里过了一次生日,哥哥如他说所,尴尬得躲到了桌子底下。不过,吃得依旧非常的欢乐。
人生第一次去了西安,这个中国古都。是在咸阳机场落地,然后在雁塔区做了一场关于云数据库架构与选型的分享。之后,去秦岭脚下的西北工大,见到了十几年未见的研究生同学,他的生活还是和在学校时差不多,他们学校的烤鱼味道真的不错。
虽然是江西人,但是这是我们第一次去滕王阁。还有八一纪念馆没有去过、江西省博物馆也没有去过,打算春节期间再去这些地方看看
一家人一起去了黄山,虽然爬山有点累,但是都很开心。看到了传说中的迎客松、猴子观海、天都峰,黄山的松、石确实奇美,古人诚不欺我:参考
今年后院的柚子树,依旧结了很多柚子。不过,柚子树有一根非常重要支干被虫子蛀得非常厉害,老爸虽然已经把这部分清理掉了,不知道明年柚子树是否还能够保持健康。今年结的柚子,水份很足,味道很好。
这一年,经常会在梦中见到妈,妈变得话很少,总是会在远远的地方看着我。每次醒来,都很想回忆起梦中的更多细节,不过,似乎越想去记得清晰,梦中的场景却会变得越模糊。
今年,休假了一次大长假,全家一起去了一趟大西北。看到了似湖似海的青海湖,翻过了葱郁的祁连山,领略了发着金光的岗什卡雪山,经过了杳无人烟的火星公路,见证了石壁上环绕千年敦煌飞天。
终于玩上了《塞尔达传说:王国之泪》:做好了一刀入魂的斩马刀;帮助渔民赶走了海盗,重建了渔村;解决了哈特诺村传统与时尚的矛盾;运送了无数的呀哈哈;帮助搭建了无数的松达家的广告牌;从人马竞技场进货无数…… 唯独,还没有去救公主
一起去了人很多很多很多的黄鹤楼,人真的很多。不过,除了黄鹤楼,武汉还有湖北省博物馆、辛亥革命纪念馆、热干面,都不错
今年,还斥巨资购入了新的相机,佳能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 Documentation、Group 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(大部分时候为超线程)是明显不同的。
性能测试的原始数据
MySQL Performance Benchmark on Oracle Cloud@2024-01-14
data on 10.0.0.13instance 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.74instance 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.224instance 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
参考