dreamflyly的博客

接上篇，增加线程池后解决了线程数瓶颈，可以继续提升warehouse数来调优提分。编译优化也是个很重要且有效的性能优化方法，通用的编译时优化O3基本都做了，所以我主要使用了链接时优化和运行时优化这两种“比较少见”的编译优化方法，其实我之前也没有接触过，也是在参赛过程中现学现做的。

接上篇，完成参数调优后，warehouse数提升到了1600，此时遇到了性能瓶颈。当warehouse超过1600时，TPCC压测时会报错：Benchmark Not Active for 10 seconds，为什么呢？这时候我们就需要分析一下数据库的线程调度方法。

今年由于阿里承办了全国大学生计算机系统能力大赛PolarDB数据库创新设计赛，本以为数据库大赛会取消，直到十一左右比赛才姗姗来迟，所以赛程较往年缩短了一个月左右，初赛和复赛都只有一个月时间，时间很紧，加之到了年底工作又比较忙，初赛的参数调优环节成绩并不理想，所以对复赛也没抱多大希望，但是进入复赛之后发现复赛跟初赛完全不同，一开始的时候成绩还不错，就又开始了熬夜模式，进程也是比较顺利，最终拿到了第5的名次，比去年又进步了几名。

使用mysql数据库的时候不小心误删除了ibdata和ib_logfile文件，但是幸好.ibd文件还在。查询表数据时会报错：ERROR 1146 (42S02): Table ‘testdb.test’ doesn’t exist，其实是说表结构不存在

上篇我们主要研究了把server和mysql部署成两个服务的情况，但是我们没有考虑mysql的冗余机制，如果mysql的pod挂掉了，K8S会重新拉起它，但是这期间业务会中断。本篇我们将讨论一下如何解决这个问题。

上篇我们研究了server和mysql两个容器部署在同一个pod中的情况，但是这不符合K8S的设计原则–解耦，而且在这种情况下也不容易实现server的负载均衡。所以本篇我们研究把server和mysql部署成两个服务，这应该是实际应用中比较通用的做法。

前几篇文章重点是研究mysql的持久化和多POD部署，所以为了便于研究都是采用手工方式来创建mysql的数据库表。显然这不符合实际情况，今天我们就重点来研究一下POD启动的时候自动调用初始化脚本创建数据库表。

在实际的业务场景中，很多业务需要用到数据库。从本文开始，我们将以server+mysql的方式来探索一下在K8S中如何部署业务+数据库的使用场景。首先我们研究一下server和mysql两个容器部署在同一个POD中的情况。

去年抱着打酱油的心态参加了第四届数据库比赛，幸运的获取了优胜奖，所以今年一直在等着第五届比赛。谁知比赛开始后却因为时间冲突，初赛几乎没打，复赛也是开始半个月之后才开始打，一路追赶，最终排名第8，比去年进步了一点点。

初赛幸运的获得第10名进入复赛，复赛目标是出分（600秒以内），但是复赛的难度远远大于初赛，分布式集群、8亿数据量，一座座大山横亘面前，出分遥遥无期。解题过程可谓历尽艰辛，在其它参赛队伍都非常卷的刺激下日夜鏖战，拼尽全力，最终复赛成绩256秒，又是第10，如此巧合，压线进入决赛答辩。总结起来，在整个解题过程中学习到了不少新知识，收获良多，也取得了参赛之初不敢想的成绩。比赛结束后看到其它队伍分享的技术实现方案，发现自己的方案还是有很多不足之处，也学到不少新的思路与方法(比如页高缓等，让我眼界大开)。

一个偶然的机会，在阿里云天池大赛上看到“第四届全球数据库大赛赛道2：分布式NewSQL性能挑战”，抱着玩一玩的心态就报名了。初赛目标50秒以内，由于之前并未接触过持久化内存，初赛主要是通过《持久内存快速编程手册》，边学习边实践，不断优化。不曾想初赛成绩居然10.45秒，位列第10名，超出预期。初赛主要考察持久化和哈希表，取得成绩的关键是细节处理，特别是AEP内存预写。