背景メモ
同僚の招待で、powerjob-serverバージョン3.4をバージョン4.0にアップグレードする方法を記録する記事を書きました。
まず、公式ドキュメントに記載されているバージョン変更手順とアップグレードガイドを見てみましょう。
ご覧のとおり、powerjobのバージョン3.xxから4.xxに、ワーカー側のパッケージ名が変更され、いくつかのフィールドとテーブルがデータベースに追加されました。
アップグレードガイド（https://www.yuque.com/powerjob/guidence/dd5hpe#lU4oI）：
簡単に言えば、powerjob3.xxと4.xxは2つの互換性のないバージョンです。したがって、公式の推奨事項は、別のpowerjob-server 4.0クラスターのセットをデプロイし、新しいデータベースを使用してから、ワーカー側のプログラムコードを1つずつアップグレードして、新しいpowerjob-server4.0クラスターに接続することです。
もちろん、次のような詳細があります。
1）元のpowerjob-server 3.4データベースのデータを新しいデータベースにコピーし、データ形式を変換します。このように、これらのタイミングタスク、連絡先情報などを再構成する必要はなく、データ形式がサーバーの新しいバージョンと互換性があることを確認する必要はありません。
2）データベースで、時間指定タスクのステータスを一時的にクローズに設定します。これは、スケジュールされたタスクが繰り返しスケジュールされないようにするためです。
もちろん、公式の指示によれば、ノンストップのアップグレードは実行可能であるはずです。そして、アップグレードにin-situシャットダウンを使用しました。理由は次のとおりです。
1）現在、powerjobに接続されているワーカー側のアプリケーションがあります。これは、メンテナンスのためにシャットダウンでき、通常の業務には影響しません。
2）現在、powerjobを大規模に使用していないため、powerjobにアクセスするワーカー側アプリケーションの数が限られており、これらのワーカー側アプリケーションを一度にアップグレードすることができます。
3）前の2つの理由に基づいて、powerjob-server側をその場でアップグレードすると、新しいドメイン名を構成する必要がないため、操作はノンストップアップグレードソリューションよりもはるかに簡単になります。新しいデータベースでは、データベース内の時間指定されたタスクを一時的にシャットダウンする必要はありません。
powerjobを使用するアプリケーションが多数あり、アプリケーションを停止できない場合は、ノンストップアップグレードを使用することをお勧めします。操作手順はもう少し面倒で、もう少し時間がかかり、それほど難しいことはありません。
その場シャットダウンアップグレードソリューション
powerjob-server 4.0を停止してアップグレードし、ワーカーアプリケーションをアップグレードする方法は次のとおりです。基本的に、最初にすべてのアプリケーションを停止し、次にデータベースを再構築してから、新しいバージョンのアプリケーションを起動します。具体的な手順は次のとおりです。
1.アプリケーションを停止します
最初にすべてのワーカー（クライアント）アプリケーションを停止してから、powerjob-server3.4アプリケーションを停止します。このように、powerjobでスケジュールされたタスクは、アップグレードプロセス中にスケジュールされません。私のアプリケーションはk8sでデプロイされているため、特定の操作コマンドは次のようになります。
クライアントアプリケーションを停止します。すべてのクライアントアプリケーションを停止する必要があります。
kubectl scale deploy example-app --replicas = 0 -n = prod |
サーバーアプリケーションを停止します。
kubectl scale sts powerjob-server --replicas = 0 -n = prod |
2.データをエクスポートします
powerjob-serverライブラリからデータをエクスポートします。ここでは、テーブル構造ではなく、データのみがエクスポートされます。Workbenchを使用して操作し、set-gtid-purged属性をOFFに設定し、complete-insertを確認してから、「DumpDataOnly」を選択してエクスポートを開始します。mysqldumpまたは他のツールへの切り替えも同様です。
3.データベースを再構築します
1）最初に元のpowerjob-serverデータベースを削除します。
2）空のpowerjob-serverデータベースを作成します。ライブラリ名は元の名前と同じで、文字セットはutf8mb4です。
3）テーブル構造のインポート：ワークベンチを使用して、powerjob-server4.0バージョンのテーブル構造を新しく作成されたライブラリにインポートします。このテーブル構造は、実際には他の場所にデプロイした別のpowerjob-server 4.0クラスターであり、実行してテーブル構造を生成した後、そのテーブル構造をエクスポートしてここで使用します。
4）データのインポート：ワークベンチを使用して、手順2でエクスポートした元のライブラリのデータを新しいライブラリにインポートします。
4. powerjob-server4.0バージョンをデプロイします
これで、新しいバージョンのpowerjob-server4.0をデプロイできます。私の側はコンテナ化されたデプロイメントです。v4.0.0に変更されたバージョンを除いて、他の構成の側面、ドメイン名などはすべて元の3.4バージョンで使用され、変更はありません。
5.データを変換します
操作手順は、powerjob-serverのapiインターフェースを呼び出して、データ形式を自動的に変換することです。powerjobデータベースのapp_infoテーブルで各アプリケーションのIDを確認してから、IDごとに次の2つのcurlコマンドを実行する必要があります。具体的な意味は公式ウェブサイトで説明されています。
curl http：// powerjob-server-address：7700 / migrate / v4 / job？appId = 1 curl http：// powerjob-server-address：7700 / migrate / v4 / Workflow？appId = 1 |
6.クライアントアプリケーションをデプロイします
最後に、すべてのクライアントアプリケーションを更新してデプロイできます。もちろん、開発者から事前に新しいバージョンのコードをマージするように求められたこれらのクライアントアプリケーションも、新しいバージョンのワーカークライアントを使用します。