このドキュメントでは、アップグレードに必要なRPMパッケージをアップロードする方法について説明します。
呼び出しの説明
インターフェース制約
obshell ServerはこのAPIに対してセキュリティ検証を実施します。詳細については、APIハイブリッド暗号化を参照してください。
リクエストパス
POST /api/v1/upgrade/package
リクエストタイプ
multipart/form-data
リクエストパラメータ
パラメータ |
タイプ |
必須 |
サンプル値 |
説明 |
|---|---|---|---|---|
| file | file | はい | なし | アップロードするRPMパッケージを指定します |
戻り値
パラメータ |
タイプ |
説明 |
|---|---|---|
| successful | bool | リクエストが成功したかどうかを示します。 |
| timestamp | time.Time | サーバーがリクエストを完了したタイムスタンプです。 |
| duration | int | サーバーがリクエストを処理した時間(ミリ秒)です。 |
| status | int | HTTP Status仕様に準拠したエンコードです。 |
| traceId | string | リクエストのTrace IDです。 |
| data | UpgradePkgInfo | 詳細については、以下のUpgradePkgInfo情報のデータ構造を参照してください。 |
| error | ApiError | リクエストで発生したErrorで、以下の情報を含みます:
|
UpgradePkgInfo情報のデータ構造:
パラメータ |
タイプ |
説明 |
|---|---|---|
| pkgId | int | ソフトウェアパッケージID |
| name | string | ソフトウェアパッケージ名 |
| version | string | ソフトウェアパッケージバージョン |
| releaseDistribution | string | ソフトウェアパッケージのリリースビルド番号 |
| distribution | string | ソフトウェアパッケージのリリース |
| release | string | ソフトウェアパッケージのビルド番号 |
| architecture | string | ソフトウェアパッケージのアーキテクチャ |
| Size | int | パッケージの解凍サイズ(バイト単位) |
| PayloadSize | int | パッケージサイズ(バイト単位) |
| ChunkCount | int | パッケージのチャンク数 |
| Md5 | string | パッケージのMD5 |
| UpgradeDepYaml | string | パッケージのアップグレードパスファイル |
| GmtModify | time.Time | パッケージの変更日時 |
例
リクエスト例
-F "file=@/home/rpmbuild/RPMS/x86_64/oceanbase-ce-4.2.1.1-101000062023110109.el7.x86_64.rpm"
/api/v1/upgrade/package
レスポンス例
{
"successful": true,
"timestamp": "2024-01-09T16:55:58.153159003+08:00",
"duration": 68288,
"status": 200,
"traceId": "42464438789e774e",
"data": {
"PkgId": 1,
"Name": "oceanbase-ce",
"Version": "4.2.1.1",
"ReleaseDistribution": "101000062023110109.el7",
"Distribution": "el7",
"Release": "101000062023110109",
"Architecture": "x86_64",
"Size": 433648329,
"PayloadSize": 96547244,
"ChunkCount": 6,
"Md5": "550d75397013d00ca0a8e529d17020c3",
"UpgradeDepYaml": "# 各OceanBaseバージョンのアップグレード依存関係を記述します\n# 参考ドキュメント release/ptw5y7\n\n# 公式リリースされた各OBバージョンについて、以下のyamlファイルに1項目追加し、以下のプロパティを含めます:\n# * version: アップグレードするバージョン、またはアップグレード中に経由するバージョン。通常はA.B.Cのバージョン番号を使用します。A.B.C-Dの形式の場合、ビルド番号はD以上である必要があります\n# * can_be_upgraded_to: そのバージョンがOB QA互換性テストを通過し、*直接*アップグレードできるOBバージョン番号です。複数のバージョンを含むリストとして指定できます\n# * deprecated: デフォルトはFalseです。Trueの場合、このバージョンは廃止されています。これを\n# アップグレードの出発点や移行バージョンとして使用できますが、アップグレードのターゲットバージョンとしては使用できません。\n# * require_from_binary: デフォルトはFalseです。Trueの場合、アップグレード中に中間バージョンとして使用する場合、upgradeスクリプトを実行するだけでなく、observerもそのバージョンにアップグレードする必要があります\n#\n\n# OCPのOBアップグレードモジュールはこのファイルを読み取り、指定されたアップグレードの開始バージョンとターゲットバージョンに基づいて、上記の制約を満たす最短のアップグレードパスを自動的に検索します。基本的なアルゴリズムは次のとおりです:\n# 以下の説明に基づいてグラフを構築します。各バージョンを1つのノードとし、can_be_upgraded_to関係で\n# 1本のエッジを定義します。開始バージョンとアップグレードターゲットバージョンの間の最短パスを探索します。開始点以外のノードは\n# deprecatedであってはなりません。A.B.CとA.B.C-Dの2種類のノードがマッチする場合、後者を優先的に選択します。\n#\n\n- version: 4.0.0.0\n can_be_upgraded_to:\n - 4.1.0.0\n\n# 4.1.0.x is barrier\n- version: 4.1.0.0-100000192023032010 # 4.1 BETA版はターゲットバージョンとして使用できません\n can_be_upgraded_to:\n - 4.1.0.0\n deprecated: True\n\n- version: 4.1.0.0\n can_be_upgraded_to:\n - 4.1.0.1\n\n- version: 4.1.0.1\n can_be_upgraded_to:\n - 4.1.0.2\n\n- version: 4.1.0.2\n can_be_upgraded_to:\n - 4.2.0.0\n require_from_binary:\n value: True\n when_come_from: [4.0.0.0, 4.1.0.0-100000192023032010]\n\n- version: 4.2.0.0-100000152023080109 # 4.2 RC2版はターゲットバージョンとして使用できません\n can_be_upgraded_to:\n - 4.2.0.0\n deprecated: True\n\n- version: 4.2.0.0-100010022023081817 # 4.2 RC2 hotfix版はターゲットバージョンとして使用できません\n can_be_upgraded_to:\n - 4.2.0.0\n deprecated: True\n\n- version: 4.2.0.0\n can_be_upgraded_to:\n - 4.2.1.0\n\n# 4.2.1.x is barrier\n- version: 4.2.1.0\n can_be_upgraded_to:\n - 4.2.1.1\n\n- version: 4.2.1.1\n can_be_upgraded_to:\n - 4.3.0.0\n require_from_binary:\n value: True\n when_come_from: [4.1.0.0, 4.1.0.1, 4.1.0.2, 4.2.0.0]\n",
"GmtModify": "0001-01-01T00:00:00Z"
}
}
関連ドキュメント
コマンドラインでAPIを呼び出すほかに、SDKメソッドを使用してAPIを呼び出すこともできます。
obshell-sdk-pythonを使用したAPIメソッドの呼び出し方法については、RPMパッケージのアップロードを参照してください。
obshell-sdk-goを使用したAPIメソッドの呼び出し方法については、RPMパッケージのアップロードを参照してください。