Background note
At the invitation of a colleague, I wrote an article to record how to upgrade the powerjob-server version 3.4 to version 4.0.
First of all, let's take a look at the version change instructions and upgrade guide given in the official documents.
Version change instructions ( https://www.yuque.com/powerjob/guidence/uyf17o#lznVx )
As you can see, from version 3.xx to 4.xx of powerjob, the package name on the worker side has changed, and some fields and tables have been added to the database.
Upgrade guide ( https://www.yuque.com/powerjob/guidence/dd5hpe#lU4oI ):
Simply put, powerjob 3.xx and 4.xx are two incompatible versions. Therefore, the official recommendation is to deploy another set of powerjob-server 4.0 clusters, use a new database, and then upgrade the worker-side program codes one by one and connect to the new powerjob-server 4.0 cluster.
Of course, there are some details, including:
1) Copy the data in the original powerjob-server 3.4 database to the new database, and convert the data format. In this way, there is no need to reconfigure those timing tasks, contact information, etc., and to ensure that the data format is compatible with the new version of the server.
2) In the database, temporarily set the status of the timed task to closed. This is to prevent scheduled tasks from being scheduled repeatedly.
Of course, according to the official instructions, non-stop upgrades should be feasible. And I used in-situ shutdown to upgrade, the reasons are:
1) I currently have worker-side applications connected to powerjob, which can be shut down for maintenance and will not affect normal business operations.
2) I do not currently use powerjob on a large scale, so the number of worker-side applications that access powerjob is limited, and it is possible to upgrade these worker-side applications at once.
3) Based on the previous two reasons, if the powerjob-server side is upgraded on the spot, the operation will be much simpler than that of the non-stop upgrade solution, because there is no need to configure a new domain name for the new powerjob-serve 4.0 cluster. Using a new database does not involve temporarily shutting down timed tasks in the database.
If you have many applications that use powerjob and cannot stop the application, it is recommended to use non-stop upgrade. The operation steps are a little more troublesome, it takes a little more time, and there is nothing too difficult.
In-situ shutdown upgrade solution
Here's how to stop and upgrade to powerjob-server 4.0 and upgrade the worker application. Basically, stop all applications first, then rebuild the database, and then start the new version of the application. Here are the specific steps.
1. Stop the application
Stop all worker (client) applications first, and then stop the powerjob-server 3.4 application. In this way, no scheduled tasks in powerjob will be scheduled during the upgrade process. Since my applications are deployed in k8s, the specific operation commands are similar to the following.
Stop the client application, all client applications must be stopped:
kubectl scale deploy example-app --replicas=0 -n=prod |
Stop server application:
kubectl scale sts powerjob-server --replicas=0 -n=prod |
2. Export data
Export data from the powerjob-server library. Here only the data is exported, not the table structure. I use Workbench to operate it. I set the set-gtid-purged attribute to OFF, check the complete-insert, and then select "Dump Data Only" to start exporting. Switching to mysqldump or other tools is similar.
3. Rebuild the database
1) Delete the original powerjob-server database first.
2) Create an empty powerjob-server database, the library name remains the same as the original, and the character set is utf8mb4.
3) Import table structure: Use workbench to import the table structure of powerjob-server 4.0 version into the newly created library. This table structure is actually another powerjob-server 4.0 cluster that I deployed elsewhere, and after it runs to generate the table structure, I export its table structure and use it here.
4) Import data: Use workbench to import the data in the original library exported in step 2 into the new library.
4. Deploy powerjob-server 4.0 version
The new version of powerjob-server 4.0 can now be deployed. My side is a containerized deployment. Except for the version changed to v4.0.0, other configuration aspects, domain names, etc. are all used in the original 3.4 version, and there is no change.
5. Convert data
The operation step is to call the api interface of powerjob-server to automatically convert the data format. You need to first check the id of each application in the app_info table of the powerjob database, and then execute the following two curl commands for each id. The specific meaning is explained on the official website:
curl http://powerjob-server-address:7700/migrate/v4/job?appId=1 curl http://powerjob-server-address:7700/migrate/v4/workflow?appId=1 |
6. Deploy the client application
Finally, you can update and deploy all client applications. Of course, these client applications, which have been asked by developers to merge the new version of the code in advance, also use the new version of the worker client.