知財求人 - 知財ポータルサイト「IP Force」
▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
特許7389104データベースの第１のバージョンから第２のバージョンへのアップグレード
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-20
(45)【発行日】2023-11-29
(54)【発明の名称】データベースの第１のバージョンから第２のバージョンへのアップグレード
(51)【国際特許分類】
G06F 16/215 20190101AFI20231121BHJP
【ＦＩ】
G06F16/215
【請求項の数】
16
(21)【出願番号】P 2021505382
(86)(22)【出願日】2019-09-24
(65)【公表番号】
(43)【公表日】2022-01-06
(86)【国際出願番号】 US2019052614
(87)【国際公開番号】W WO2020068760
(87)【国際公開日】2020-04-02
【審査請求日】2022-09-13
(31)【優先権主張番号】16/140,498
(32)【優先日】2018-09-24
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】506332063
【氏名又は名称】セールスフォース インコーポレイテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】タン シャオイ
(72)【発明者】
【氏名】リウ，チャオクン
(72)【発明者】
【氏名】プラブハカール，プラシャスティ
(72)【発明者】
【氏名】リーラウ，サージ
(72)【発明者】
【氏名】コーエン，ジェフ
(72)【発明者】
【氏名】ギャロウェイ，ジョン
(72)【発明者】
【氏名】シンガムシェッティ，モハン
【審査官】甲斐 哲雄
(56)【参考文献】
【文献】特開平０９－２４４９３０（ＪＰ，Ａ）
【文献】国際公開第２００５／０２９３３２（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１８／０００４７９２（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／１０－１６／２９
(57)【特許請求の範囲】
【請求項1】
データベースを第１のバージョンから第２のバージョンにアップグレードする方法であって、第１のプロセッサにより、前記データベースのデータベース管理システムの第１のバージョンを動作させるステップと、
第２のプロセッサにより、前記データベースの前記データベース管理システムの第２のバージョンを動作させるステップと、
前記第２のプロセッサにより、前記第１のプロセッサから、データベースアプリケーションスキーマのコピーを受け取るステップと、
前記第２のプロセッサにより、前記データベース管理システムの前記第２のバージョンと前記データベースアプリケーションスキーマの前記コピーとを使用し、前記データベース管理システムの前記第２のバージョンのためのデータベースカタログのオリジナルバージョンを生成するステップと、
前記第１のプロセッサにより、前記第２のプロセッサから、前記データベース管理システムの前記第２のバージョンのための前記データベースカタログの前記オリジナルバージョンのコピーを受け取るステップと、
前記第１のプロセッサにより、前記データベースのアップグレードのためのカタログを生成するステップであり、前記アップグレードのための前記カタログは、前記データベース管理システムの前記第２のバージョンのための前記データベースカタログの前記オリジナルバージョンの前記コピーに含まれるテーブル及びインデックスと同一のテーブル及びインデックスを有する、ステップと、
前記第１のプロセッサにより、前記アップグレードのための前記カタログ内に、前記データベース管理システムの前記第２のバージョンのための前記データベースカタログの前記オリジナルバージョンの前記コピーを保存するステップと、
前記第１のプロセッサにより、前記アップグレードのための前記カタログ内の情報について、前記データベース管理システムの前記第１のバージョンに従う前記データベースの編成に関するものから前記データベース管理システムの前記第２のバージョンに従う前記データベースの編成に関するものへ前記データベース内のデータの位置への参照の変更を引き起こすステップと、
を含む方法。
【請求項2】
前記第１のプロセッサは、前記第２のプロセッサと異なる、請求項１に記載の方法。
【請求項3】
前記第２のプロセッサの処理速度は、前記第１のプロセッサの処理速度未満である、請求項２に記載の方法。
【請求項4】
前記データベースの前記アップグレードの間、前記データベースが要求に対して無応答である事象の持続時間は、短い持続時間である、請求項１に記載の方法。
【請求項5】
前記短い持続時間は、３０秒以下である、請求項４に記載の方法。
【請求項6】
前記データベースアプリケーションスキーマのアップグレードは、前記データベースのアップグレードの間、中断される、請求項１に記載の方法。
【請求項7】
前記第１のプロセッサにより、前記参照の変更の完了に応答して、前記第１のプロセッサによる前記データベース管理システムの前記第１のバージョンの動作を停止するステップ、をさらに含む請求項１に記載の方法。
【請求項8】
前記第１のプロセッサにより、前記参照の変更の前記完了に応答して、前記第１のプロセッサによる前記データベース管理システムの前記第２のバージョンの動作を開始するステップであり、前記第１のプロセッサによる前記データベース管理システムの前記第２のバージョンの前記動作は、前記データベース管理システムの前記第２のバージョンのための前記データベースカタログのワーキングバージョンとして前記アップグレードのための前記カタログを使用する、ステップ、をさらに含む請求項７に記載の方法。
【請求項9】
前記データベース管理システムの前記第２のバージョンのための前記データベースカタログの前記ワーキングバージョンは、前記データベースアプリケーションスキーマに関連する及び前記データベース管理システムに関連するメタデータを記憶するように構成される、請求項８に記載の方法。
【請求項10】
前記第１のプロセッサにより、前記データベース管理システムの前記第２のバージョンに、前記データベースのストレージに記憶されたデータと対話させるステップ、をさらに含む請求項８に記載の方法。
【請求項11】
前記データベース管理システムの前記第２のバージョンに、前記データベースの前記ストレージに記憶された前記データと対話させるステップは、前記データの一部にアクセスする要求に応答して前記データの前記一部に対して実行される、請求項１０に記載の方法。
【請求項12】
前記データベースの前記アップグレードは、前記データベースのユーザに知覚できないように実行される、請求項１１に記載の方法。
【請求項13】
第３のプロセッサにより、前記参照の変更の前記完了に応答して、前記第３のプロセッサによる前記データベース管理システムの前記第１のバージョンの動作を停止するステップと、前記第３のプロセッサにより、前記参照の変更の前記完了に応答して、前記第３のプロセッサによる前記データベース管理システムの前記第２のバージョンの動作を開始するステップと、
をさらに含む請求項８に記載の方法。
【請求項14】
前記第３のプロセッサにより停止するステップ及び前記第３のプロセッサにより開始するステップは、前記第１のプロセッサにより停止するステップ及び前記第１のプロセッサにより開始するステップの後に生じる、請求項１３に記載の方法。
【請求項15】
前記第１のプロセッサ及び前記第３のプロセッサは、前記データベースの同じクラスタに関連づけられる、請求項１４に記載の方法。
【請求項16】
前記第１のプロセッサは、前記データベースのプライマリクラスタに関連づけられ、前記第３のプロセッサは、前記データベースのディザスタリカバリクラスタに関連づけられる、
請求項１４に記載の方法。
【発明の詳細な説明】
【背景技術】
【0001】
データベースは、メモリセル（すなわち、ストレージ）に記憶することができ、かつプロセッサにより制御されるメモリ制御回路を通じてアクセスすることができる、データの編成された集合であり得る。データベース管理システムは、アプリケーション及びエンドユーザがデータベースのメモリセルと対話することができるように、プロセッサにより操作され得るソフトウェアであり得る。データベース管理システムもまた、データベースのメモリセルに記憶することができる。データベース管理システムは、ストレージに記憶されたデータが、アプリケーション及びエンドユーザとの対話において、１つ以上のテーブルに編成されることを模倣できるように構成することができる。テーブルは、１つ以上のエンティティに関連する１つ以上の特定の型のデータのセットを配置することができるデータの集合であり得る。特定の型のデータは、テーブル内のフィールド（すなわち、列）として表すことができる。エンティティは、テーブル内のレコード（すなわち、行）として表すことができる。データベース管理システムは、（１）エンティティのデータを記憶するレコードを作成し、（２）レコードの１つ以上のフィールドにデータを書き込み、（３）レコードの１つ以上のフィールドからデータを読み出し、（４）レコードを削除するように構成することができる。
【図面の簡単な説明】
【0002】
開示される主題事項のさらなる理解を提供するために含まれる添付の図面は、本明細書に組み込まれ、本明細書の一部を構成する。図面はまた、開示される主題事項の実装を例示し、詳細な説明と共に、開示される主題事項の実装の原理を説明するのに役立つ。開示される主題事項及びそれが実施され得る様々な方法の基本的理解のために必要であり得る以上に詳細な構造的詳細を示す試みは行われない。
【図1】データベースの一例を示す図である。
【図2】時間ｔ１におけるデータベースの第１のバージョンの状態の一例を示す図である。
【図3】時間ｔ２におけるデータベースの第１のバージョンの状態の一例を示す図である。
【図4】時間ｔ３におけるデータベースの第２のバージョンの状態の一例を示す図である。
【図5】データベースを第２のバージョンにアップグレードするための従来の動作の一部の一例を示す図である。
【図6】データベース管理システムの第２のバージョンの一例を示す図である。
【図7】データベースを第２のバージョンにアップグレードするための従来の動作の別の部分の一例を示す図である。
【図8】開示される技術による、データベースを第２のバージョンにアップグレードする動作の一例を示す図である。
【図9】データベースの第１のバージョンのために使用されるメモリセルに記憶されたデータベース管理システムの第２のバージョンのためのデータベースカタログのコピーの一例を示す図である。
【図10】データベースの第１のバージョンのために使用されるメモリセルに記憶されたデータベース管理システムの第２のバージョンを示す図である。
【図11】開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードする方法の一例を示すフロー図である。
【図12】開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードするためのトポロジの一例を示す図である。
【図13】開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードする方法の一例を示す図である。
【図14】開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードするためのいくつかの動作の一例を示すフロー図である。
【図15】開示される技術による、シャドウカタログを作成する動作の一例を示すフロー図である。
【図16】開示される技術による、エラー及び信号ハンドリングのための動作の一例を示すフロー図である。
【図17】データベースを第２のバージョンにアップグレードするための従来の動作の一例を示す図である。
【図18】開示される技術による、データベースを第２のバージョンにアップグレードする動作の別の例を示す図である。
【図19】pg_classの一例を示す図である。
【図20】Relmapperファイルの一例を示す図である。
【図21】Relfilenodeの一例を示す図である。
【図22】開示される技術による、データベースを第２のバージョンにアップグレードする動作のさらに別の例を示す図である。
【図23】pg_catalog.pg_classにおけるサンプルデータの一例を示す図である。
【図24】開示される技術による、データベースを第２のバージョンにアップグレードする動作のさらに別の例を示す図である。
【図25】シャドウカタログへのコピー後のpg_catalog.pg_classにおけるサンプルデータの一例を示す図である。
【図26】Relfilenodeスワップの一例を示す図である。
【図27】シャドウカタログアップグレードの一例を示す図である。
【図28】ハイアベイラビリティ（ＨＡ）アップグレードの一例を示す図である。
【図29】ディザスタリカバリ（ＤＲ）アップグレードの一例を示す図である。
【図30】シンボリックリンクの管理の一例を示す図である。
【図31】リブート直前のシンボリックリンクの管理の一例を示す図である。
【図32】リブート後のシンボリックリンクの管理の一例を示す図である。
【発明を実施するための形態】
【0003】
本明細書で用いられるとき、コンポーネントが動作を「実行するように構成され」得るという記述は、そのコンポーネントが構造的な変更を何ら必要とせず、単にその動作を実行するための動作状態（例えば、電力を供給される、下層のオペレーティングシステムを実行している等）に置かれる必要があることを意味するものと理解することができる。
【0004】
データベースは、メモリセル（すなわち、ストレージ）に記憶することができ、かつプロセッサにより制御されるメモリ制御回路を通じてアクセスすることができる、データの編成された集合であり得る。（メモリセルは、例えば、ディスクドライブ内にあり得る。）データベース管理システムは、アプリケーション及びエンドユーザがデータベースのメモリセルと対話することができるように、プロセッサにより操作され得るソフトウェアであり得る。データベース管理システムもまた、データベースのメモリセルに記憶することができる。データベース管理システムは、ストレージに記憶されたデータが、アプリケーション及びエンドユーザとの対話において、１つ以上のテーブルに編成されることを模倣できるように構成することができる。テーブルは、１つ以上のエンティティに関連する１つ以上の特定の型のデータのセットを配置することができるデータの集合であり得る。特定の型のデータは、テーブル内のフィールド（すなわち、列）として表すことができる。エンティティは、テーブル内のレコード（すなわち、行）として表すことができる。データベース管理システムは、（１）エンティティのデータを記憶するレコードを作成し、（２）レコードの１つ以上のフィールドにデータを書き込み、（３）レコードの１つ以上のフィールドからデータを読み出し、（４）レコードを削除するように構成することができる。
【0005】
メモリセルの効率的な使用は、データベースの設計において重要な側面であり得る。テーブルの設計は、メモリセルのいくつかが不適切に設計されたテーブルのフィールドに特定の項目のためのデータを記憶するように指定されるが、少数のレコードのみがその特定の項目のデータを含む状況を、回避するようにアレンジすることができる。このようなデータを不適切に設計されたテーブルに記憶する代わりに、第１のテーブルと第２のテーブルを使用することができる。第１のテーブルは、上記少数のレコードのみに関連する特定の項目のためのデータを記憶することができ、第２のテーブルは、残りの特定の項目のためのデータを記憶することができる。第１のテーブルと第２のテーブルの間に関係を確立することができ、それにより、上記少数のレコードのみに関連する特定の項目のためのデータをデータベースから読み出すことができる。そのメタデータには、データベース内の各テーブルのエントリを含むことができる。各エントリは、テーブルの名前と、テーブルに含まれる各フィールドについて、フィールドの名前と、フィールドに記憶されるデータの型を含むことができる。
【0006】
テーブルの設計は、さらに、特定の項目のためのデータが不適切に設計されたテーブルのメモリセルに重複して記憶される状況を回避するようにアレンジすることができる。このようなデータを不適切に設計されたテーブルに記憶する代わりに、再びになるが、第１のテーブルと第２のテーブルを使用することができる。第１のテーブルは、データの単一インスタンスのみを記憶するように構成することができ、第２のテーブルは、残りの特定の項目のためのデータを記憶することができる。再びになるが、第１のテーブルと第２のテーブルの間に関係を確立することができる。
【0007】
テーブルの設計に対するこのようなアプローチはメモリセルの効率的な使用を結果としてもたらす可能性があるが、このアプローチは、多数のテーブルとこれら多数のテーブル間の関係を結果としてもたらす可能性がある。したがって、データベースは、データベースに含まれるテーブルの定義に関連するメタデータを記憶することができるデータベースカタログを含むことができる。メタデータには、例えば、データベース内の各テーブルのエントリを含むことができる。各エントリは、例えば、テーブルの名前と、テーブルに含まれる各フィールドについて、フィールドの名前と、フィールドに記憶されるデータの型を含むことができる。
【0008】
図１は、データベース１００の一例を示す図である。データベース１００は、メモリセル１０２及びプロセッサ１０４を含むことができる。メモリセル１０２は、ストレージ１０６を含むことができ、データベース管理システム１０８を記憶することができる。データベース管理システム１０８は、１つ以上のテーブル１１０及びデータベースカタログ１１２を含むことができる。
【0009】
一構成において、メモリセル１０２は、マルチテナントデータベース内にあり得る。例えば、マルチテナントデータベースは、メモリセル１０２の第１のセット及びメモリセル１０２の第２のセットを含むことができる。第１のセットと第２のセットは、分離可能であり得る。第１のセットは、レコードの第１のセットを記憶するように構成することができる。第２のセットは、レコードの第２のセットを記憶するように構成することができる。レコードの第１のセットのフィールドは、レコードの第２のセットの対応するフィールドを有することができる。レコードの第１のセットのフィールドのうちの一フィールドを、カスタムフィールドとすることができる。レコードの第２のセットの対応するフィールドのうち対応する一フィールドを、対応するカスタムフィールドとすることができる。レコードの第１のセットのカスタムフィールドは、第１の型のデータを記憶するように指定することができ、レコードの第２のセットの対応するカスタムフィールドは、第２の型のデータを記憶するように指定することができる。
【0010】
図２は、時間ｔ１におけるデータベース１００の第１のバージョンの状態の一例を示す図である。本明細書における例示の目的で、データベース１００は、小規模な情報技術サポートサービス会社のためのものであり得る。データベース１００は、時間ｔ１に、「従業員認定（Employee Certifications）」のテーブル、「活動ログ（Activity Log）」のテーブル（例えば、図１に示す１つ以上のテーブル１１０）、及び「データベースカタログ（Database Catalog）」（例えば、図１に示すデータベースカタログ１１２）を含むことができる。
【0011】
「従業員認定」のテーブルには、３つのフィールドと、時間ｔ１で３つのレコードを含むことができる。フィールドには、「EmpID」（従業員識別）、「名前（Name）」、及び「認定（Certification）」を含むことができる。３つのレコードには、時間ｔ１において、（１）従業員識別001を有し、「Apple認定サポートプロフェッショナル（Apple Certified Support Professional）-macOS」であるAnne Alphaのレコード、（２）従業員識別002を有し、「Cisco認定技術者（Cisco Certified Technician）」であるBrian Bravoのレコード、及び（３）従業員識別003を有し、「Oracleクラウド認定（Oracle Cloud Certification）」を有するCindy Charlesのレコードを含むことができる。
【0012】
「活動ログ」のテーブルには、３つのフィールドと、時間ｔ１で３つのレコードを含むことができる。フィールドには、「タイムスタンプ（Timestamp）」、「EmpID」、及び「活動（Activity）」を含むことができる。３つのレコードには、時間ｔ１において、（１）2018年8月15日午後3時03分（タイムスタンプ2018081503）の、デルタ社のネットワークをトラブルシュートするためにEmpID002により行われた作業のレコード、（２）2018年8月23日午前11時15分（タイムスタンプ2018082311155）の、Eddie EchoのオペレーティングシステムをアップデートするためにEmpID001により行われた作業のレコード、及び（３）2018年8月27日午後1時42分（タイムスタンプ201808271342）の、Felicity FoxtrotのオペレーティングシステムをアップデートするためにEmpID001により行われた作業のレコードを含むことができる。
【0013】
図２に示すように、「EmpID」フィールドは、「従業員認定」のテーブルと「活動ログ」のテーブルとの間の関係を確立することができる。この関係を通じて、データベース１００へのクエリは、（１）「Cisco認定技術者」であるBrian Bravoが、デルタ社のネットワークをトラブルシュートする作業を行ったこと、及び（２）「Apple認定サポートプロフェッショナル-macOS」であるAnne Alphaが、Eddie Echo及びFelicity Foxtrotのオペレーティングシステムを更新する作業を行ったことを決定することができる。
【0014】
「データベースカタログ」には、「従業員認定（Employee Certifications）」のテーブルと「活動ログ（Activity Log）」のテーブルの定義に関連するメタデータを記憶することができる。「従業員認定」のテーブルについては、そのメタデータには、「テーブル名：従業員認定（Table Name: Employee Certifications）」、「フィールド名：EmpID； データ型：数値（Field Name: EmpID; Data Type: number）」、「フィールド名：名前； データ型：テキスト（Field Name: Name; Data Type: text）」、及び「フィールド名：認定； データ型：テキスト（Field Name: Certification; Data Type: text）」を含むことができる。「活動ログ」のテーブルについては、そのメタデータには、「テーブル名：活動ログ（Table Name: Activity Log）」、「フィールド名：タイムスタンプ； データ型：日時（Field Name: Timestamp; Data Type: date）」、「フィールド名：EmpID； データ型：数値（Field Name: EmpID; Data Type: number）」、及び「フィールド名：活動； データ型：テキスト（Field Name: Activity; Data Type: text）」を含むことができる。
【0015】
データがデータベースに追加されるとき、より早い時間にメモリセルの効率的な使用をもたらしたテーブルの設計は、より後の時間にメモリセルの非効率的な使用をもたらす可能性がある。図３は、時間ｔ２におけるデータベース１００の第１のバージョンの状態の一例を示す図である。
【0016】
「従業員認定（Employee Certifications）」のテーブルには、時間ｔ２において、時間ｔ１以降に追加された３つの新しいレコード、すなわち、（４）従業員識別002を有し、現在「Cisco認定アーキテクト（Cisco Certified Architect）」でもあるBrian Bravoのレコード、（５）従業員識別003を有し、現在「Oracleデータベース認定（Oracle Database Certification）をさらに有するCindy Charlesのレコード、及び（６）従業員識別001を有し、現在「Apple認定サポートプロフェッショナル（Apple Certified Support Professional）-OS X」でもあるAnne Alphaのレコードを含むことができる。
【0017】
「活動ログ（Activity Log）」のテーブルには、時間ｔ２において、時間ｔ１以降に追加された３つの新しいレコード、すなわち、（４）2018年9月5日午前9時37分（タイムスタンプ201809050937）の、ゴルフ社のデータベースを修正するためにEmpID003により行われた作業のレコード、（５）2018年9月12日午後2時8分（タイムスタンプ201809121408）の、ヘンリーホテルのオペレーティングシステムを更新するためにEmpID001により行われた作業のレコード、及び（６）2018年9月20日午後12時10分（タイムスタンプ201809201210）の、インド社のネットワークをトラブルシュートするためにEmpID02により行われた作業のレコードを含むことができる。
【0018】
図２に示すように、時間ｔ１でメモリセルの効率的な使用をもたらした「従業員認定」のテーブルの設計は、時間ｔ２でメモリセルの非効率的な使用をもたらしている。時間ｔ２の「従業員認定」テーブルでは、時間ｔ１で「従業員認定」テーブルの「名前」フィールドのデータが重複して記憶されている。すなわち、時間ｔ１では、特定の認定を有する従業員の名前のデータを「従業員認定」のテーブルの「名前」フィールドに記憶することがメモリセルの効率的な使用をもたらしており、なぜならば、時間ｔ１では、各従業員は１つだけ特定の認定を有していたためである。しかしながら、時間ｔ２では、１以上の従業員が１つ以上の特定の認定を有するため、特定の認定を有する従業員の名前のデータを「従業員認定」のテーブルの「名前」フィールドに記憶することはメモリセルの非効率的な使用をもたらしている。データベース１００を再びメモリセルの効率的な使用のために構成することができるように、テーブルの設計は、データベース１００の第２のバージョンのために再構成することができる。
【0019】
図４は、時間ｔ３におけるデータベース１００の第２のバージョンの状態の一例を示す図である。データベース１００は、ｔ３時点で、「認定（Certifications）」のテーブル、「従業員（Employees）」のテーブル、「活動ログ（Activity Log）」のテーブル、及び「データベースカタログ（Database Catalog）」を含むことができる。
【0020】
「認定」のテーブルには、３つのフィールドと、時間ｔ３で６つのレコードを含むことができる。フィールドには、「EmpID」（従業員識別）、「CertID」（認定識別）、「認定（Certification）」を含むことができる。「CertID」フィールドには、（１）「Apple認定サポートプロフェッショナル-macOS」のための認定識別AAA、（２）「Cisco認定技術者」のための認定識別AAB、（３）「Oracleクラウド認定」のための認定識別AAC、（４）「Cisco認定アーキテクト」のための認定識別AAD、（５）「Oracleデータベース認定」のための認定識別AAE、及び（６）「Apple認定サポートプロフェッショナル-OS X」のための認定識別AAFを含むことができる。これらは、時間ｔ２でのデータベース１００の第１のバージョン内の「従業員認定」のテーブルに含まれる６つのレコードに対応する。
【0021】
「従業員」のテーブルには、２つのフィールドと、時間ｔ３で３つのレコードを含むことができる。フィールドには、「EmpID」と「名前（Name）」を含むことができる。３つのレコードには、時間ｔ３で、（１）Anne Alphaのレコード、（２）Brian Bravoのレコード、及び（３）Cindy Charlesのレコードを含むことができる。
【0022】
時間ｔ３でのデータベース１００の第２のバージョンにおける「活動ログ」のテーブルは、時間ｔ２でのデータベース１００の第１のバージョンにおける「活動ログ」のテーブルと同一であり得る。
【0023】
図３に示すように、「EmpID」フィールドは、「認定」のテーブル、「従業員」のテーブル、及び「活動ログ」のテーブルの間の関係を確立することができる。この関係を通じて、データベース１００へのクエリは、（１）「Cisco認定技術者」及び「Cisco認定アーキテクト」であるBrian Bravoが、デルタ社及びインド社のネットワークをトラブルシュートする作業を行ったこと、（２）「Apple認定サポートプロフェッショナル-macOS」及び「Apple認定サポートプロフェッショナル-OS X」であるAnne Alphaが、「Eddie Echo」、「Felicity Foxtrot」、及び「Henry Hotel」のオペレーティングシステムを更新する作業を行ったこと、及び（３）「Oracleクラウド認定」及び「Oracleデータベース認定」を有するCindy Charlesが、ゴルフ社のデータベースを修正する作業を行ったことを決定することができる。
【0024】
「データベースカタログ」には、「認定」のテーブル、「従業員」のテーブル、及び「活動ログ」のテーブルの定義に関連するメタデータを記憶することができる。「認定」のテーブルについては、そのメタデータには、「テーブル名：認定（Table Name： Cerifications）」、「フィールド名：EmpID； データ型：数値（Field Name: EmpID; Data Type: number）」、「フィールド名：CertID； データ型：テキスト（Field Name: CertID; Data Type: text）」、及び「フィールド名：認定； データ型：テキスト（Field Name: Certification; Data Type: text）」を含むことができる。「従業員」のテーブルについては、そのメタデータには、「テーブル名：従業員（Table Name: Employees）」、「フィールド名：EmpID； データ型：数値（Field Name: EmpID; Data Type: number）」、及び「フィールド名：名前； データ型：テキスト（Field Name: Name; Data Type: text）」を含むことができる。「活動ログ」のテーブルについては、そのメタデータには、「テーブル名：活動ログ（Table Name: Activity Log）」、「フィールド名：タイムスタンプ； データ型：日時（Field Name: Timestamp; Data Type: date）」、「フィールド名：EmpID； データ型：数値（Field Name: EmpID; Data Type: number）」、及び「フィールド名：活動； データ型：テキスト（Field Name: Activity; Data Type: text）」を含むことができる。
【0025】
開示される技術は、データベースを第１のバージョンから第２のバージョンにアップグレードする動作に向けることができる。
【0026】
従来、データベースを第１のバージョンから第２のバージョンにアップグレードする動作は、（１）別のプロセッサ及び他のメモリセルを提供してデータベース管理システムの第２のバージョンを設計すること、（２）データベース管理システムの第２のバージョンに、ストレージに記憶されたデータと対話させること、及び（３）データベース管理システムの第１のバージョンの動作を停止することを必要としていた。このアプローチは、比較的多数の他のメモリセルがデータベース管理システムの第２のバージョンを記憶するために利用可能であり、他のプロセッサがデータベース管理システムの第２のバージョンを動作させるために利用可能であることを要する。
【0027】
図５は、データベース１００を第２のバージョンにアップグレードするための従来の動作の一部の一例を示す図である。データベース１００は、メモリセル１０２及びプロセッサ１０４を含むことができる。メモリセル１０２は、ストレージ１０６を含むことができ、データベース管理システム１０８を記憶することができる。データベース管理システム１０８は、１つ以上のテーブル１１０及びデータベースカタログ１１２を含むことができる。さらに、データベース１００は、データベース管理システム５０８の第２のバージョンを設計するために、別のプロセッサ５０４及び他のメモリセル５０２を含むことができる。データベース管理システム５０８の第２のバージョンは、１つ以上の他のテーブル５１０（例えば、図４に示す「認定」のテーブル、「従業員」のテーブル、及び「活動ログ」のテーブル）と、別のデータベースカタログ５１２（例えば、図４に示す「データベースカタログ」）を含むことができる。図６は、データベース管理システム５０８の第２のバージョンの一例を示す図である。
【0028】
図７は、データベース１００を第２のバージョンにアップグレードするための従来の動作の別の部分の一例を示す図である。図７に示すように、データベース管理システム５０８の第２のバージョンは、図４に示すデータベース１００の第２のバージョンを生成するために、ストレージ１０６に記憶されたデータと対話させられている。図７に示すデータベースは、共用されたストレージを有する。
【0029】
対照的に、（１）別のプロセッサ及び他のメモリセルを提供してデータベース管理システムの第２のバージョンを設計し、（２）データベース管理システムの第２のバージョンに、ストレージに記憶されたデータと対話させるのでなく、開示される技術は、（１）別のプロセッサ及び他のメモリセルを提供してデータベース管理システムの第２のバージョンのためのデータベースカタログを生成し、（２）データベースの第１のバージョンのメモリセル内に第２のバージョンのコントローラを確立し、（３）データベース管理システムの第２のバージョンのためのデータベースカタログのコピーをデータベースの第１のバージョンのメモリセル内に記憶し、（４）第２のバージョンのコントローラに、データベース管理システムの第２のバージョンのためのデータベースカタログのコピーを使用してデータベース管理システムの第２のバージョンの１つ以上のテーブルを生成するようにさせ、（５）データベース管理システムの第２のバージョンに、ストレージに記憶されたデータと対話させ、（６）データベース管理システムの第１のバージョンの動作を停止することができる。
【0030】
上述の従来のアプローチと比較して、開示される技術のアプローチは、（１）（データベース管理システムの第２のバージョンを全体としてでなく）データベース管理システムの第２のバージョンのためのデータベースカタログを記憶するために、より少数の他のメモリセルが利用可能であること、及び（２）データベース管理システムの第２のバージョンのためのデータベースカタログを生成するために、他のプロセッサによってより少ない動作が実行されること（例えば、従来のアプローチの他のプロセッサと比較して、開示される技術の他のプロセッサは軽量プロセッサでもよい）を要する。さらに、一構成において、開示される技術の動作は、（１）データベースによりユーザに提供されるサービスの途絶が、名目上の持続時間（例えば、３０秒）の間のみであり得、（２）データベースを第１のバージョンから第２のバージョンにアップグレードすることを、データベースのユーザにより知覚できないように効果的に実行できるように、徐々に実行することができる。
【0031】
図８は、開示される技術による、データベース１００を第２のバージョンにアップグレードする動作の一例を示す図である。データベース１００は、メモリセル１０２及びプロセッサ１０４を含むことができる。メモリセル１０２は、ストレージ１０６を含むことができ、データベース管理システム１０８を記憶することができる。データベース管理システム１０８は、１つ以上のテーブル１１０及びデータベースカタログ１１２を含むことができる。さらに、データベース１００は、別のプロセッサ８０４及び他のメモリセル８０２を含み、図８の動作１として示すように、データベース管理システム８１２の第２のバージョンのためのデータベースカタログ（例えば、図４に示す「データベースカタログ」）を生成することができる。第２のバージョンのコントローラ８１４を、データベース１００の第１のバージョンのために使用されるメモリセル１０２内に確立することができ、データベース管理システムの第２のバージョンのためのデータベースカタログのコピー８１６を、図８の動作２として示すように、データベース１００の第１のバージョンに使用されているメモリセル１０２内に記憶することができる。図９は、データベース１００の第１のバージョンのために使用されるメモリセル１０２に記憶されたデータベース管理システムの第２のバージョンのためのデータベースカタログ（database catalog）のコピー８１６の一例を示す図である。図８に戻り、図８の動作３として示すように、第２のバージョンのコントローラ８１４に、データベース管理システムの第２のバージョンのためのデータベースカタログのコピー８１６を使用してデータベース管理システムの第２のバージョンの１つ以上の他のテーブル（例えば、図４に示す「認定」のテーブル、「従業員」のテーブル、及び「活動ログ」のテーブル）を生成するようにさせることができる。図１０は、データベース１００の第１のバージョンのために使用されるメモリセル１０２に記憶されたデータベース管理システムの第２のバージョンを示す図である。図８に戻り、図８の動作４として示すように、データベース管理システムの第２のバージョンに、ストレージ１０６に記憶されたデータと対話して（図４に示すように）データベース１００の第２のバージョンを生成するようにさせることができる。
【0032】
図１１は、開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードする方法１１００の一例を示すフロー図である。方法１１１０では、動作１１０２において、第１のプロセッサが、データベースのデータベース管理システムの第２のバージョンのためのデータベースカタログを生成することができる。データベースカタログは、データベースの第２のバージョンに含まれるオブジェクト又はテーブルの定義に関連するメタデータを記憶するように構成することができる。データベースの第２のバージョンに含まれるオブジェクト又はテーブルの定義に関連するメタデータは、例えば、データベースの第２のバージョンにおけるオブジェクト又はテーブルの各々のエントリを含むことができる。各エントリは、例えば、（１）テーブル又はオブジェクトの名前、及び（２）テーブルに含まれる各フィールドについて、又はオブジェクトに含まれる各属性について、（ａ）フィールド又は属性の名前、及び（ｂ）フィールド又は属性に記憶されるデータの型を含むことができる。
【0033】
動作１１０４において、データベースの第１のバージョンのために使用されるメモリセル内に、コントローラを確立させることができる。データベース管理システムの第２のバージョンのためのデータベースカタログを生成するために使用されるメモリセルの数は、例えば、データベースの第１のバージョンのために使用されるメモリセルの数未満であり得る。
【0034】
動作１１０６において、データベース管理システムの第２のバージョンのためのデータベースカタログのコピーを、データベースの第１のバージョンのためのメモリセルに記憶することができる。
【0035】
動作１１０８において、データベース管理システムの第２のバージョンを、データベースカタログのコピー、データベース管理システムの第２のバージョンを使用して、コントローラにより生成することができる。コントローラは、例えば、データベース管理システムの第２のバージョンのみを生成するように構成することができる。コントローラは、例えば、データベース管理システムの別のバージョンを生成しないように構成することができる。
【0036】
動作１１１０において、データベース管理システムの第２のバージョンに、データベースのストレージに記憶されたデータと対話させることができる。ストレージは、データベースの第１のバージョンのために使用されるメモリセルに含めることができる。第２のプロセッサは、例えば、データベースの第１のバージョンに対して使用されるメモリセルと対話して、データベースの第１のバージョンを動作させるように構成することができる。第１のプロセッサは、第２のプロセッサと異なり得る。第１のプロセッサの処理速度は、例えば、第２のプロセッサの処理速度未満でもよい。一構成において、動作１１１０は、データベースのストレージに記憶されたデータの一部に対して、該データの一部にアクセスする要求に応答して実行することができる。このようにして、データベースのアップグレードは、データベースのストレージに記憶されたデータの部分が次々にアクセスの要求の対象になるとき、ある時間にわたり徐々に生じ得る。データベースのアップグレードは、データベースのユーザが知覚できないように実行することができる。
【0037】
任意的な動作１１１２において、データベースの第１のバージョンの動作を停止することができる。
【0038】
一構成において、データベースのアップグレードの間、データベースが要求に対して無応答である場合の持続時間は、短い持続時間であり得る。例えば、この短い持続時間は、３０秒以下でもよい。
【0039】
一構成において、データベースに関連づけられたアプリケーションのアップグレードは、データベースをアップグレードする間、中断することができる。
【0040】
一構成において、動作１１０２、１１０４、１１０６、１１０８、及び１１１０は、データベースの第１のクラスタに対して実行することができる。この構成において、動作１１０２、１１０４、１１０６、１１０８、及び１１１０は、データベースの第２のクラスタに対して実行することができる。例えば、データベースの第２のクラスタに対する動作１１０２、１１０４、１１０６、１１０８、及び１１１０の実行は、データベースの第１のクラスタに対して動作１１０２、１１０４、１１０６、１１０８、及び１１１０が実行された後、生じてもよい。データベースの第２のクラスタには、例えば、スタンバイクラスタ、ディザスタリカバリクラスタ、又はハイアベイラビリティクラスタを含むことができる。
【0041】
開示される技術によれば、任意の所与の時間にホストごとに実行される１つのデータベースコンテナが存在し得る。これにより、データベースホストの利用率を最大化することができる。
【0042】
開示される技術は、大多数の将来のデータベースアップグレードシナリオをハンドリングするのに十分に一般的であり得る（すなわち、停止を必要とするアップグレードシナリオは、数年間隔であろう）。
【0043】
開示される技術は、ハードウェア要件を増加させない可能性がある（すなわち、これらは、付加的なホストを必要としない可能性がある）。
【0044】
開示される技術は、エンドユーザにより知覚されるゼロのダウンタイムを実現することができる。一般に、これは、データベースが最大でも３０秒の間、要求に対して無応答であり得ることを意味する。
【0045】
開示される技術は、動作上、平易であり得る。
【0046】
開示される技術は、本番（production）における全てのアップグレードに対して１つのみのソリューションを提供するように構成することができる。
【0047】
開示される技術は、データベースのアップグレードの間、データベースに関連づけられたアプリケーションのアップグレードを中断することができる方法で実施することができる。
【0048】
開示される技術は、進行中のアップグレードがハイアベイラビリティ（high availability、ＨＡ）又はディザスタリカバリ（disaster recovery、ＤＲ）サービスの低下を引き起こすような方法で実施される場合がある。
【0049】
開示される技術は、アップグレードの持続時間が予測可能であり、時間においてほぼ一定であり得るような方法で実施することができる。すなわち、時間は、より大きいデータセットに対して増えない可能性がある。
【0050】
開示される技術は、何らかの理由でアップグレードが失敗した場合に、顧客データの損失なく、かつ３０秒未満の全体的な途絶で前の状態に戻すための簡易な方法が存在し得るような方法で実施することができる。
【0051】
開示される技術は、自動化された方法でフォールトインジェクション（fault injection）を用いてテストすることが容易又は実現可能な方法で実施することができる。
【0052】
開示される技術は、データベースコンテナをより新しいバージョンで置き換える前に、アップグレードされたバージョンにマッチし得るシャドウデータベースカタログを構築することができる。新しいデータベースバイナリを開始するとき、新しいカタログのために、古いカタログをスワップアウトすることができる。
【0053】
開示される技術を使用し、データベースサービスクラスタを第１のバージョンから第２のバージョンにアップグレードすることは、以下の動作を含むことができる。
１．前提条件の検証
このフェーズは、アップグレードプロセス全体を通して失敗のリスクを最小化するためのものであり得る。それは、以下を含むことができる。
ａ． 前の失敗したアップグレードからの残りのクリーンアップ。
ｂ． ダンプ及びコピーされたファイルを含むのに利用可能な十分なリソースが存在することの検証。
ｃ． 進行中のアプリケーションアップグレードが存在しないことの確認。
２．新しいカタログの構築
この動作は、ＳＡＭに存在でき、かつマスタに接続するために使用できる専用の「アップグレードコントローラコンテナ」により実行することができる。コントローラは、以下の動作を実行できる。
ａ． Initdbをアップグレードコンテナイメージ構築時に行うことができる。
ｂ． データベースサービスにおいてシャドウカタログスキーマ（shadow catalog schema）を作成する。
ｃ． データベースサービスクラスタを、（データ定義言語（Data Definition Language、ＤＤＬ）で書かれた）特定のアクションを防止するモードに置く。
これにより、基本的に、オリジナルのシステムカタログ全体を読取専用モードに置くことができる。これは、pg_tenantを除外することができる。
ｄ． アップグレードコントローラが、データベースサービスのアプリスキーマ（app schema）のダンプを実行することができる。
ｅ． アップグレードコントローラが、データベースサービスのダンプされたアプリスキーマの、そのローカルデータベースへのリストアを実行することができる。
ｆ． アップグレードコントローラが、システムカタログコンテンツ全体をｃｓｖファイルのセットにコピーし、システムカタログテーブルのＤＤＬスクリプトを生成することができる。
ｇ． システムカタログｃｓｖファイルは、データベースサービスマスタに送ることができる。
ｈ． アップグレードコントローラが、シャドウカタログテーブル（ｂで作成）を、送られたｃｓｖファイルでフィルすることができる。
ｉ． アップグレードコントローラが、データベースサービスクラスタを「コンテナアップグレードの準備完了」としてマーク付けすることができる。
「アップグレードコントローラ」は、最小限のデータベースインスタンスで実行することができ、なぜならば、コントローラの唯一の目的は、アプリスキーマを用いて第２のバージョンのシステムカタログを生成することだからである。
さらに、コントローラは全体的に、ＲＡＭディスクを使用し、かつロギングすることなく、メモリ内で動作することができる。これは、リストアのパフォーマンスを大きく向上させる可能性がある。
アップグレードコントローラとデータベースサービスのマスタとの間で転送されるデータの量は、ｚｉｐファイルを送ることにより最小限に保つことができる。ダンプ出力とｃｓｖファイルの双方がかなりうまく圧縮されることがある。
この動作の終わりに、ディザスタリカバリ（ＤＲ）ログレコードアプリケーションにおける待ち時間を考慮し、データベースサービスクラスタ全体が最新の第２のバージョンのクローンカタログを有することができる。
２．バイナリアップグレードの実行
この動作は、最初にディザスタリカバリ（ＤＲ）サイト、及びローカルデータベースサービスのスレーブで実行することができる。
マスタは、アプリケーションの起動を保つために、ハイアベイラビリティ（ＨＡ）フェイルオーバに依存して最後にアップグレードすることができる。この時間に、アプリは第２のバージョンのデータベースバイナリで動作を開始できることに留意する。
個々の動作は、以下のようになり得る。
ａ． 第１のバージョンのコンテナを第２のバージョンのコンテナで置き換える。
ｂ． データベースの第２のバージョンを開始する。
ｃ． データベースの第２のバージョンが開始されたとき、それは、それが第２のバージョンであり、第２のバージョンにおけるカタログクローンがあることを発見する。
次いで、それは、このクローンを使用するためにカタログを入れ替える（flip）ことができ、ブートストラップテーブル上で小さいハウスキーピングを実行することができる。
ｄ．連続リカバリモードに入る（すなわち、これは、常にスレーブであり得る）。
３． ＤＤＬ無し（no-DDL）フラグの削除
クラスタ内の最後のノードがアップグレードされると、（ＤＤＬで書かれた）特定のアクションが再度許可され得る。
１．前提条件の検証
このフェーズは、アップグレードプロセス全体を通して失敗のリスクを最小化するためのものであり得る。それは、以下を含むことができる。
ａ． 前の失敗したアップグレードからの残りのクリーンアップ。
ｂ． ダンプ及びコピーされたファイルを含むのに利用可能な十分なリソースが存在することの検証。
ｃ． 進行中のアプリケーションアップグレードが存在しないことの確認。
２．新しいカタログの構築
この動作は、ＳＡＭに存在でき、かつマスタに接続するために使用できる専用の「アップグレードコントローラコンテナ」により実行することができる。コントローラは、以下の動作を実行できる。
ａ． Initdbをアップグレードコンテナイメージ構築時に行うことができる。
ｂ． データベースサービスにおいてシャドウカタログスキーマ（shadow catalog schema）を作成する。
ｃ． データベースサービスクラスタを、（データ定義言語（Data Definition Language、ＤＤＬ）で書かれた）特定のアクションを防止するモードに置く。
これにより、基本的に、オリジナルのシステムカタログ全体を読取専用モードに置くことができる。これは、pg_tenantを除外することができる。
ｄ． アップグレードコントローラが、データベースサービスのアプリスキーマ（app schema）のダンプを実行することができる。
ｅ． アップグレードコントローラが、データベースサービスのダンプされたアプリスキーマの、そのローカルデータベースへのリストアを実行することができる。
ｆ． アップグレードコントローラが、システムカタログコンテンツ全体をｃｓｖファイルのセットにコピーし、システムカタログテーブルのＤＤＬスクリプトを生成することができる。
ｇ． システムカタログｃｓｖファイルは、データベースサービスマスタに送ることができる。
ｈ． アップグレードコントローラが、シャドウカタログテーブル（ｂで作成）を、送られたｃｓｖファイルでフィルすることができる。
ｉ． アップグレードコントローラが、データベースサービスクラスタを「コンテナアップグレードの準備完了」としてマーク付けすることができる。
「アップグレードコントローラ」は、最小限のデータベースインスタンスで実行することができ、なぜならば、コントローラの唯一の目的は、アプリスキーマを用いて第２のバージョンのシステムカタログを生成することだからである。
さらに、コントローラは全体的に、ＲＡＭディスクを使用し、かつロギングすることなく、メモリ内で動作することができる。これは、リストアのパフォーマンスを大きく向上させる可能性がある。
アップグレードコントローラとデータベースサービスのマスタとの間で転送されるデータの量は、ｚｉｐファイルを送ることにより最小限に保つことができる。ダンプ出力とｃｓｖファイルの双方がかなりうまく圧縮されることがある。
この動作の終わりに、ディザスタリカバリ（ＤＲ）ログレコードアプリケーションにおける待ち時間を考慮し、データベースサービスクラスタ全体が最新の第２のバージョンのクローンカタログを有することができる。
２．バイナリアップグレードの実行
この動作は、最初にディザスタリカバリ（ＤＲ）サイト、及びローカルデータベースサービスのスレーブで実行することができる。
マスタは、アプリケーションの起動を保つために、ハイアベイラビリティ（ＨＡ）フェイルオーバに依存して最後にアップグレードすることができる。この時間に、アプリは第２のバージョンのデータベースバイナリで動作を開始できることに留意する。
個々の動作は、以下のようになり得る。
ａ． 第１のバージョンのコンテナを第２のバージョンのコンテナで置き換える。
ｂ． データベースの第２のバージョンを開始する。
ｃ． データベースの第２のバージョンが開始されたとき、それは、それが第２のバージョンであり、第２のバージョンにおけるカタログクローンがあることを発見する。
次いで、それは、このクローンを使用するためにカタログを入れ替える（flip）ことができ、ブートストラップテーブル上で小さいハウスキーピングを実行することができる。
ｄ．連続リカバリモードに入る（すなわち、これは、常にスレーブであり得る）。
３． ＤＤＬ無し（no-DDL）フラグの削除
クラスタ内の最後のノードがアップグレードされると、（ＤＤＬで書かれた）特定のアクションが再度許可され得る。
【0054】
アップグレードコントローラサービス
アップグレードコントローラは、データベースノードとコロケートされる（co-located）必要のないマイクロサービスであり得る。それは、概念的に、オーケストレーション（orchestration）の一部でもよい。コンテナは、以下を含むことができる。
・ データベースの第２のバージョンのインスタンス。（これは各バージョンで変わり、そのため、各アップグレードで新しいコントローラが生成される必要があり得ることに留意する（コントローラは単に空のinitdbでもよく、そのため、それ自体はアップグレードされない）。）
・ 任意で、コアアプリスキーマを保持するほど十分に大きいＲＡＭディスク。あるいは、ローカルＳＳＤを使用することができる。
・ アップグレードステップを実行するドライバプログラム
アップグレードコントローラは、データベースノードとコロケートされる（co-located）必要のないマイクロサービスであり得る。それは、概念的に、オーケストレーション（orchestration）の一部でもよい。コンテナは、以下を含むことができる。
・ データベースの第２のバージョンのインスタンス。（これは各バージョンで変わり、そのため、各アップグレードで新しいコントローラが生成される必要があり得ることに留意する（コントローラは単に空のinitdbでもよく、そのため、それ自体はアップグレードされない）。）
・ 任意で、コアアプリスキーマを保持するほど十分に大きいＲＡＭディスク。あるいは、ローカルＳＳＤを使用することができる。
・ アップグレードステップを実行するドライバプログラム
【0055】
以下の必要はない可能性がある。
・ Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）、
・ メトリックストリーマ、又は
・ 分散データベースストア。
・ Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）、
・ メトリックストリーマ、又は
・ 分散データベースストア。
【0056】
一構成において、コンテナは、アプリスキーマを受け入れるために既に実行準備のできたinitdbを備えることができる。
【0057】
図１２は、開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードするためのトポロジの一例を示す図である。
【0058】
図１３は、開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードする方法の一例を示す図である。図１３には、以下の動作を示している。
１． 第２のバージョンのコントローラ（すなわち、この特定のアップグレードバージョンのためのコントローラ）を取得する。
２． 第２のバージョンのシステムカタログＤＤＬファイルをダンプする。
（initdbの後のコントローラの第２のバージョンのカタログのpg_dump）
３． カタログＤＤＬファイル（ステップ２からのpg_dump出力）をマスタにプッシュする。
４． 各データベースについて、第１のバージョンのマスタ上に新しいスキーマで第２のバージョンのシャドウカタログを構築する。共有テーブルを、template1に１回のみ構築することができる。
５． ＤＤＬ無しフェーズをマーク付けする（コントローラのアップグレードスクリプトから呼び出される）。
ａ． これは、ワークフローデーモンを停止することができ、あるいは、これらは、ＤＤＬ制限（restrict-DDL）セマンティクスを順守しなければならない。しかし、ＤＲサイトのワークフローデーモンは、これらがカタログテーブルを修正しないため、継続してもよい。
６． シャドウテーブルを除くアプリスキーマＤＤＬをダンプする。
７． アプリスキーマＤＤＬをコントローラにプルする。
８． アプリスキーマを（コントローラ上の）第２のバージョンのカタログにリストアする。
９． 第２のバージョンのカタログをカンマ区切り値（ＣＳＶ）ファイルにコピーする。
１０． ＣＳＶファイルをマスタに送る。
１１． ＣＳＶファイルを第２のバージョンのシャドウカタログにコピーする。
１２． アップグレードの準備ができているデータベースをマーク付けする。
１３． ディザスタリカバリ（ＤＲ）サイトでクバネティス（kubernetes）アップグレードを実行する。
ａ． シャドウカタログがディザスタリカバリ（ＤＲ）サイトに伝播するのを待つ。
ｂ． 第２のバージョンのスレーブを開始する（これは、シャドウカタログを見つけ、使用する）。
ｃ． 全てのスレーブが第２のバージョンで動作しているとき、（そのほとんどを完了するために）フラッシュし、（アプリ接続を停止するために）スーパーユーザ専用モードに入り、（リカバリを速めるために）フラッシュし、第１のバージョンのマスタを停止する。
１４． プライマリサイトでクバネティスアップグレードを実行する。
ａ． 第２のバージョンのスレーブを開始する（これは、シャドウカタログを見つけ、使用する）。
ｂ． 全てのスレーブが第２のバージョンであるとき、（そのほとんどを完了するために）フラッシュし、（アプリ接続を停止するために）スーパーユーザ専用モードに入り、（リカバリを速めるために）フラッシュし、第１のバージョンのマスタを停止する。
１５． ＤＤＬ制限モードをクリアする（成功又は失敗のアップグレードに対してオーケストレータ（Orchestrator）により呼び出される）。
１６． アップグレードされたデータベースが使用可能になる。
１． 第２のバージョンのコントローラ（すなわち、この特定のアップグレードバージョンのためのコントローラ）を取得する。
２． 第２のバージョンのシステムカタログＤＤＬファイルをダンプする。
（initdbの後のコントローラの第２のバージョンのカタログのpg_dump）
３． カタログＤＤＬファイル（ステップ２からのpg_dump出力）をマスタにプッシュする。
４． 各データベースについて、第１のバージョンのマスタ上に新しいスキーマで第２のバージョンのシャドウカタログを構築する。共有テーブルを、template1に１回のみ構築することができる。
５． ＤＤＬ無しフェーズをマーク付けする（コントローラのアップグレードスクリプトから呼び出される）。
ａ． これは、ワークフローデーモンを停止することができ、あるいは、これらは、ＤＤＬ制限（restrict-DDL）セマンティクスを順守しなければならない。しかし、ＤＲサイトのワークフローデーモンは、これらがカタログテーブルを修正しないため、継続してもよい。
６． シャドウテーブルを除くアプリスキーマＤＤＬをダンプする。
７． アプリスキーマＤＤＬをコントローラにプルする。
８． アプリスキーマを（コントローラ上の）第２のバージョンのカタログにリストアする。
９． 第２のバージョンのカタログをカンマ区切り値（ＣＳＶ）ファイルにコピーする。
１０． ＣＳＶファイルをマスタに送る。
１１． ＣＳＶファイルを第２のバージョンのシャドウカタログにコピーする。
１２． アップグレードの準備ができているデータベースをマーク付けする。
１３． ディザスタリカバリ（ＤＲ）サイトでクバネティス（kubernetes）アップグレードを実行する。
ａ． シャドウカタログがディザスタリカバリ（ＤＲ）サイトに伝播するのを待つ。
ｂ． 第２のバージョンのスレーブを開始する（これは、シャドウカタログを見つけ、使用する）。
ｃ． 全てのスレーブが第２のバージョンで動作しているとき、（そのほとんどを完了するために）フラッシュし、（アプリ接続を停止するために）スーパーユーザ専用モードに入り、（リカバリを速めるために）フラッシュし、第１のバージョンのマスタを停止する。
１４． プライマリサイトでクバネティスアップグレードを実行する。
ａ． 第２のバージョンのスレーブを開始する（これは、シャドウカタログを見つけ、使用する）。
ｂ． 全てのスレーブが第２のバージョンであるとき、（そのほとんどを完了するために）フラッシュし、（アプリ接続を停止するために）スーパーユーザ専用モードに入り、（リカバリを速めるために）フラッシュし、第１のバージョンのマスタを停止する。
１５． ＤＤＬ制限モードをクリアする（成功又は失敗のアップグレードに対してオーケストレータ（Orchestrator）により呼び出される）。
１６． アップグレードされたデータベースが使用可能になる。
【0059】
技術的詳細
データベースのアップグレードには、２つの主なフェーズがあり得る。
データベースのアップグレードには、２つの主なフェーズがあり得る。
【0060】
シャドウカタログ作成。このフェーズは、カタログ変更の詳細を隠すことができ、それにより、次のフェーズのローリングアップグレード（rolling upgrade）がバイナリアップグレードを行うことができる。このフェーズは、アップグレードコントローラ、軽量（ｓｄｂイメージのみ、ｂｋプロキシ及びメトリックストリーマなし）の、データベースイメージの第２のバージョン及びアップグレードスクリプトを含むことができる短寿命コンテナによりハンドリングすることができる。各データベースクラスタについて、単一のアップグレードコントローラが必要とされ得る。このフェーズの成功裏の完了の後、第２のバージョンの形状、ビルトイン、及びアプリスキーマを有するシャドウカタログをプライマリに作成することができる。スタンバイがシャドウカタログの変更に追いついたとき、クラスタは、アップグレードの準備ができ得る。このフェーズがいずれにせよ失敗した場合、何の害もなされない。このフェーズが作成する全ては、第２のバージョンのイメージでのみ使用できるシャドウカタログである。前に失敗した実行から残ったいかなるアーチファクトも、アップグレードコントローラが再度実行されたとき、破棄することができる。このフェーズは、コアアプリスキーマ及び２ＧＢのメモリに対して約１０分かかる可能性がある。
【0061】
ローリングアップグレード。このフェーズは、オーケストレーションに関連づけられる。アップグレードは、最初に本番クラスタ、及び最後にディザスタリカバリ（ＤＲ）クラスタで生じ得る。
【0062】
シャドウカタログの作成
アップグレードモード。データベースアップグレードは、シャドウスキーマを作成すること及びpg_global表領域（table space）にテーブルを作成することを含む、通常許可されていない動作を要求し得る。新しいブールのセッションスコープのグランドユニファイド構成（Grand Unified Configuration、ＧＵＣ）upgrade_modeを追加して、アップグレードにおいてこれらを許可する。ＧＵＣは、スーパーユーザによってのみセットアップすることができる。アップグレードコントローラは、データベースクラスタ内のスクリプトをｄｂスーパーユーザとして実行することができる。
アップグレードモード。データベースアップグレードは、シャドウスキーマを作成すること及びpg_global表領域（table space）にテーブルを作成することを含む、通常許可されていない動作を要求し得る。新しいブールのセッションスコープのグランドユニファイド構成（Grand Unified Configuration、ＧＵＣ）upgrade_modeを追加して、アップグレードにおいてこれらを許可する。ＧＵＣは、スーパーユーザによってのみセットアップすることができる。アップグレードコントローラは、データベースクラスタ内のスクリプトをｄｂスーパーユーザとして実行することができる。
【0063】
（ＤＤＬで書かれた）特定のデータベースアクションのブロック。動作のほとんどは、pg_database内の全てのデータベースを反復し得る。したがって、作業すべきデータベースのリストがひとたび取得されると、（ＤＤＬで書かれた）特定のデータベースアクションをブロックする必要があり得る。コマンドは、以下のとおりでもよい：SELECT pg_catalog.pg_set_restriction_mode(‘block-db-ddl’)；。
【0064】
シャドウスキーマ。シャドウカタログテーブルは、スーパーユーザにより所有されるsdb_shadow_catalogという名前のスキーマ下で作成することができる。この名前は、データベースアップグレードのみによる使用のために予約することができる。セキュリティのため、アプリケーションは、同じスキーマを作成すること又はその内容を修正することができない。これは、アプリケーションがスーパーユーザを通じてデータベースに接続できないことを仮定している。失敗診断のため、スキーマは、スーパーユーザとして接続するリリースエンジニアに見えてもよい。
【0065】
スキーマは、クラスタ内の各データベースに作成する（又は、既に存在する場合には最初に破棄する）ことができる。Template0は、デフォルトでは接続を許可しない。それは、アップグレードの間の接続を有効にし、終わりに無効にし得る。
【0066】
シャドウカタログテーブル。ほとんどのカタログテーブルはデータベースに特有であり得、例えばpg_classである。これらのデータベースのシャドウテーブルは、通常のユーザテーブルと同様に作成することができる。
【0067】
カタログテーブルの小さいセットは全てのデータベースで共有することができ、例えば、pg_database、pg_authid、pg_tenant等である。これらのテーブル行のログ構造マージ（log-structured merge、ＬＳＭ）鍵のデータベース番号部分は０である。シャドウテーブルは、特殊なツイーク（tweek）を要求することができる。その鍵は、それが最終的に置き換える実鍵と同じ鍵空間（key space）になければならない。これは、データベース番号も０であり得ることを意味する。これを行う方法は、テーブル作成ＤＤＬでpg_global表領域を使用することであり得る。例えば、create table sdb_shadow_catalog.pg_database (...) with oids tablespace pg_global;である。
【0068】
表領域は、データベースにおいて使用されない。ここでpg_globalの使用は、単に、新しい文法を発明することなく正しいストレージ鍵を得るためであり得る。
【0069】
シャドウカタログを作成するＤＤＬは、
コマンド出力からパースすることができる。pg_dumpはボックスの外部で機能しないことがあり、なぜならば、主キーが正しくダンプされておらず、ＬＳＭテーブルが主キーを必要とするためである。これは、カタログテーブルがpg_constraintテーブルに定義された主キー制約を有さないためであり得る。その結果、主キーは、一意インデックスとしてダンプすることができる。pg_dumpは、固定され得る。
【数1】
コマンド出力からパースすることができる。pg_dumpはボックスの外部で機能しないことがあり、なぜならば、主キーが正しくダンプされておらず、ＬＳＭテーブルが主キーを必要とするためである。これは、カタログテーブルがpg_constraintテーブルに定義された主キー制約を有さないためであり得る。その結果、主キーは、一意インデックスとしてダンプすることができる。pg_dumpは、固定され得る。
【数2】
【0070】
pg_tenant
【0071】
テーブルpg_tenantは、その形状が変わらない場合、シャドウカタログの一部でなくてもよく、なぜならば、それが不必要にテナント動作をブロックする可能性があるためである。これは、あらゆるカタログテーブルをコピーすることを要するsdbinstallを上回る、シャドウカタログアップグレードが有する利点の１つである。それが変わる稀なケースでは、それをシャドウテーブルに追加することができる。sdbinstallは、テナントダンピングを他スキーマのダンプから分離して、テナント動作をブロックするウィンドウを低減させることができる。他のＤＤＬファイルがシャドウスキーマにコピーされた後、システムは、テナントＤＤＬファイルを同様にブロックすることができる。次いで、pg_tenantを、同じ方法でシャドウスキーマにコピーすることができる。
【0072】
あるいは、開示される技術は、sfdcコアのカスタムオブジェクトのように、将来使用されるＮ個（例えば、３０個）のテキスト列を予め定義することにより、pg_tenantへの変更のないことを強制することができる。pg_tenantテーブルは、シャドウイングされ（shadowed）なくてもよい。しかしながら、インデックスが変更又は追加されるとき、このアプローチには複雑さがあり得る。シャドウテーブルは、インデックス変更を自動的にハンドリングすることができる。
【0073】
pg_statistic
【0074】
pg_statisticテーブルは、その形状が変わらないとしてもシャドウイングされる必要があり、なぜならば、そのanyarray型の列が、information_schema.sqlに定義されるいくつかの型について安定的でないpg_type.oidを含むためである。pg_statisticの詳細なハンドリング方法については、Anyarrayを参照する。
【0075】
pg_workflow
【0076】
ワークフローデータは、pg_workflow及びpg_workflow_tagsにあり得る。コントローラへのインポートは、sdbinstallと同じ直接ＤＭＬ文でハンドリングすることができる。アクティブなワークフローは、ストレージカタログにもあり得る。sdbinstallは、ｓｑｌ関数を使用して、ストレージカタログ内のワークフローをエクスポート及びインポートする。シャドウカタログは、それがインプレースアップグレードであるため、この動作を必要としない。ストレージカタログは、バージョニング（versioned）できる。第２のバージョンは、同じストレージカタログ（その中にワークフローを有する）を読み取り、最新のバージョンに変換することができ得る。
【0077】
現在、ワークフローを使用して、インデックスとテナントスナップショットを作成することができる。デフォルトでは、アップグレードの間、ワークフロー実行をブロックすることができ、なぜならば、それがシステムカタログを変更し、シャドウカタログを無効にする可能性があるためである。しかしながら、アップグレードの間、テナントスナップショットをブロックしないことが重要な可能性がある。pg_tenantと同じアプローチを用いることができる。ワークフローテーブルは、形状変更がない場合、シャドウイングされなくてもよい。
【0078】
シーケンス
pg_workflowid及びpg_lsmoidは、initdb時に作成できるカタログシーケンスである。それらのoid／relfilenodeは、安定的でない可能性がある。
pg_workflowid及びpg_lsmoidは、initdb時に作成できるカタログシーケンスである。それらのoid／relfilenodeは、安定的でない可能性がある。
【0079】
シャドウシーケンスを、これらに対して同様に作成する必要があり得る。
１． pg_dumpを強化して、シーケンス定義と現在の値を出力する。
２． シャドウシーケンスを作成し、現在の値をダンプからの同じ値に設定する。
３． シャドウテーブルと同様に、シーケンスに関してrelfilenodeを更新する。
１． pg_dumpを強化して、シーケンス定義と現在の値を出力する。
２． シャドウシーケンスを作成し、現在の値をダンプからの同じ値に設定する。
３． シャドウテーブルと同様に、シーケンスに関してrelfilenodeを更新する。
【0080】
relfilenodeが変わらないため、ユーザ定義シーケンスはユーザ定義テーブルと同様に使用することができる。しかしながら、重要な仮定は、シーケンスの記憶フォーマットが変わってはならない（又は、後方互換性の（backward compatible）必要がある）ことである。シーケンスは、開始値、増分等と最後の値などのシーケンスメタデータを記憶するいくつかのハードコーディングされた属性を有するログ構造マージ（ＬＳＭ）に単一のタプルとして記憶することができる。postgresが何らかの形でフォーマットを変更した場合、それはこのアップグレードを途絶させる。これは、ＰＧ１０で起こりうる。ＰＧ１０では、シーケンスレコードフォーマットが大きく変化する（いくつかの属性をデータレコードからpg_sequenceテーブルに移動している）。アップグレードが機能するためには、データベースは、pg_sequenceに移動する属性をダミー値としてデータレコードに保持することにより、ＰＧ１０から分かれることができる。
【0081】
ＤＤＬ無しモード
シャドウスキーマが作成された後、データベースは、ＤＤＬ無しモードに入ることができる。テナントは、依然として作成、修正、又は破棄することができる。このモードは、永続的であり得（template1の行のpg_database.datrmode列）、アプリ／バックエンド又はデーモンから全てのＤＤＬファイル（テナント作成／破棄を予期する）をブロックし得る。
シャドウスキーマが作成された後、データベースは、ＤＤＬ無しモードに入ることができる。テナントは、依然として作成、修正、又は破棄することができる。このモードは、永続的であり得（template1の行のpg_database.datrmode列）、アプリ／バックエンド又はデーモンから全てのＤＤＬファイル（テナント作成／破棄を予期する）をブロックし得る。
【0082】
同時に、ワークフローを同様に一時停止して、シャドウ内のコピーがオリジナルと正確に同じであることを確保することができる。
【0083】
スキーマダンプ及びリストア
pg_dumpallを使用して、シャドウカタログスキーマを除く全てのアプリスキーマをダンプすることができる。したがって、ダンプファイルがシャドウカタログにロードされたとき、シャドウカタログ情報が存在しない場合がある。例えば、pg_catalog.pg_classはsdb_shadow_catalog.pg_classの行を有するが、sdb_shadow_catalog.pg_classはそうではない。その結果、アップグレードの後、シャドウカタログメタデータをクリーンアップする必要がない場合がある。
pg_dumpallを使用して、シャドウカタログスキーマを除く全てのアプリスキーマをダンプすることができる。したがって、ダンプファイルがシャドウカタログにロードされたとき、シャドウカタログ情報が存在しない場合がある。例えば、pg_catalog.pg_classはsdb_shadow_catalog.pg_classの行を有するが、sdb_shadow_catalog.pg_classはそうではない。その結果、アップグレードの後、シャドウカタログメタデータをクリーンアップする必要がない場合がある。
【0084】
現在、pg_dumpallは、template0、template1、及びpostgresをダンプしない。これは、これらのデータベースへのいかなるカスタマイズもアップグレード後に持ち越され得ないことを意味する。
【0085】
データベースコアアプリからのスキーマダンプは、サイズが約１８０ＭＢであり得、コントローラに送信する前に２０ＭＢに圧縮することができる。テストでは、スキーマダンプはローカルで５０秒、異なるホストからダンプする場合に３分かかり得ることが示されている。dumpコマンドを実行するために、マスタへｓｓｈ接続する（ssh into）のがより良い可能性がある。
【0086】
ダンプファイルは、psqlによりコントローラ内で再生することができる。
【0087】
カタログデータのコピー
次に、copyコマンドを使用して、カタログテーブルデータを、第２のバージョンのコントローラから、あらゆるデータベースについて依然として第１のバージョンで動作しているデータベースクラスタ内のシャドウカタログにコピーする。oidは、テーブルがそれを有する場合、ＦＫ参照が有効なままであるように、維持することができる。
コントローラで
copy pg_class to “<filepath>” with oids;
マスタで
copy sdb_shadow_catalog.pg_class from “<filepath>” with oids;
次に、copyコマンドを使用して、カタログテーブルデータを、第２のバージョンのコントローラから、あらゆるデータベースについて依然として第１のバージョンで動作しているデータベースクラスタ内のシャドウカタログにコピーする。oidは、テーブルがそれを有する場合、ＦＫ参照が有効なままであるように、維持することができる。
コントローラで
copy pg_class to “<filepath>” with oids;
マスタで
copy sdb_shadow_catalog.pg_class from “<filepath>” with oids;
【0088】
開示される技術は、「copy to」において第２のバージョンから生成されるテキスト又はバイナリデータが「copy from」において第１のバージョンで正しく読み取れることを確保することができる。内部フォーマットと外部フォーマットの間で変換する<adt>in及び<adt>out関数は、複数リリースにわたりマッチしなければならない。copyコマンドのドキュメントは、バイナリ出力フォーマットの後方互換性を示している。開示される技術は、リーダ（マスタ）がより古いバージョンであるとき、前方互換性（forward compatibility）を要求することができる。テキストフォーマットを使用することができる。これは、特にanyarray、pg_node_tree、aclitemのような複雑なデータ型では、良好なテストを必要とするリスクのある領域の可能性がある。１つの簡易なテストは、第２のバージョンのコピー出力を第１のバージョンのコピー出力と比較することであり得る。
【0089】
pg_catalogテーブルにおける一意の列データ型のリスト
【数3】
【0090】
pg_statisticで使用されるAnyarray型は、扱いにくい可能性がある。それが任意の型であり得るため、そのテキスト出力は、型と後に続く配列値を識別するために、pg_type oidを有する。しかしながら、pg_type oidは、指定されたoidのない型、例えばinformation_schema.sqlで定義された型については、複数リリースにわたり安定的でない可能性がある。
【0091】
ソースからコントローラへ、同じ機能を現在のsdbinstallにより使用してダンプ及びロードすることができる。これらは、pg_load_column***関数であり得る。コントローラからの及びシャドウpg_statisticへのanyattrayデータのコピーは、そのデータをblobとして扱う必要があり得、何らかの特別なフォーマット及び検証を必要としない可能性がある。現在の挙動は、データを検証することができる。それは、型ｉｄミスマッチのため動作しない場合がある。
【0092】
解決策は、anyarrayデータをデフォルトでテキストにフォーマットしないことであり得る。代わりに、新しいグランドユニファイド構成（ＧＵＣ）を使用して、その出力フォーマットを制御することができる。アップグレードの場合、データは、base64エンコードすることができる。テーブルへのコピーは、その後、それをbase64デコードすることができる。
【0093】
配列
pg_catalogにはいくつかの配列型があり得る。１つのそのような配列はaclitem[]であり得る。aclitemのコピーイン／アウトは、ＰＧ１０において問題があった。aclitemは、pg_authidにおいてユーザに関連づけることができる。現在、ＰＧ１０は、pg_authidにデフォルト行を有する。その結果、コントローラからシャドウカタログへのコピーが失敗する可能性がある。
pg_catalogにはいくつかの配列型があり得る。１つのそのような配列はaclitem[]であり得る。aclitemのコピーイン／アウトは、ＰＧ１０において問題があった。aclitemは、pg_authidにおいてユーザに関連づけることができる。現在、ＰＧ１０は、pg_authidにデフォルト行を有する。その結果、コントローラからシャドウカタログへのコピーが失敗する可能性がある。
【0094】
解決策は、anyarray型と同様に、全ての配列データをbase64エンコードすることであり得る。
【0095】
新しい型
システムカタログへの新しいデータ型の導入は、２つのリリースで行うことができる。
１． 新しいデータ型とサポートする関数を追加する（例えば、copyコマンドにより使用されるin及びout関数など）。
２． カタログテーブルに追加する。
システムカタログへの新しいデータ型の導入は、２つのリリースで行うことができる。
１． 新しいデータ型とサポートする関数を追加する（例えば、copyコマンドにより使用されるin及びout関数など）。
２． カタログテーブルに追加する。
【0096】
不安定なデータベースoid
データベースがコントローラで再作成され、後にシャドウカタログにコピーされたとき、pg_database oidが変わる可能性がある。例えば、データベースsdbmainは、マスタに65555のoidを有し得る。コントローラでは、同じデータベースがoid67777を生成することができる。これは、データベース固有のサブフォルダがdb oidに因んで、例えば$pgdata/base/67777と名づけられるとき、pgdataレイアウトに問題を引き起こす可能性がある。第２のバージョンは、その予期されたフォルダがない（依然として$pgdata/base/65555である）とき、sdbmainに接続できない場合がある。これは、ユーザ定義データベースとビルトインデータベースtemplate0及びpostgres（template1は、１の固定oidを有する）の双方に影響する可能性がある。選択肢は、以下のとおりであり得る。
１． ３つのビルトインデータベースに対して安定的なidを有し、pg_dumpにおけるpg_database oidの固定化（nailing）をサポートする。これは、ユーザデータベースに対して機能する可能性があり、なぜならば、これらは、ダンプ及びリストアの間、常に再作成されるためである。template0、template1、及びpostgresは、これらがinitdbの間に生成されるため、ダンプされない。initdbの間、template0とpostgreに固定のidを割り当てることができる。これらの名前が固定oidを有することを保証するために、template0、template1、及びpostgresのリネーム／破棄をブロックすることができる。そうでなければ、これらはリネームでき、新しいデータベースをその名前で作成することができる（例えば、alter database template0 rename to foo; create database template0）。これが生じた場合、template0は、元々ビルトインデータベースに固定idが割り当てられていたとしても、不安定なoidを有する可能性がある。
データベースがコントローラで再作成され、後にシャドウカタログにコピーされたとき、pg_database oidが変わる可能性がある。例えば、データベースsdbmainは、マスタに65555のoidを有し得る。コントローラでは、同じデータベースがoid67777を生成することができる。これは、データベース固有のサブフォルダがdb oidに因んで、例えば$pgdata/base/67777と名づけられるとき、pgdataレイアウトに問題を引き起こす可能性がある。第２のバージョンは、その予期されたフォルダがない（依然として$pgdata/base/65555である）とき、sdbmainに接続できない場合がある。これは、ユーザ定義データベースとビルトインデータベースtemplate0及びpostgres（template1は、１の固定oidを有する）の双方に影響する可能性がある。選択肢は、以下のとおりであり得る。
１． ３つのビルトインデータベースに対して安定的なidを有し、pg_dumpにおけるpg_database oidの固定化（nailing）をサポートする。これは、ユーザデータベースに対して機能する可能性があり、なぜならば、これらは、ダンプ及びリストアの間、常に再作成されるためである。template0、template1、及びpostgresは、これらがinitdbの間に生成されるため、ダンプされない。initdbの間、template0とpostgreに固定のidを割り当てることができる。これらの名前が固定oidを有することを保証するために、template0、template1、及びpostgresのリネーム／破棄をブロックすることができる。そうでなければ、これらはリネームでき、新しいデータベースをその名前で作成することができる（例えば、alter database template0 rename to foo; create database template0）。これが生じた場合、template0は、元々ビルトインデータベースに固定idが割り当てられていたとしても、不安定なoidを有する可能性がある。
【0097】
２． 一代替策は、マスタにおけるtemplate0／postgres oidを見つけ出し、コントローラinit dbの間に同じoidを使用することであり得る。さらに、pg_dumpを強化して、ユーザ作成データベースについてpg_database.oidを固定化する。
【0098】
３． 上記のことに応じてpgdataフォルダを調整する。pgdataのコピーを作成し、oid変更にマッチするようにベースサブフォルダをリネームする。これは、単一ノードのアップグレードでは機能するが、マルチノードクラスタでは機能しない可能性がある。アップグレードの間、異なるコンテナは、異なるバージョンを一時的に有することができる。異なるバージョン間で異なるデータベースoidを有することは、問題を引き起こす可能性がある（例えば、db oidは、LsmLock、LsmInvalidateなどのxlogメッセージの一部である）。
【0099】
４． copyコマンドを調整してoidをリマッピングする。pg_database、pg_tenantにおける主キーに加え、データベースoidをpg_replication_slots.datoidで、可能性として他で、参照することができる。マイナス面は、既存／新規データベースのoid FK列を見落としやすいことであり得る。oidベクトル型は、ハンドリングが一層困難な可能性がある。
【0100】
Relfilenode及びマッピングファイル
この段階では、シャドウカタログテーブルが作成され、埋められ（populated）得る。
この段階では、シャドウカタログテーブルが作成され、埋められ（populated）得る。
【0101】
pg_catalog.pg_classにおけるサンプルデータ
【表1】
【0102】
sdb_shadow_catalog.pg_classにおけるマッチングデータ
【表2】
【0103】
関係の物理位置idは、大抵のテーブル及びインデックスについてはpg_class.relfilenode列に、及びブートストラップ関係の小さいセットについてはpg_filenode.mapファイルに記憶することができる。これらは一緒に、カタログを指定することができる。シャドウカタログが埋められた後、シャドウpg_classのrelfilenodeを更新することができる。
【数4】
【0104】
shadow_splice()と同様の新しい関数を使用して、pg_filenode.mapと同じディレクトリに、pg_filenode.map.shadowと呼ばれる第２のバージョンのpg_filenode.mapファイルを生成することができる。
【数5】
【0105】
このクエリは、あらゆる第２のバージョンによりマッピングされたカタログ関係（エイリアス o）を調べる。
１． シャドウテーブルが存在する（pg_tenant及びそのインデックスを除く全ての関係について真である）場合、マッパーファイルを更新してシャドウ関係の位置を使用することができる。
２． シャドウテーブル（pg_tenant）が存在しない場合、マッパーファイルの行は更新されない場合がある。pg_tenantのrelfilenodeはこれまで変わっていないという暗黙の仮定がある。
３． このクエリでハンドリングされない可能性のある一角のケースは、第２のバージョンがいくつかのマッピングされた関係を除去したときである。create_shadow_relmapperが、第１のバージョンのマッパーファイルを（上記ケース２が機能し得るように）開始点として使用するとき、第２のバージョンから除去された関係は、マッパーファイルから除去されなくてもよい。
１． シャドウテーブルが存在する（pg_tenant及びそのインデックスを除く全ての関係について真である）場合、マッパーファイルを更新してシャドウ関係の位置を使用することができる。
２． シャドウテーブル（pg_tenant）が存在しない場合、マッパーファイルの行は更新されない場合がある。pg_tenantのrelfilenodeはこれまで変わっていないという暗黙の仮定がある。
３． このクエリでハンドリングされない可能性のある一角のケースは、第２のバージョンがいくつかのマッピングされた関係を除去したときである。create_shadow_relmapperが、第１のバージョンのマッパーファイルを（上記ケース２が機能し得るように）開始点として使用するとき、第２のバージョンから除去された関係は、マッパーファイルから除去されなくてもよい。
【0106】
重要
シャドウイングされないテーブルでは、relfilenodeフィールドは決して変更されないと仮定することができる（現在はpg_tenantのみ）（例えば、pg_tenant relfilenodeは2619である。それが、これまでに第２のバージョンで、例えば3000に変更された場合、それは、実際のデータが2619にある一方で位置3000を見ることになる。これは、クリティカルな可能性がある。したがって、このために回帰テストを使用することができる。
シャドウイングされないテーブルでは、relfilenodeフィールドは決して変更されないと仮定することができる（現在はpg_tenantのみ）（例えば、pg_tenant relfilenodeは2619である。それが、これまでに第２のバージョンで、例えば3000に変更された場合、それは、実際のデータが2619にある一方で位置3000を見ることになる。これは、クリティカルな可能性がある。したがって、このために回帰テストを使用することができる。
【0107】
この関数は、新しいファイルをローカルに生成可能なだけであるため、ログレコードを作成せず、スタンバイで自動的に再生することができない。選択肢は、以下のとおりであり得る。
１． この関数を実行するために各コンテナに接続する。全てのスタンバイについて、関数を実行する前、ログが捕捉されるまで待つ必要があり得る（スタンバイにおけるpg_get_system_visible_xcnをマスタにおけるpg_get_session_snapshot_xcn()と比較することにより？）。
２． それをロギングし、それが全てのスタンバイで再生されるようにできる。ファイルは、正確に1024バイトであり得る。
３． 最初、第２のバージョンのコンテナを起動する前に、sdb_basebackupを行う。それは、ファイルをスタンバイに伝播するのに信頼することができる。しかしながら、マスタがクラッシュした場合、新しいマッパーファイルがそれと共に消失する可能性がある。また、ディザスタリカバリ（ＤＲ）スタンバイは、マッパーファイルを有さないＤＲマスタにのみ接続することができる。
４． ズーキーパー（zookeeper）であるが、各データセンタはその独自のズーキーパークラスタを有し、クロスデータセンタメッセージングを依然として必要とする。
１． この関数を実行するために各コンテナに接続する。全てのスタンバイについて、関数を実行する前、ログが捕捉されるまで待つ必要があり得る（スタンバイにおけるpg_get_system_visible_xcnをマスタにおけるpg_get_session_snapshot_xcn()と比較することにより？）。
２． それをロギングし、それが全てのスタンバイで再生されるようにできる。ファイルは、正確に1024バイトであり得る。
３． 最初、第２のバージョンのコンテナを起動する前に、sdb_basebackupを行う。それは、ファイルをスタンバイに伝播するのに信頼することができる。しかしながら、マスタがクラッシュした場合、新しいマッパーファイルがそれと共に消失する可能性がある。また、ディザスタリカバリ（ＤＲ）スタンバイは、マッパーファイルを有さないＤＲマスタにのみ接続することができる。
４． ズーキーパー（zookeeper）であるが、各データセンタはその独自のズーキーパークラスタを有し、クロスデータセンタメッセージングを依然として必要とする。
【0108】
開示される技術では、第２の選択肢が好ましい可能性がある。
【0109】
ここで重要な仮定は、マッピングファイルフォーマットが第１のバージョンと第２のバージョンの間で変わらないことであり得る。シャドウマッピングファイルが第１のバージョンから書かれるが、第２のバージョンにより使用されるため、フォーマットが変更された場合、第２のバージョンはファイルを読み取ることができない可能性がある。シャドウマッパーファイルは、pg_filenode.mapにリネームする前に、第２のバージョンのフォーマットに変換される必要があり得る。別個のコンバータ実行ファイルを使用することができる。
【0110】
コンテナベースのデプロイメントのためのsdbdocker repoにおいて、pgdataは、アップグレードにおいてクリーンに消去され、sdb_basebackupを使用してマスタに同期することにより再作成され得る。
【0111】
旧カタログのクリーニング
データベースコアは、例えば、１８０ＭＢのカタログデータを生成することができる。古いカタログデータは、このデータがもはや必要ないことが確実になった後、クリーンアップすることができる。最も早いそのような時間は、第２のバージョン上のマスタでアップグレードが成功裏に完了したときであり得る。その時間ではロールバックを禁止できるため、古いカタログは安全に削除することができる。
データベースコアは、例えば、１８０ＭＢのカタログデータを生成することができる。古いカタログデータは、このデータがもはや必要ないことが確実になった後、クリーンアップすることができる。最も早いそのような時間は、第２のバージョン上のマスタでアップグレードが成功裏に完了したときであり得る。その時間ではロールバックを禁止できるため、古いカタログは安全に削除することができる。
【0112】
古いカタログは、第２のバージョンが生じた後、即座に削除されるわけではない。このアプローチは、クラッシュハンドリングを簡素化することができ、フォレンジック的価値（forensic value）を有し得る。
・ 古いカタログの固定番号（例えば、２）を、各々がその独自のスキーマ、sdb_obsolete_catalog_<unix epoch timestamp>下で保持することができる。
・ アップグレードは、このようなスキーマの数が制限に達しているかどうかを最初にチェックする。そうである場合、アップグレードは最も古いスキーマを削除する。これは、古いカタログを実際に削除できるときである。
・ 命名規則付きの新しいスキーマを作成することができる。空の第１のバージョンのカタログテーブル／インデックス／シーケンスをその中に作成することができる。
・ Relfilenodeは、第２のバージョンのシャドウカタログとスワップすることができる。
アップグレードの前のpg_catalog.pg_classにおけるサンプル行
アップグレードの間のpg_catalog.pg_classにおけるサンプル行
Delete schema sdb_obsolete_catalog_1111111
Create schema sdb_obsolete_catalog_1111113, sdb_shadow_catalog
relfilenodeスワップ前のアップグレードの間のsdb_shadow_catalog.pg_classにおけるサンプル行
relfilenodeスワップ後のアップグレードの間のsdb_shadow_catalog.pg_classにおけるサンプル行
・ 古いカタログの固定番号（例えば、２）を、各々がその独自のスキーマ、sdb_obsolete_catalog_<unix epoch timestamp>下で保持することができる。
・ アップグレードは、このようなスキーマの数が制限に達しているかどうかを最初にチェックする。そうである場合、アップグレードは最も古いスキーマを削除する。これは、古いカタログを実際に削除できるときである。
・ 命名規則付きの新しいスキーマを作成することができる。空の第１のバージョンのカタログテーブル／インデックス／シーケンスをその中に作成することができる。
・ Relfilenodeは、第２のバージョンのシャドウカタログとスワップすることができる。
アップグレードの前のpg_catalog.pg_classにおけるサンプル行
【表3】
アップグレードの間のpg_catalog.pg_classにおけるサンプル行
Delete schema sdb_obsolete_catalog_1111111
Create schema sdb_obsolete_catalog_1111113, sdb_shadow_catalog
【表4】
relfilenodeスワップ前のアップグレードの間のsdb_shadow_catalog.pg_classにおけるサンプル行
【表5】
relfilenodeスワップ後のアップグレードの間のsdb_shadow_catalog.pg_classにおけるサンプル行
【表6】
【0113】
このアプローチは、複数の古いカタログを許可することができる。しかしながら、ダンプ及びロード時間は、各コピーにより線形に増加し得る。パフォーマンスのために、次のアップグレードまで、旧スキーマの１つのコピーのみを保持することができる。次のアップグレードが古いカタログを最初に破棄することができるため、pg_dump時間は悪影響を受けない可能性がある。１つだけコピーがあるため、スキーマ名にタイムスタンプサフィックスは必要なくてもよい。
【0114】
PG_CONTROL/PG-VERSION
PGDATA/global下のバイナリファイルpg_controlは、多くのフィールドを有することができる。２つのフィールド、pg_control_version及びcatalog_version_noが、アップグレードに重要である。postgresが開始するときに値をチェックすることができ、これらが実行ファイルにマッチしない場合、起動は失敗する。
PGDATA/global下のバイナリファイルpg_controlは、多くのフィールドを有することができる。２つのフィールド、pg_control_version及びcatalog_version_noが、アップグレードに重要である。postgresが開始するときに値をチェックすることができ、これらが実行ファイルにマッチしない場合、起動は失敗する。
【0115】
さらに、PGDATA下のPG_VERSIONテキストファイルと、各データベースサブディレクトリPGDATA/base/<dbID>が存在し得る。これらもまたチェックすることができる。
【0116】
したがって、既存のpgdataで第２のバージョンが実行される前に、これらのファイルを更新する必要があり得る。これは、pg_filenode.map.shadowのpg_filenode.mapへのリネームと同様であり得る。オーケストレータがこれをハンドリングすることができる。
１． 第１のバージョンのコンテナをシャットダウンする。
２． そのpgdataのコピーを、第２のバージョンが使用するために作成する（マスタからsdb_basebackupを実行することもできる）。
３． コピーにおいて
ａ． pg_filenode.map.shadowをpg_filenode.mapにリネームする
ｂ． PG_VERSIONファイル（コミュニティからのマージが行われるときはいつでも必要とされる）を更新する
ｃ． pg_control_versionとcatalog_version_no.を、以下で説明するようにストレージカタログに移動する。
２．マッチするpgdataにおいて第２のバージョンのコンテナをブートする。
１． 第１のバージョンのコンテナをシャットダウンする。
２． そのpgdataのコピーを、第２のバージョンが使用するために作成する（マスタからsdb_basebackupを実行することもできる）。
３． コピーにおいて
ａ． pg_filenode.map.shadowをpg_filenode.mapにリネームする
ｂ． PG_VERSIONファイル（コミュニティからのマージが行われるときはいつでも必要とされる）を更新する
ｃ． pg_control_versionとcatalog_version_no.を、以下で説明するようにストレージカタログに移動する。
２．マッチするpgdataにおいて第２のバージョンのコンテナをブートする。
【0117】
あるいは、pgdataは必要ない場合があり、必須データのみがストアカタログに移動されてもよい。
【0118】
ストレージカタログの変更
ストレージカタログに、システムカタログ番号とsdbバージョン番号を記憶することができる。
SDB_Version_Num 301079000
System_Catalog_Num 201802070
SDB_Version_Num 0
System_Catalog_Num 0
ストレージカタログに、システムカタログ番号とsdbバージョン番号を記憶することができる。
SDB_Version_Num 301079000
System_Catalog_Num 201802070
SDB_Version_Num 0
System_Catalog_Num 0
【0119】
値は、許可されたシステムカタログ番号であり得る。マッチするシステムカタログ番号を有するデータベース実行ファイルのみが起動することができる。アップグレードの間、クラスタが２つのデータベースバージョン（例えば、第２のバージョンでハイアベイラビリティ、第１のバージョンでマスタ）を実行している可能性があるため、２つのスロットが存在し得る。
・ initdbが、スロット１を現在のデータベース及びカタログバージョンでフィルする。
・ データベースサーバが開始されたとき、それは、そのカタログ番号をストレージカタログからの値を用いてチェックし、そのカタログ番号がシステムカタログ番号とマッチしない場合にエラー出力する。
・ アップグレードを行うとき、マスタは、他のスロットに第２のバージョンのカタログ番号を設定することができる。<catalog_number, release_number>は、アップグレードに固有でなければならない。
・ マスタが第２のバージョンで開始されたとき、それは、より古いカタログ番号を含むスロットをリセットする。
・ この変更は、より限定的なチェックを導入する。以前は、データベースバイナリ及びpgdataの互換性チェックは、ＰＧバージョン（例えば、９．６）とカタログバージョンに基づいている。これらは現在、データベースバージョンとカタログバージョンに基づいている。これは、（例えば、単にサーバを再起動する（bouncing）ことによる）直接ダウングレードをブロックする含みを有し得る。しかしながら、このようなアクションが望まれる場合、ストレージカタログにバージョンを追加するＳＱＬ関数がある。
・ initdbが、スロット１を現在のデータベース及びカタログバージョンでフィルする。
・ データベースサーバが開始されたとき、それは、そのカタログ番号をストレージカタログからの値を用いてチェックし、そのカタログ番号がシステムカタログ番号とマッチしない場合にエラー出力する。
・ アップグレードを行うとき、マスタは、他のスロットに第２のバージョンのカタログ番号を設定することができる。<catalog_number, release_number>は、アップグレードに固有でなければならない。
・ マスタが第２のバージョンで開始されたとき、それは、より古いカタログ番号を含むスロットをリセットする。
・ この変更は、より限定的なチェックを導入する。以前は、データベースバイナリ及びpgdataの互換性チェックは、ＰＧバージョン（例えば、９．６）とカタログバージョンに基づいている。これらは現在、データベースバージョンとカタログバージョンに基づいている。これは、（例えば、単にサーバを再起動する（bouncing）ことによる）直接ダウングレードをブロックする含みを有し得る。しかしながら、このようなアクションが望まれる場合、ストレージカタログにバージョンを追加するＳＱＬ関数がある。
【0120】
サマリ
シャドウカタログの作成ステップ
１． ソースデータベースがアップグレードされる条件にあることを検証する
２． コントローラを起動する
３． 特定のデータベースＤＤＬファイルの作成（create）／破棄（drop）／変更（alter）をブロックする
４． template0のdatallowconnを有効にする
５． ソース及びコントローラデータベースの双方においてワークフローを中断する。
６． sdb_shadow_catalogスキーマを第２のバージョンの構成（すなわち、形状）で作成する。
７． sdb_obsolete_catalogスキーマを第１のバージョンの構成（すなわち、形状）で作成する
８． 特定のＤＤＬファイル（テナントを除く）をブロックする
９． アプリスキーマをダンプする
１０． アプリスキーマをコントローラにロードする
１１． ソースからワークフローをダンプし、コントローラにロードする
１２． コントローラからのカタログテーブルをシャドウテーブルにコピーする
１３． テナント構成（形状）が変わった場合、テナントをダンプし、シャドウpg_tenantにロードする。
１４．シャドウpg_filenode.mapを生成し、カタログ関係についてsdb_shadow_catalog.pg_class内のrelfilenodeポインタを更新する
シャドウカタログの作成ステップ
１． ソースデータベースがアップグレードされる条件にあることを検証する
２． コントローラを起動する
３． 特定のデータベースＤＤＬファイルの作成（create）／破棄（drop）／変更（alter）をブロックする
４． template0のdatallowconnを有効にする
５． ソース及びコントローラデータベースの双方においてワークフローを中断する。
６． sdb_shadow_catalogスキーマを第２のバージョンの構成（すなわち、形状）で作成する。
７． sdb_obsolete_catalogスキーマを第１のバージョンの構成（すなわち、形状）で作成する
８． 特定のＤＤＬファイル（テナントを除く）をブロックする
９． アプリスキーマをダンプする
１０． アプリスキーマをコントローラにロードする
１１． ソースからワークフローをダンプし、コントローラにロードする
１２． コントローラからのカタログテーブルをシャドウテーブルにコピーする
１３． テナント構成（形状）が変わった場合、テナントをダンプし、シャドウpg_tenantにロードする。
１４．シャドウpg_filenode.mapを生成し、カタログ関係についてsdb_shadow_catalog.pg_class内のrelfilenodeポインタを更新する
【0121】
図１４は、開示される技術による、データベースを第１のバージョンから第２のバージョンにアップグレードするためのいくつかの動作の一例を示すフロー図である。
【0122】
図１５は、開示される技術による、シャドウカタログを作成する動作の一例を示すフロー図である。
【0123】
図１６は、開示される技術による、エラー及び信号ハンドリングのための動作の一例を示すフロー図である。
【0124】
テスト
カタログデータの正確性
カタログデータには、pg_catalogスキーマ下のあらゆるもの、形状と内容の双方を含むことができる。これは、新たにインストールされたデータベース及びアップグレードされたデータベースからのpg_dump出力をチェックすることによりテストすることができる。
１． 第１のバージョンをインストールし、第１のバージョンのいくつかのスキーマをセットアップし、アップグレードを実行する。
２． 第２のバージョンで新しいデータベースをインストールし、同じスキーマをセットアップする
３． カタログスキーマをpg_dump --schema=pg_catalogで、及びアプリスキーマをpg_dumpall --schema-onlyで、双方のバージョンからダンプし、比較する。これらは同じであるべきである。
カタログデータの正確性
カタログデータには、pg_catalogスキーマ下のあらゆるもの、形状と内容の双方を含むことができる。これは、新たにインストールされたデータベース及びアップグレードされたデータベースからのpg_dump出力をチェックすることによりテストすることができる。
１． 第１のバージョンをインストールし、第１のバージョンのいくつかのスキーマをセットアップし、アップグレードを実行する。
２． 第２のバージョンで新しいデータベースをインストールし、同じスキーマをセットアップする
３． カタログスキーマをpg_dump --schema=pg_catalogで、及びアプリスキーマをpg_dumpall --schema-onlyで、双方のバージョンからダンプし、比較する。これらは同じであるべきである。
【0125】
データの正確性
アップグレードは、ユーザテーブルデータに触れない。このテストは、relfilenodeが変更されていないことを確認し、いくつかのテストテーブルをダンプすることができる。
アップグレードは、ユーザテーブルデータに触れない。このテストは、relfilenodeが変更されていないことを確認し、いくつかのテストテーブルをダンプすることができる。
【0126】
制限
アップグレードが終了した後、制限モード、ワークフローの一時停止、及びtemplate0の接続性は全て、オリジナル値に戻されるべきである。これらは、アップグレードが成功したとき及びアップグレードが失敗したときにテストすることができる。
アップグレードが終了した後、制限モード、ワークフローの一時停止、及びtemplate0の接続性は全て、オリジナル値に戻されるべきである。これらは、アップグレードが成功したとき及びアップグレードが失敗したときにテストすることができる。
【0127】
古いカタログの削除
アップグレードの前、カタログ関係のためにrelfilenodeを保存する。アップグレードの後、そのようなrelfilenodeがログ構造マージ（ＬＳＭ）にデータを有さないことをチェックする。
アップグレードの前、カタログ関係のためにrelfilenodeを保存する。アップグレードの後、そのようなrelfilenodeがログ構造マージ（ＬＳＭ）にデータを有さないことをチェックする。
【0128】
失敗ケース
アップグレードは、何らかの失敗があったとき、中止することができる。いくつかの失敗ケースには、以下を含むことができる。
１． マスタクラッシュ
２． コントローラクラッシュ
３． マスタステータス消失
４． ネットワーク／ディスクエラー
５． アップグレードスクリプト／オーケストレータクラッシュ
アップグレードは、何らかの失敗があったとき、中止することができる。いくつかの失敗ケースには、以下を含むことができる。
１． マスタクラッシュ
２． コントローラクラッシュ
３． マスタステータス消失
４． ネットワーク／ディスクエラー
５． アップグレードスクリプト／オーケストレータクラッシュ
【0129】
アップグレードスクリプトは、データベース制限モード（ｄｄｌ無し、ｄｂ無し、テナント無しなど）を終了し、template0の接続設定を戻そうとする。しかしながら、マスタがクラッシュしたとき、そのようにすることが常に可能ではない可能性がある。オペレータは、データベースが戻った後、２つの選択肢を有する。
・ クリーンアップ関数を呼び出して制限モードから出る（一構成において、これは、マスタが開始され／プロモートされ（promoted）たときにいつでも自動的に行うことができる）。
・ アップグレードをリトライする。ログとアーチファクト（例えば、部分的に完成したシャドウカタログなど）は、問題の診断に使用することができる。
・ クリーンアップ関数を呼び出して制限モードから出る（一構成において、これは、マスタが開始され／プロモートされ（promoted）たときにいつでも自動的に行うことができる）。
・ アップグレードをリトライする。ログとアーチファクト（例えば、部分的に完成したシャドウカタログなど）は、問題の診断に使用することができる。
【0130】
アプリテスト
一連のアプリテスト（現在プリチェックイン）がアップグレードの前後に実行され、アップグレード後の失敗したテストがアップグレード前の失敗のサブセットであることを確認する。プリチェックインより包括的なスイート（例えば、ベーシックなftests）の方がより良い可能性がある。
一連のアプリテスト（現在プリチェックイン）がアップグレードの前後に実行され、アップグレード後の失敗したテストがアップグレード前の失敗のサブセットであることを確認する。プリチェックインより包括的なスイート（例えば、ベーシックなftests）の方がより良い可能性がある。
【0131】
パフォーマンステスト
１ アップグレード自体以外のテスト。これは、アップグレードされたデータベースがパフォーマンス劣化を有さないことをテストできる。
１ アップグレード自体以外のテスト。これは、アップグレードされたデータベースがパフォーマンス劣化を有さないことをテストできる。
【0132】
２ アップグレード自体のテスト
アプリ開発者特有のテスト
１． 複数のアプリ分岐（例えば、214、main）
２． ソースバージョン（301.84）としてアップグレードによりサポートされるあらゆるデータベースバージョンのテスト
３． データベースAnt/bltターゲット
ａ． sdb.start
ｂ． sdb.stop
ｃ． sdb.ngupgrade
ｄ． sdb.ngupgrade_maybe
ｅ． sdb.rollback_ngupgrade
４． OSXとUbuntuの双方
５． 破壊テスト
ａ． アップグレードが失敗したとき、ユーザは依然として第１のバージョンのデータベースを使用することができる。
６． 旧データエクステントのクリーニング
ａ． アップグレードの間、sdb_basebackupをデータベースのバックアップに使用できるため、旧データは、もはや必要ないとき削除することができる。
アプリ開発者特有のテスト
１． 複数のアプリ分岐（例えば、214、main）
２． ソースバージョン（301.84）としてアップグレードによりサポートされるあらゆるデータベースバージョンのテスト
３． データベースAnt/bltターゲット
ａ． sdb.start
ｂ． sdb.stop
ｃ． sdb.ngupgrade
ｄ． sdb.ngupgrade_maybe
ｅ． sdb.rollback_ngupgrade
４． OSXとUbuntuの双方
５． 破壊テスト
ａ． アップグレードが失敗したとき、ユーザは依然として第１のバージョンのデータベースを使用することができる。
６． 旧データエクステントのクリーニング
ａ． アップグレードの間、sdb_basebackupをデータベースのバックアップに使用できるため、旧データは、もはや必要ないとき削除することができる。
【0133】
バックアップ
アップグレード又は新しい第２のバージョンのバイナリのいずれかから、データ破損の可能性があるため、更新の直前にデータベースをバックアップすることが重要であり得る。sdb_basebackupを使用してバックアップを作成することができる。sfstoreで、クローンオプションを使用することができる。それは、最新のログエクステントをコピーするだけでよいため、一層速い可能性がある。pgfilestore上のアプリｄｅｖでは、より高速なクローンオプションは機能しない可能性がある。より遅いバックアップオプションは、全てのデータ／ログエクステントをコピーすることができる。バックアップは、アップグレードの開始時に、シャドウカタログの作成と同時に実行することができる。ＳＳＤを用いたｄｅｖボックスのテストは、バックアップスループットが約１ＧＢ／１０秒、又は、シャドウカタログの作成に要する時間が６０ＧＢ（約１０分）であることを示している。
アップグレード又は新しい第２のバージョンのバイナリのいずれかから、データ破損の可能性があるため、更新の直前にデータベースをバックアップすることが重要であり得る。sdb_basebackupを使用してバックアップを作成することができる。sfstoreで、クローンオプションを使用することができる。それは、最新のログエクステントをコピーするだけでよいため、一層速い可能性がある。pgfilestore上のアプリｄｅｖでは、より高速なクローンオプションは機能しない可能性がある。より遅いバックアップオプションは、全てのデータ／ログエクステントをコピーすることができる。バックアップは、アップグレードの開始時に、シャドウカタログの作成と同時に実行することができる。ＳＳＤを用いたｄｅｖボックスのテストは、バックアップスループットが約１ＧＢ／１０秒、又は、シャドウカタログの作成に要する時間が６０ＧＢ（約１０分）であることを示している。
【0134】
ＰＧ１０の課題
ＰＧ１０の変更のいくつかは、シャドウカタログのアップグレードを乱す可能性がある。問題と解決策のリストには、以下を含むことができる。
１．新しいpg_dataレイアウト：それは、pg_clogをpg_xactに、pg_xlogをpg_walにリネームする。解決策：古いpgdata内の同じディレクトリをリネームする。
２． pg_controlファイルフォーマットの変更。新しいセキュリティフィールドmock_authentication_nonceが追加されている。解決策：pg_controlファイルをアップグレードできる新しいバイナリを作成する。
３． xlogページのマジックナンバーの変更。postgresは、あらゆるメジャーリリースでマジックナンバーを変更するようである。postgresは、新しいバイナリを古いデータベース上で実行したくない。解決策：次世代のアップグレードが、同じxlogファイルを使用できる。xlogページのマジックナンバーは、安定的に保たれる必要はない。これは、短期的なフィックスであり、該フィックスは、次のコミュニティリリースでxlogフォーマットが変更された場合、問題を提示する可能性がある。長期的な解決策は、コミュニティxlogと、より大きいコンテキストではpgdataディレクトリ全体を取り除くことであり得る。データベースは、ほとんどの場合、コミュニティxlogを使用しない。データベースは、postgresから継承された特定のレコード（例えば、db shutdown）を依然として書き込む。
４． 新しいカタログデータ型。これは、一般に、postgres及び新しいリリースバリア（release barrier）からの新しい型の入念な選択（cherry-picking）の必要があり得る。解決策：ＰＧ１０の場合、新しい型、pg_ndistict及びpg_dependenciesは、bytea型にキャストできる。
５． 新しいデフォルトロール。いくつかのカタログ列は、aclitem[]型である。aclitemは、そのin/out関数でロール名を検証する。これは、aclitemがＰＧ１０からダンプされ、ＰＧ９．６で受け入れられない可能性があるとき、アップグレードを乱す可能性がある。解決策：コピーコマンドで直接、生バイトをbase64エンコード／デコードすることができる。これには、全ての配列型を含むことができる。これにより、検証をスキップすることができ、これは、データが第２のバージョンのバイナリにより使用されることが意図されているため、受け入れ可能である
ＰＧ１０の変更のいくつかは、シャドウカタログのアップグレードを乱す可能性がある。問題と解決策のリストには、以下を含むことができる。
１．新しいpg_dataレイアウト：それは、pg_clogをpg_xactに、pg_xlogをpg_walにリネームする。解決策：古いpgdata内の同じディレクトリをリネームする。
２． pg_controlファイルフォーマットの変更。新しいセキュリティフィールドmock_authentication_nonceが追加されている。解決策：pg_controlファイルをアップグレードできる新しいバイナリを作成する。
３． xlogページのマジックナンバーの変更。postgresは、あらゆるメジャーリリースでマジックナンバーを変更するようである。postgresは、新しいバイナリを古いデータベース上で実行したくない。解決策：次世代のアップグレードが、同じxlogファイルを使用できる。xlogページのマジックナンバーは、安定的に保たれる必要はない。これは、短期的なフィックスであり、該フィックスは、次のコミュニティリリースでxlogフォーマットが変更された場合、問題を提示する可能性がある。長期的な解決策は、コミュニティxlogと、より大きいコンテキストではpgdataディレクトリ全体を取り除くことであり得る。データベースは、ほとんどの場合、コミュニティxlogを使用しない。データベースは、postgresから継承された特定のレコード（例えば、db shutdown）を依然として書き込む。
４． 新しいカタログデータ型。これは、一般に、postgres及び新しいリリースバリア（release barrier）からの新しい型の入念な選択（cherry-picking）の必要があり得る。解決策：ＰＧ１０の場合、新しい型、pg_ndistict及びpg_dependenciesは、bytea型にキャストできる。
５． 新しいデフォルトロール。いくつかのカタログ列は、aclitem[]型である。aclitemは、そのin/out関数でロール名を検証する。これは、aclitemがＰＧ１０からダンプされ、ＰＧ９．６で受け入れられない可能性があるとき、アップグレードを乱す可能性がある。解決策：コピーコマンドで直接、生バイトをbase64エンコード／デコードすることができる。これには、全ての配列型を含むことができる。これにより、検証をスキップすることができ、これは、データが第２のバージョンのバイナリにより使用されることが意図されているため、受け入れ可能である
【0135】
ローリングアップグレード
ローリングアップグレードは、プライマリで開始することができる。
１．第１のバージョンのスタンバイコンテナを停止する（コンテナ内のpgdataがホストにマウントされ、シャットダウン後に一時ディレクトリに移動され得る）。
２． 同じノードで第２のバージョンのコンテナを開始する。
ａ． sdb_basebackupからシャドウrelmapperファイルを取得することができる（そうでない場合、スタンバイが追い付き、ログレコードからシャドウrelmapperを作成する必要があり得る）。
ｂ． シャドウrelmapperファイルをpg_filenode.mapにリネームできる。
３． 上記の動作は、全てのスタンバイに対して繰り返すことができる。
４． プライマリが停止され、スタンバイにフェイルオーバできる。
５． 新たにプロモートされた第２のバージョンのマスタが、そのバージョンでログレコードを作成できる。スタンバイは、スタンバイバージョンがより古い場合、ログ再生を一時停止できる。
６． 古いプライマリは、スタンバイとして再起動できる。プライマリサイトが実行可能である。
７． 上記動作は、ディザスタリカバリ（ＤＲ）サイトで繰り返すことができる。
ローリングアップグレードは、プライマリで開始することができる。
１．第１のバージョンのスタンバイコンテナを停止する（コンテナ内のpgdataがホストにマウントされ、シャットダウン後に一時ディレクトリに移動され得る）。
２． 同じノードで第２のバージョンのコンテナを開始する。
ａ． sdb_basebackupからシャドウrelmapperファイルを取得することができる（そうでない場合、スタンバイが追い付き、ログレコードからシャドウrelmapperを作成する必要があり得る）。
ｂ． シャドウrelmapperファイルをpg_filenode.mapにリネームできる。
３． 上記の動作は、全てのスタンバイに対して繰り返すことができる。
４． プライマリが停止され、スタンバイにフェイルオーバできる。
５． 新たにプロモートされた第２のバージョンのマスタが、そのバージョンでログレコードを作成できる。スタンバイは、スタンバイバージョンがより古い場合、ログ再生を一時停止できる。
６． 古いプライマリは、スタンバイとして再起動できる。プライマリサイトが実行可能である。
７． 上記動作は、ディザスタリカバリ（ＤＲ）サイトで繰り返すことができる。
【0136】
アップグレード後
アップグレード後のアクションには、以下を含むことができる。
・ ＤＤＬ無しモードを終了する
・ 古いカタログを削除する
・ 任意の確認を実行する
アップグレード後のアクションには、以下を含むことができる。
・ ＤＤＬ無しモードを終了する
・ 古いカタログを削除する
・ 任意の確認を実行する
【0137】
エラーハンドリング
この新しいアップグレードの最初のロールアウトは、アプリ開発者向けであり得る。初期実装は、pythonでもよい。pythonのアップグレードスクリプトは、サーバのリブートを含むプロセス全体をハンドリングすることができ、sdbinstallベースのsdbアップグレードを置き換えることができる。
この新しいアップグレードの最初のロールアウトは、アプリ開発者向けであり得る。初期実装は、pythonでもよい。pythonのアップグレードスクリプトは、サーバのリブートを含むプロセス全体をハンドリングすることができ、sdbinstallベースのsdbアップグレードを置き換えることができる。
【0138】
アップグレード中の任意の時点で、失敗やクラッシュがあり得る。クラッシュは、スクリプトが予期せず実行を停止したとき（例えば、パワーダウンなど）、又はデータベースに接続できないとき（例えば、ネットワークの問題、シャットダウン）であり得る。このような場合、スクリプトはクリーンアップ作業を実行できない。失敗には、クリーンアップが可能な全ての他のケースを含むことができる。失敗は自動的にハンドリングでき、一方、クラッシュは、ant targetを呼び出すことによる手動クリーンアップを必要とする場合がある。（一構成において、クリーンアップは、手動クリーンアップを必要としないように、sdb.startで呼び出すことができる）。
シャドウカタログ作成において
アーチファクト：
１． スキーマ：sdb_shadow_catalog、sdb_obsolete_catalog
２． Template0.datallowconn設定
３． データベース制限モード（pg_database.rmode）
４． ワークフロー一時停止モード
５． コントローラsdbインスタンス
失敗：上記動作２、３、４、及び５をアンドゥする（undo）。スキーマは損傷なく保たれ、次の実行中にクリーンアップされ得る。
クラッシュ：ユーザは、ant targetを呼び出して、動作２、３、及び４（現在、sdb.start ant targetの一部）をアンドゥすることができる。アップグレードコントローラは、それが依然として実行中の場合、手動でシャットダウンされる必要がある。一構成において、データベースはこれを自動的に行うことができる。
サーバ再起動において
アクション：
１． 第１のバージョンをフラッシュする
２． 新規リリース番号をストアカタログに追加する
３． 第１のバージョンを停止する
４． 第２のバージョンのために第１のバージョンのpgdataをコピーする（cp ~/sdb/sdbdata/<cluuid> ~/sdb/sdbdata/<cluuid>_v2）。sdb_basebackupを使用する場合、第１のバージョンからクローンされたpgdataが既に存在し得る。
５． 第２のバージョンのpgdataを更新する（relmapperファイル、PG_VERSIONファイル、及びpostgresql.confファイル）
６． 第２のバージョンを開始する
エラーハンドリングは、シャドウカタログ作成と同じでもよい。
アップグレード後
アクション：
７． 任意で、ストアカタログから古いリリース番号を除去する。
８． コントローラを停止する（非同期、結果を無視）
９． 現在のバイナリとpgdataシンボリックリンク（symlink）の双方を更新する。これは、呼び出し元（ant）により、pythonスクリプトの外部で管理することができる。
ａ． ~/sdb/sdbbuild/current
ｂ． ~/sdb/sdbbuild/current.previous
ｃ． ~/sdb/sdbdata/sdbmain
ｄ． ~/sdb/sdbdata/sdbmain.previous
クラッシュ：
動作７の前／間：ストレージカタログ内のリリース番号を除去することはクリティカルではない。
動作８の前／間：コントローラは実行中のままにすることができる。ユーザはそれを手動で停止する必要があり得る。
シャドウカタログ作成において
アーチファクト：
１． スキーマ：sdb_shadow_catalog、sdb_obsolete_catalog
２． Template0.datallowconn設定
３． データベース制限モード（pg_database.rmode）
４． ワークフロー一時停止モード
５． コントローラsdbインスタンス
失敗：上記動作２、３、４、及び５をアンドゥする（undo）。スキーマは損傷なく保たれ、次の実行中にクリーンアップされ得る。
クラッシュ：ユーザは、ant targetを呼び出して、動作２、３、及び４（現在、sdb.start ant targetの一部）をアンドゥすることができる。アップグレードコントローラは、それが依然として実行中の場合、手動でシャットダウンされる必要がある。一構成において、データベースはこれを自動的に行うことができる。
サーバ再起動において
アクション：
１． 第１のバージョンをフラッシュする
２． 新規リリース番号をストアカタログに追加する
３． 第１のバージョンを停止する
４． 第２のバージョンのために第１のバージョンのpgdataをコピーする（cp ~/sdb/sdbdata/<cluuid> ~/sdb/sdbdata/<cluuid>_v2）。sdb_basebackupを使用する場合、第１のバージョンからクローンされたpgdataが既に存在し得る。
５． 第２のバージョンのpgdataを更新する（relmapperファイル、PG_VERSIONファイル、及びpostgresql.confファイル）
６． 第２のバージョンを開始する
エラーハンドリングは、シャドウカタログ作成と同じでもよい。
アップグレード後
アクション：
７． 任意で、ストアカタログから古いリリース番号を除去する。
８． コントローラを停止する（非同期、結果を無視）
９． 現在のバイナリとpgdataシンボリックリンク（symlink）の双方を更新する。これは、呼び出し元（ant）により、pythonスクリプトの外部で管理することができる。
ａ． ~/sdb/sdbbuild/current
ｂ． ~/sdb/sdbbuild/current.previous
ｃ． ~/sdb/sdbdata/sdbmain
ｄ． ~/sdb/sdbdata/sdbmain.previous
クラッシュ：
動作７の前／間：ストレージカタログ内のリリース番号を除去することはクリティカルではない。
動作８の前／間：コントローラは実行中のままにすることができる。ユーザはそれを手動で停止する必要があり得る。
【0139】
ロールバック
ロールバックは、第２のバージョン又はアップグレードスクリプト自体に重大な問題がある場合に許可され得る。アップグレードスクリプトは、データベースをバックアップすることができる（sdb_basebackup clone/backup cmd）。バックアップ後の変更は失われる。
ロールバックは、第２のバージョン又はアップグレードスクリプト自体に重大な問題がある場合に許可され得る。アップグレードスクリプトは、データベースをバックアップすることができる（sdb_basebackup clone/backup cmd）。バックアップ後の変更は失われる。
【0140】
自動稼働データベース（ＳＤＤＢ）インターフェース
シャドウカタログアップグレードの本番ロールアウトは、自動稼働データベース（self-driving database、ＳＤＤＢ）フレームワーク上に構築することができる。
シャドウカタログアップグレードの本番ロールアウトは、自動稼働データベース（self-driving database、ＳＤＤＢ）フレームワーク上に構築することができる。
【0141】
各状態遷移において、ワークフローオーケストレータは、アップグレードチームにより実装された「関数（function）」を呼び出すことができる。
【0142】
これらの機能は、ＳＤＤＢ repoのGoパッケージで実装することができる。それらは、ＳＤＤＢオーケストレータにコンパイルすることができる。関数は、第２のバージョンにマッチしなければならないpsql、pg_dump、pg_dumpallなどのsdbバイナリと、標準のlinuxコマンド（cp、cat、awk、及びsed）を呼び出すことができる。オーケストレータが動作しているホストは、psqlでデータベースサーバに接続できるべきである。
【0143】
いずれかの関数がエラーを返した場合、ワークフローを（クリーンアップの後に）中止することができる。
【0144】
次世代（next gen）のアップグレードは、現在のpythonスクリプトとgoパッケージの双方で維持されるべきでないため、オーケストレータは、アプリ開発者環境で同様にアップグレードをハンドリングできる。開発者環境におけるアップグレードは、本番環境とかなり異なる可能性がある（コンテナvs非コンテナ、単一ノードvsハイアベイラビリティ（ＨＡ）／ディザスタリカバリ（ＤＲ）など）。一構成において、単一のオーケストレータを構築して双方をハンドリングすることができる。別の構成において、アプリ開発者環境をハンドリングするために別のgoバイナリを作成することができる。シャドウカタログの作成は、双方のアプローチに共通し得る。
【0145】
ステップの詳細
アップデートステップは、２つの場所、すなわち、（１）アップグレードバイナリ／オーケストレータ、及び（２）アップグレードコントローラで、論理的に実行できる。自動稼働データベースコントローラは、gRPCを介してアクセス可能な長期実行プロセスであり得る。したがって、オーケストレータは、gRPCによりコントローラと通信することができる。短期的には、コントローラは、ＳＤＢイメージにない可能性がある。アプリｄｅｖのために設計されたアップデートバイナリでは、それは、コントローラコードを単一バイナリとしてコンパイルすることができる。
エントリ基準チェック
ワーク
・ データベースバージョンがシャドウカタログアップグレードをサポートするほど十分に新しいことをチェックする。
・ データベースバージョンがターゲットバージョンより古いことをチェックし、そうである場合、ダウングレードは許されない。
・ ソースバージョンとターゲットバージョンの間にリリースバリアがないことをチェックする。
・ 同時アップグレードを防止するために、データベース制限モードが明確であることを確認する。
Ｃｍｄ：validateMaster
アクタ：アップグレードバイナリ／オーケストレータ。あるいは、マスタデータベースのコントローラでもよい。
ステップ１：sdb_basebackupを並列に実行する
ワーク：sdb_basebackupをサポートする必要がある場合、postgresql.conf及びpg_hba.confを更新する。sdb_basebackupを実行する。
アクタ：アップグレードバイナリ／オーケストレータ。
ステップ２：アップグレードコントローラを作成する
アップデートステップは、２つの場所、すなわち、（１）アップグレードバイナリ／オーケストレータ、及び（２）アップグレードコントローラで、論理的に実行できる。自動稼働データベースコントローラは、gRPCを介してアクセス可能な長期実行プロセスであり得る。したがって、オーケストレータは、gRPCによりコントローラと通信することができる。短期的には、コントローラは、ＳＤＢイメージにない可能性がある。アプリｄｅｖのために設計されたアップデートバイナリでは、それは、コントローラコードを単一バイナリとしてコンパイルすることができる。
エントリ基準チェック
ワーク
・ データベースバージョンがシャドウカタログアップグレードをサポートするほど十分に新しいことをチェックする。
・ データベースバージョンがターゲットバージョンより古いことをチェックし、そうである場合、ダウングレードは許されない。
・ ソースバージョンとターゲットバージョンの間にリリースバリアがないことをチェックする。
・ 同時アップグレードを防止するために、データベース制限モードが明確であることを確認する。
Ｃｍｄ：validateMaster
アクタ：アップグレードバイナリ／オーケストレータ。あるいは、マスタデータベースのコントローラでもよい。
ステップ１：sdb_basebackupを並列に実行する
ワーク：sdb_basebackupをサポートする必要がある場合、postgresql.conf及びpg_hba.confを更新する。sdb_basebackupを実行する。
アクタ：アップグレードバイナリ／オーケストレータ。
ステップ２：アップグレードコントローラを作成する
【0146】
アップグレードコントローラは、コンテナ内で実行できる。自動稼働データベースオーケストレータは、そのドッカーイメージをダウンロードし、それを開始することができる。アップグレードコントローラは、ロギングの無効化、バイナリアップグレードモードなど、いくつかの一般的でない構成パラメータを必要とする。コンフィグファイルはイメージの一部である。
アプリＤｅｖは、コンテナを使用しない。
Ｃｍｄ：setupController
アクタ：アップグレードバイナリ／オーケストレータ
ステップ２．１：アップグレードコントローラを検証する
プレースホルダ
ステップ３：論理データベースの作成を無効にする
ワーク
・ db DDLをブロック
Ｃｍｄ：BlockDbDDL
アクタ：アップグレードコントローラ
ステップ４：Ｖ１（マスタ）及びＶ２（コントローラ）からカタログ情報を取得する
ワーク
・ pg_catalog、information_schema、インスペクタスキーマ情報を取得
Ｃｍｄ：GetCatalogInfo
アクタ：アップグレードコントローラ
ステップ５：データベース接続を有効にし、ワークフローを一時停止する
ワーク
・ template0接続を有効化（マスタ及びアップグレードコントローラの双方）
・ ワークフローを一時停止（マスタ及びアップグレードコントローラの双方）
Ｃｍｄ：EnableDBConnectionSuspendWorkflow
アクタ：アップグレードコントローラ
ステップ６：シャドウカタログスキーマを作成する
ワーク
・ スキーマsdb_shadow_catalog及びsdb_obsolete_catalogを作成
Ｃｍｄ：CreateShadowSchemaDef
アクタ：アップグレードコントローラ
ステップ７：ＤＤＬを無効にする
Ｃｍｄ：restrict_ddl
アクタ：アップグレードコントローラ
ステップ８：シャドウカタログデータを作成する
ワーク
・ ソースからスキーマをpg_dumpall
・ アップグレードコントローラへpsql load
・ コントローラからファイルへコピー
・ ファイルからソースシャドウテーブルへコピー
・ シャドウカタログシーケンスを同期
・ pg_tenantが形状を変更した場合、テナントをダンプし、ロード
・ シャドウスキーマ内のrelfilenodeを更新
・ シャドウrelmapperファイルを生成
Ｃｍｄ：createShadowSchemaData
アクタ：アップグレードコントローラ
ステップ９：アップグレードコントローラを停止する
Ｃｍｄ：stopController()
アクタ：アップグレードバイナリ／オーケストレータ
ステップ１０．ａ：マスタ（アプリＤＥＶ）をリブートする
ワーク
・ フラッシュ
・ ストレージカタログへ新規リリースを追加
・ シャドウrelmapperファイルをリネーム
・ bkproxyをリブート
・ 第２のバージョンをサニティチェック
Ｃｍｄ：rebootMaster
アクタ：アップグレードバイナリ
ステップ１０．ｂ：第１のバージョンのコンテナをシャットダウンし、第２のバージョンのコンテナを起動する。
アクタ：オーケストレータ（シャドウrelmapperをリネームする必要がある）
ステップ１１：制限モードを終了する
ワーク
・ データベース制限モードをクリア
・ template0接続を無効化
・ （ワークフロー一時停止モードは持続されなくてもよい）
Ｃｍｄ：clear_restriction
アクタ：アップグレードバイナリ／オーケストレータ
ステップ１２：クリーンアップする
ワーク
・ 古いカタログを削除
・ ストレージカタログから古いリリースを除去す
・ アップグレードコントローラをシャットダウン
Ｃｍｄ：clean_up
アクタ：アップグレードバイナリ／オーケストレータ
Ｇｏｌａｎｇ ｐｒｏｔｏｔｙｐｅ
アプリＤｅｖは、コンテナを使用しない。
Ｃｍｄ：setupController
アクタ：アップグレードバイナリ／オーケストレータ
ステップ２．１：アップグレードコントローラを検証する
プレースホルダ
ステップ３：論理データベースの作成を無効にする
ワーク
・ db DDLをブロック
Ｃｍｄ：BlockDbDDL
アクタ：アップグレードコントローラ
ステップ４：Ｖ１（マスタ）及びＶ２（コントローラ）からカタログ情報を取得する
ワーク
・ pg_catalog、information_schema、インスペクタスキーマ情報を取得
Ｃｍｄ：GetCatalogInfo
アクタ：アップグレードコントローラ
ステップ５：データベース接続を有効にし、ワークフローを一時停止する
ワーク
・ template0接続を有効化（マスタ及びアップグレードコントローラの双方）
・ ワークフローを一時停止（マスタ及びアップグレードコントローラの双方）
Ｃｍｄ：EnableDBConnectionSuspendWorkflow
アクタ：アップグレードコントローラ
ステップ６：シャドウカタログスキーマを作成する
ワーク
・ スキーマsdb_shadow_catalog及びsdb_obsolete_catalogを作成
Ｃｍｄ：CreateShadowSchemaDef
アクタ：アップグレードコントローラ
ステップ７：ＤＤＬを無効にする
Ｃｍｄ：restrict_ddl
アクタ：アップグレードコントローラ
ステップ８：シャドウカタログデータを作成する
ワーク
・ ソースからスキーマをpg_dumpall
・ アップグレードコントローラへpsql load
・ コントローラからファイルへコピー
・ ファイルからソースシャドウテーブルへコピー
・ シャドウカタログシーケンスを同期
・ pg_tenantが形状を変更した場合、テナントをダンプし、ロード
・ シャドウスキーマ内のrelfilenodeを更新
・ シャドウrelmapperファイルを生成
Ｃｍｄ：createShadowSchemaData
アクタ：アップグレードコントローラ
ステップ９：アップグレードコントローラを停止する
Ｃｍｄ：stopController()
アクタ：アップグレードバイナリ／オーケストレータ
ステップ１０．ａ：マスタ（アプリＤＥＶ）をリブートする
ワーク
・ フラッシュ
・ ストレージカタログへ新規リリースを追加
・ シャドウrelmapperファイルをリネーム
・ bkproxyをリブート
・ 第２のバージョンをサニティチェック
Ｃｍｄ：rebootMaster
アクタ：アップグレードバイナリ
ステップ１０．ｂ：第１のバージョンのコンテナをシャットダウンし、第２のバージョンのコンテナを起動する。
アクタ：オーケストレータ（シャドウrelmapperをリネームする必要がある）
ステップ１１：制限モードを終了する
ワーク
・ データベース制限モードをクリア
・ template0接続を無効化
・ （ワークフロー一時停止モードは持続されなくてもよい）
Ｃｍｄ：clear_restriction
アクタ：アップグレードバイナリ／オーケストレータ
ステップ１２：クリーンアップする
ワーク
・ 古いカタログを削除
・ ストレージカタログから古いリリースを除去す
・ アップグレードコントローラをシャットダウン
Ｃｍｄ：clean_up
アクタ：アップグレードバイナリ／オーケストレータ
Ｇｏｌａｎｇ ｐｒｏｔｏｔｙｐｅ
【0147】
Ｇｏ言語（Golang）バージョンは、データベースとは別個に、ＳＤＤ repoに構築することができる。バイナリは、1.0.0から始まるバージョン情報を出力する--versionフラグをサポートすることができる。Ｇｏ言語は、クロスプラットフォームコンパイルをサポートすることができる。ビルドスクリプトは、linux及びosxバイナリ（例えば、全てamd64）をビルドし、ＳＤＢソースツリーにチェックインすることができる。ＳＤＢビルドスクリプトは、正しいバイナリをそのビルドフォルダに選び取ることができる。
【0148】
ＳＤＤは、各ngupgradeリリースについて分岐することができる。
【0149】
ログ再生後方互換
マスタが依然として第１のバージョン上にあり、スタンバイが第２のバージョンにアップグレードされたとき、スタンバイは、第１のバージョンのバイナリにより生成されたログを再生することができる。
マスタが依然として第１のバージョン上にあり、スタンバイが第２のバージョンにアップグレードされたとき、スタンバイは、第１のバージョンのバイナリにより生成されたログを再生することができる。
【0150】
関連する一要件は、データベーススタンバイインスタンスが、それがバージョン変更を検出した場合、ログ再生を一時停止することに関し得る。ハイアベイラビリティ（ＨＡ）では、スタンバイを最初にアップグレードすることができる。しかしながら、ディザスタリカバリ（ＤＲ）インスタンスは、プライマリから独立してアップグレードすることができる。ディザスタリカバリ（ＤＲ）の前にプライマリがアップグレードされた場合、ディザスタリカバリ（ＤＲ）は第２のバージョンのログを見ることになる。ＤＲは、それがアップグレードされるまで、これらを処理すべきでない。
【0151】
最適化
カタログテーブルが変更されない限り（スキーマ及びビルトインデータ）、シャドウテーブルを作成する必要はない可能性がある。これは、pg_tenantでは特に重要であり得る。必要に応じて、pg_workflow及びpg_statisticsなど、いくつかの簡易なテーブルを同様にハンドリングすることができる。
カタログテーブルが変更されない限り（スキーマ及びビルトインデータ）、シャドウテーブルを作成する必要はない可能性がある。これは、pg_tenantでは特に重要であり得る。必要に応じて、pg_workflow及びpg_statisticsなど、いくつかの簡易なテーブルを同様にハンドリングすることができる。
【0152】
アップグレードに関する推奨
pgdataの変更を回避する
・ relmapperファイル
・ pg_controlファイル
pgdataの変更を回避する
・ relmapperファイル
・ pg_controlファイル
【0153】
新しいカタログデータ型を回避する
・ ステージングを要する可能性あり
・ ステージングを要する可能性あり
【0154】
pg_tenantの変更を回避する
・ ＤＤＬロックを免除
・ アップグレードはorgサインアップをブロック不可
・ ＤＤＬロックを免除
・ アップグレードはorgサインアップをブロック不可
【0155】
サマリ
第２のバージョンのバイナリとマッチするシャドウカタログ
・ 多数のポインタ（relfilenode）操作
第２のバージョンのバイナリとマッチするシャドウカタログ
・ 多数のポインタ（relfilenode）操作
【0156】
解決される問題
・ 付加的な本番ＳＫＵデータベースサーバが不要
○ オーケストレーションノードで実行される軽量データベースインスタンスを使用
・ ディザスタリカバリ（ＤＲ）をアップグレードする時間を短縮
○ シャドウカタログはプライマリサイトに１つ作成され、ディザスタリカバリ（ＤＲ）に複製される
・ 付加的な本番ＳＫＵデータベースサーバが不要
○ オーケストレーションノードで実行される軽量データベースインスタンスを使用
・ ディザスタリカバリ（ＤＲ）をアップグレードする時間を短縮
○ シャドウカタログはプライマリサイトに１つ作成され、ディザスタリカバリ（ＤＲ）に複製される
【0157】
アプリ開発
第２のバージョンをリブートする前にデータベースをバックアップする
第２のバージョンをリブートする前にデータベースをバックアップする
【0158】
第２のバージョンでデータベースをリブートするまでの失敗
・ 第２のバージョンのイメージでのみ使用できるシャドウカタログ
・ 前に失敗した実行から残った任意のアーチファクトを後の実行でクリーンアップ可能
・ 第２のバージョンのイメージでのみ使用できるシャドウカタログ
・ 前に失敗した実行から残った任意のアーチファクトを後の実行でクリーンアップ可能
【0159】
第２のバージョンでデータベースをリブートする
・ 第１のバージョンをシャットダウン
・ 第２のバージョンのrelmapperファイルをプロモート
・ pg_versionファイルを更新
・ postgresql.confファイルを更新
・ 修正されたpgdataにおいて第２のバージョンをアップ
・ 第１のバージョンをシャットダウン
・ 第２のバージョンのrelmapperファイルをプロモート
・ pg_versionファイルを更新
・ postgresql.confファイルを更新
・ 修正されたpgdataにおいて第２のバージョンをアップ
【0160】
sdb_basebackupを--type=backupで使用して、リブートプロセスの前に第１のバージョンをバックアップする
・ --type=backup
○ tarストリームを通じて、スナップショットからのエクステント、ストレージカタログ、及びPGDATA下のファイルを送る
○ ストリームからバックアップPGDATAへファイルを抽出する
○ 全てのエクステントを新しいエクステントｉｄで作成する
○ リマッピングされたエクステントｉｄへの参照を含む新しいＣＬＵＵＩＤを有する新しいストレージカタログを作成する
・ 将来：--type=clone
・ 問題：pgfilestoreにおいて、データベースは同じストアを使用する他のインスタンスを認識しない
・ ＳＳＤにおいて、１ＧＢのデータとフルのアプリスキーマでは、backupオプションでのsdb_basebackupは、１．５～２分かかる
テスト
・ 同じバージョンアップグレードを行う：
○ データが損われておらず、ＤＤＬ及びＤＭＬを実行できることを確かめる
○ ストレージカタログ及びシャドウrelmapperファイル内のリリース番号がディザスタリカバリ（ＤＲ）に複製されていることを確かめる
・ アプリ実行状態でのsdb.ngupgrade：
○ ngupgradeをワークロードとして、チャッタ（chatter）ワークロードと同時に実行する
○ sfstoreを使用する
・ ftstsを伴うsdb.ngupgrade：
○ ngupgradeの前後でftestsを実行する
○ ngupgradeでエラーが発生したとき、第１のバージョン又は第２のバージョンいずれかのデータベースが動作しているかをチェックする
・ sdb.ngupgrade_clean：
○ 全てのデータベース制限モードはオフにすべきである
○ template0はアクセスを許可すべきでない
・ sdb.rollback_ngupgrade
○ ロールバックの後、前のバージョンのデータベースが動作しているべきである
○ ロールバック後、シンボリックリンクが変更される
・ --type=backup
○ tarストリームを通じて、スナップショットからのエクステント、ストレージカタログ、及びPGDATA下のファイルを送る
○ ストリームからバックアップPGDATAへファイルを抽出する
○ 全てのエクステントを新しいエクステントｉｄで作成する
○ リマッピングされたエクステントｉｄへの参照を含む新しいＣＬＵＵＩＤを有する新しいストレージカタログを作成する
・ 将来：--type=clone
・ 問題：pgfilestoreにおいて、データベースは同じストアを使用する他のインスタンスを認識しない
・ ＳＳＤにおいて、１ＧＢのデータとフルのアプリスキーマでは、backupオプションでのsdb_basebackupは、１．５～２分かかる
テスト
・ 同じバージョンアップグレードを行う：
○ データが損われておらず、ＤＤＬ及びＤＭＬを実行できることを確かめる
○ ストレージカタログ及びシャドウrelmapperファイル内のリリース番号がディザスタリカバリ（ＤＲ）に複製されていることを確かめる
・ アプリ実行状態でのsdb.ngupgrade：
○ ngupgradeをワークロードとして、チャッタ（chatter）ワークロードと同時に実行する
○ sfstoreを使用する
・ ftstsを伴うsdb.ngupgrade：
○ ngupgradeの前後でftestsを実行する
○ ngupgradeでエラーが発生したとき、第１のバージョン又は第２のバージョンいずれかのデータベースが動作しているかをチェックする
・ sdb.ngupgrade_clean：
○ 全てのデータベース制限モードはオフにすべきである
○ template0はアクセスを許可すべきでない
・ sdb.rollback_ngupgrade
○ ロールバックの後、前のバージョンのデータベースが動作しているべきである
○ ロールバック後、シンボリックリンクが変更される
【0161】
図１７は、データベースを第２のバージョンにアップグレードするための従来の動作の一例を示す図である。
【0162】
図１８は、開示される技術による、データベースを第２のバージョンにアップグレードする動作の別の例を示す図である。
【0163】
図１９は、pg_classの一例を示す図である。
【0164】
図２０は、Relmapperファイルの一例を示す図である。
【0165】
図２１は、Relfilenodeの一例を示す図である。
【0166】
図２２は、開示される技術による、データベースを第２のバージョンにアップグレードする動作のさらに別の例を示す図である。
【0167】
図２３は、pg_catalog.pg_classにおけるサンプルデータの一例を示す図である。
【0168】
図２４は、開示される技術による、データベースを第２のバージョンにアップグレードする動作のさらに別の例を示す図である。
【0169】
図２５は、シャドウカタログへのコピー後のpg_catalog.pg_classにおけるサンプルデータの一例を示す図である。
【0170】
図２６は、Relfilenodeスワップの一例を示す図である。
【0171】
図２７は、シャドウカタログアップグレードの一例を示す図である。
【0172】
図２８は、ハイアベイラビリティ（ＨＡ）アップグレードの一例を示す図である。
【0173】
図２９は、ディザスタリカバリ（ＤＲ）アップグレードの一例を示す図である。
【0174】
図３０は、シンボリックリンクの管理の一例を示す図である。
【0175】
図３１は、リブート直前のシンボリックリンクの管理の一例を示す図である。
【0176】
図３２は、リブート後のシンボリックリンクの管理の一例を示す図である。
【0177】
データベースを第１のバージョンから第２のバージョンにアップグレードする様々な実装は、コンピュータにより実装されたプロセス及びこれらのプロセスを実施する装置の形態を含み、あるいは該形態で実装することができる。また、実装は、フロッピーディスケット、コンパクトディスク読取専用メモリ（ＣＤ－ＲＯＭ）、ハードドライブ、ユニバーサルシリアルバス（ＵＳＢ）ドライブ、又は任意の他のマシン読取可能記憶媒体などの非一時的及び／又は有形媒体に実装された命令を含むコンピュータプログラムコードを有するコンピュータプログラムプロダクトの形態で実施することができ、コンピュータプログラムコードがコンピュータにロードされ、コンピュータにより実行されたとき、コンピュータは、データベースを第１のバージョンから第２のバージョンにアップグレードする実装を実施する装置になる。
【0178】
また、実装は、例えば、記憶媒体に記憶され、コンピュータにロードされ、及び／又はコンピュータにより実行されるか、あるいは電気配線若しくはケーブル接続を通じて、光ファイバを通じて、又は電磁放射を介してなどで何らかの伝送媒体を通じて伝送されるかにかかわらず、コンピュータプログラムコードの形態で実施することができ、コンピュータプログラムコードがコンピュータにロードされ、コンピュータにより実行されたとき、コンピュータは、データベースを第１のバージョンから第２のバージョンにアップグレードする実装を実施する装置になる。
【0179】
汎用マイクロプロセッサ上に実装されたとき、コンピュータプログラムコードセグメントが、特定の論理回路を作り出すようにマイクロプロセッサを構成する。いくつかの構成において、コンピュータ読取可能記憶媒体に記憶されたコンピュータ読取可能命令のセットは、汎用プロセッサにより実施することができ、これは、汎用プロセッサ又は汎用プロセッサを含むデバイスを、命令を実施又は実行するように構成された専用デバイスに変換することができる。
【0180】
実装は、ハードウェア及び／又はファームウェアにおける開示される主題事項の実装による手法の全部又は一部を実施する汎用マイクロプロセッサ及び／又は特定用途向け集積回路（ＡＳＩＣ）などの、プロセッサを含み得るハードウェアを使用して実施することができる。プロセッサは、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、フラッシュメモリ、ハードディスク、又は電子情報を記憶することができる任意の他のデバイスなどのメモリに結合することができる。メモリは、データベースを第１のバージョンから第２のバージョンにアップグレードする手法を実行するために、プロセッサにより実行されるように適合された命令を記憶することができる。
【0181】
上述の記載は、説明の目的で、特定の実装を参照して記載された。しかしながら、上記の例示的な議論は、網羅的であること、又は開示される主題事項の実装を開示された正確な形態に限定することを意図したものではない。上記の教示を考慮し、多くの修正及びバリエーションが可能である。実装は、開示される主題事項の実装の原理及びそれらの実際の適用を説明し、それにより、当業者がそれらの実装と企図された特定の用途に適し得る様々な修正を備えた様々な実装を利用できるように選択され、記載されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
