復元点を明確にして注文を保存する

PostgreSQLBeginner
オンラインで実践に進む

はじめに

PAPER & FORM は紙のプリントとデスク用品を販売しています。別サービスへの移行を前に、店主はバックアップからどの注文を戻せるか正確に知る必要があります。ファイルがあるだけでは不十分です。明確な復元点の各注文と商品明細が含まれていなければなりません。

小さな注文を作成し、PostgreSQL カスタム形式でバックアップを保存した後、もう1件注文を追加して、それが保存済みバックアップに入らない理由を確認します。基本的なターミナル操作ができれば十分です。データベース、ツール、サイトは準備済みで、SQL の作成やソフトウェアのインストールは不要です。顧客、価格、注文はすべて架空で、決済やメールのサービスはありません。

稼働中の店舗は Original Shop、コマンドは Workstation で操作します。Restored Copy は次のラボで使う独立した空のターゲットです。この単元では復元しないでください。各単元は専用のデータから始まります。提供プログラムと uploads/ を変更しないでください。これは論理データベースのエクスポート演習で、完全な災害復旧や特定時点への復旧(PITR)ではありません。

バックアップに含める注文を記録する

このステップでは商品明細を持つ実際の注文を記録します。まず Original Shop を開きます。青い帯に元のデータベース shop_source が表示されます。Explore the collection ↗ を開いてください。Print pair は1点 $18.00、Desk tray は1点 $26.00 です。上部の Orders から R-101 を選び、明細を読みます。Print pair が2点で合計 $36.00 です。Download receipt ↓ を選び、保存されたテキストを読みます。番号、顧客、商品、数量、合計が含まれます。PAPER & FORM で戻ってください。

データベースは構造化されたレコードを保存します。ここでは orders が注文番号と顧客を、order_items が商品明細行を保存します。各明細は親の注文に関連付けられています。顧客名や合計だけを保存すると、店舗が必要とする関連が失われます。詳細ページと領収書は、実際に関連付けられた行を読みます。

Workstation に切り替えます。pwd は作業ディレクトリ、ls はその中のファイルを表示します。

pwd
/home/labex/project/shop-backup
ls

backups、shopctl、uploads があるはずです。エクスポートは backups/ に保存します。uploads/packing-note.txt はこの作業とは無関係なので変更しないでください。論理エクスポートにはデータベース外のファイルは入りません。

./shopctl は現在のディレクトリにある提供済みヘルパーを実行します。identity は実際の接続を表示します。ロールは権限を決めるデータベースのアカウントです。ホストとポートがサービスの接続先を識別します。実行してください。

./shopctl identity

ソース shop_source の読み取り専用クライアントロール d09_reader と、ターゲット shop_copy の書き込み可能ロール d09_copy を確認します。どちらも 127.0.0.1:5432 です。同じサーバーでも同じデータベースとは限りません。コピーロールはソースには接続できません。サイトは別のソース書き込みロールを使います。これは演習での操作境界であり、システム管理者に対する防御ではありません。

Original Shop の Collection を開き、Place an order までスクロールします。送信前に Writing to: shop_source · ORIGINAL SHOP を読み、次の値を正確に入力します。

フィールド 値
Reference R-103
Name Rae
Item Print pair
Quantity 2

Place order ↗ を選びます。R-103、Rae、Print pair が2点、合計 $36.00 のレコードが開きます。これがバックアップに含める区切りの注文です。元のフォームは未知の番号やコピー専用番号を拒否し、レコードを書き込みません。有効で保護された cutoff-kept.dump を保存する前の R-104 も Keep the earlier point first で拒否され、何も書き込まれません。R-103 のつもりだった場合は Collection に戻り、番号を直してください。この保護は演習に必要なレコード順序のためです。本番店舗が通常バックアップ完了まで注文を待つわけではありません。既存の R-103 の顧客、商品、数量を間違えた場合は、Workstation でその指定練習レコードだけを修正できます。

./shopctl correct source R-103

ヘルパーは実際の接続先を表示し、R-103 だけを Rae / Print pair / 2 に直します。元の初期レコード番号は拒否し、他の注文、後続レコード、アップロード、すべてのアーカイブを保ちます。これは学習者が明示的に行う修正で、チェックが代行する処理ではありません。修正して再確認してからエクスポートしてください。繰り返しクリックして番号が既存の場合は Already recorded になります。重複送信せず Orders でレコードを開いて確認します。

Workstation に戻ります。records は実際に関連するデータを表示します。最後の数値は数量とセント単位の単価です。

./shopctl records source

R-103 | Rae | Print pair | 2 | 1800 と、3件合計 $98.00 を確認します。元の R-101、R-102 を変更せず、必要な注文を追加できました。

一貫したカスタム形式アーカイブを保存する

このステップでは確定済みの3件の注文を保存します。復元点とはエクスポートが捕捉したデータベースの状態で、ファイル名や更新時刻ではありません。PostgreSQL の pg_dump は一貫したスナップショットを作ります。他のユーザーが操作していても、関連するテーブルを同じデータベースの見え方で保存します。この演習では、R-103 を完了してからエクスポートし、終了を待って次の注文を追加します。この順序なら時計を比較せず区切りを明確にできます。

Workstation のまま進めます。pg_dump はデータベースをエクスポートし、pg_restore はそのアーカイブ形式を読みます。クライアントのバージョンを確認してください。

pg_dump --version
pg_restore --version

準備済み環境では、両方とも PostgreSQL 14 と表示されます。サーバーも14です。古い pg_dump と新しいサーバーの組み合わせは失敗することがあります。空ファイルを保存してバージョンエラーをごまかさないでください。本ラボには対応するツールが用意されています。

ソースを選ぶ前に接続をもう一度表示します。

./shopctl identity

PostgreSQL の接続サービスは保存済みの接続設定です。service=shop-source は shop_source と読み取り専用ロールを、service=shop-copy は独立ターゲットを選びます。--dbname がその接続を指定します。クライアントの既定値に頼らず、サービスを毎回明示してください。

--format=custom は通常の SQL テキストではなく、pg_restore が必要な PostgreSQL の圧縮アーカイブを作ります。--file は出力名です。--no-privileges はソースの権限付与を省きます。カスタムアーカイブでは pg_dump --no-owner は無視されます。所有権を省くには、後の pg_restore で --no-owner を指定します。この復元オプションによって、復元オブジェクトをターゲットロールが所有できます。次のコマンドはソースを読み、指定したローカルバックアップファイルだけに書き込みます。

pg_dump --dbname=service=shop-source --format=custom --no-privileges --file=backups/cutoff.dump

成功すると通常は何も表示されません。終了するまで次の業務注文を入力しないでください。接続やファイルのエラーが出たら、pwd、./shopctl identity、出力パスを確認して再試行します。再実行は backups/cutoff.dump を置き換えるため、ソースがまだ目的の区切り状態のときだけ行ってください。後のエクスポートには後のデータが入ります。

pg_restore --list はインポートせずアーカイブの目次を読みます。

pg_restore --list backups/cutoff.dump

最初の方で Format: CUSTOM、dbname: shop_source と対応するサーバー/クライアントのバージョンを確認します。その下に orders、order_items、データ、シーケンス、制約の項目があります。これは構造の説明であり、正しい業務行が含まれる証明ではありません。実際に復元して行を読む方が強い証拠です。

チェックでは実際のアーカイブを新しい破棄可能なデータベースで試し、区切りの注文と商品関連を検証します。Restored Copy タブを復元する処理ではありません。次のステップのためにアーカイブを保ってください。

次へ進む前にチェック結果を読み、確認済みアーカイブを保管します。cp は別名でファイルをコピーします。chmod a-w はすべてのユーザーから書き込み権限を外し、pg_dump --file による誤った上書きから両方の名前を守ります。

cp backups/cutoff.dump backups/cutoff-kept.dump
chmod a-w backups/cutoff.dump backups/cutoff-kept.dump

バックアップのチェックに合格した後にだけ実行してください。以後、保護ファイルへの直接エクスポートは復元点を置き換えず Permission denied で失敗します。元のファイル名を消した場合は cp backups/cutoff-kept.dump backups/cutoff.dump で元のバイトを取り戻せます。保管ファイルは通常の間違いへの2つ目のローカルコピーで、オフサイトの災害対策ではありません。

後続の注文と保存した復元点を区別する

このステップではソースが先へ進む一方、保存したアーカイブが以前の状態を保つことを確認します。Original Shop の Collection を開き、書き込み前に Writing to: shop_source · ORIGINAL SHOP を読みます。次を送信してください。

フィールド 値
Reference R-104
Name Sol
Item Desk tray
Quantity 1

新しいレコードは合計 $26.00 です。Orders で R-101、R-102、R-103、R-104 を確認します。R-104 は pg_dump 終了後に確定したため、backups/cutoff.dump には入りません。バックアップは注文を受け取り続けるライブ接続ではありません。今は区切りアーカイブを再エクスポートで上書きしないでください。

Workstation でソースを再び読みます。

./shopctl records source

出力に R-104 | Sol | Desk tray | 1 | 2600 が加わり、合計は $124.00 になります。ソースは利用可能なままです。復元を演習するために業務データを壊したわけではありません。アーカイブをもう一度一覧にすると、元の構造が表示されます。

pg_restore --list backups/cutoff.dump

アーカイブのチェックは破棄可能なテスト用データベースにだけ復元します。R-101 から R-103 を含み、R-104 を含まない状態が必要です。これが単なるファイルの存在ではなく復元点を証明します。この単元では Restored Copy を空のままにします。

R-104 を間違えた場合、./shopctl correct source R-104 はソースを表示し、その既存練習注文だけを Sol / Desk tray / 1 に修正します。以前のレコードはすべて保たれます。未知の番号はフォームで拒否されるので、番号を直して再送してください。

cutoff.dump を誤って削除、置換したら、新しい未来のスナップショットではなく保管した過去のバイトから回復します。Workstation で chmod u+w を使うと、その1ファイルの所有者に書き込み権限を戻せます。次に cp で内容を戻し、chmod a-w で再び保護します。

chmod u+w backups/cutoff.dump
cp backups/cutoff-kept.dump backups/cutoff.dump
chmod a-w backups/cutoff.dump

ファイルを削除した場合は最初のコマンドを省き、保管コピーから直接戻してください。その後アーカイブのチェックを再実行します。R-104 を削除したりソースを巻き戻したりしないでください。後続の業務レコードは残す必要があります。過去の復元点のコピーをすべて失った場合、新しい論理エクスポートで過去を再現することはできません。前のステップが、ソースを先へ進める前に保護したコピーを検証、保管するのはそのためです。次の独立ラボでは同じ区切りアーカイブが用意され、安全な復元に集中できます。

まとめ

実際に注文を作成し、一貫性のある PostgreSQL カスタム形式アーカイブをエクスポートして、保存した復元点と後続のソース注文を区別しました。アーカイブのチェックでは、破棄可能なデータベースに実際に復元した関連を検証しました。次の独立したラボでは、保存した状態を使える店舗コピーとして開きます。