このドキュメントでは、アップグレードに必要な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ステータスコード仕様に準拠したエンコードです。 |
| 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ファイルに項目を追加します。必須プロパティは以下の通りです:\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関係で1本のエッジを定義します。開始バージョンとアップグレードターゲットバージョン間の最短パスを探索します。開始点以外のノードは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パッケージのアップロードを参照してください。