背景说明
应同事邀请，写篇文章记录下如何将powerjob-server 3.4版本升级为4.0版本。
首先，我们先看下官方文档中给出的版本变更说明和升级指南。
可以看到，powerjob 3.x.x到4.x.x版本，主要是worker端的包名变更了、数据库增加了一些字段和表。
简单来说，powerjob 3.x.x和4.x.x是两个不兼容的版本。因此，官方的建议是，另外部署一套powerjob-server 4.0集群，使用新的数据库，再逐个升级worker端程序代码并连接到新的powerjob-server 4.0集群。
当然，其中有一些细节问题，包括：
1) 将原有powerjob-server 3.4数据库中的数据拷贝到新数据库，并进行数据格式的转换。这样就不用重新配置那些定时任务、联系人信息之类的，并且保证数据格式与新版本服务端兼容。
2) 在数据库中，临时将定时任务的状态置为关闭。这是防止定时任务被重复调度。
当然，按照官方的说明，进行不停机升级应该是可行的。而我采用的是原地停机升级，原因是：
1) 我这边目前有接入powerjob的worker端应用是可以停机维护的，并不影响正常业务的进行。
2) 我这边目前暂未大规模使用powerjob，因此接入powerjob的worker端应用的数量是有限的，一次性升级这些worker端应用是可能的。
3) 基于前面两个原因，原地停机升级powerjob-server端的话，相较于不停机升级方案来说，操作方面会简单很多，因为不用额外给新的powerjob-serve 4.0集群配置新的域名、使用新的数据库，也不涉及在数据库中临时关闭定时任务。
如果你那边有很多应用有使用powerjob，并且不能停应用，推荐还是采用不停机升级。就操作步骤上麻烦些，需要多花点时间，并没什么太难的地方。
原地停机升级方案
下面介绍下我这边如何原地停机升级到powerjob-server 4.0版本和升级worker端应用。基本就是，先停掉所有应用，再重建数据库，再启动新版本应用。下面是具体步骤。
1、停应用
先停所有worker端(即客户端)应用，再停powerjob-server 3.4应用。这样，升级过程中都不会有powerjob中的定时任务被调度。由于我这边应用程序都部署在k8s中，因此具体的操作命令类似下面这样。
停客户端应用，所有客户端应用都要停掉：
kubectl scale deploy example-app --replicas=0 -n=prod |
停server端应用：
kubectl scale sts powerjob-server --replicas=0 -n=prod |
2、导出数据
从powerjob-server库中导出数据。这里只导出数据，不导出表结构。我这边是使用Workbench来操作的，就将set-gtid-purged属性设为OFF，勾选上complete-insert，再选择"Dump Data Only"，就可以开始导出了。换成使用mysqldump或其它工具也是差不多的。
3、重建数据库
1) 先删除原有的powerjob-server的数据库。
2) 再创建一个空的powerjob-server的数据库，库名保持跟原有的相同，字符集为utf8mb4。
3) 导入表结构：使用workbench将powerjob-server 4.0版本的表结构导入到新创建的库中。这个表结构其实是我在其它地方另外部署一个powerjob-server 4.0集群，等它运行起来生成表结构后，再把它的表结构导出来拿到这里使用的。
4) 导入数据：使用workbench将第2步中导出的原库中的数据导入到新库中。
4、部署powerjob-server 4.0版本
现在就可以部署新的powerjob-server 4.0版本了。我这边是容器化部署，除了版本改成v4.0.0外，其它配置方面、域名等都是沿用原来3.4版本的，没有变化。
5、转换数据
该操作步骤，就是调用powerjob-server的api接口，让它自动进行数据格式转换。你需要先查一下powerjob数据库的app_info表中各个应用的id是什么，然后针对每一个id都执行下面两条curl命令，具体含义的话官网中有说明：
curl http://powerjob-server-address:7700/migrate/v4/job?appId=1 curl http://powerjob-server-address:7700/migrate/v4/workflow?appId=1 |
6、部署客户端应用
最后，就可以更新部署所有客户端应用程序啦。当然，这些客户端应用程序，事先已经让开发人员将新版本的代码合并好了的，也是采用新版本的worker客户端的。