Gitプロジェクトは4月20日（現地時間）、Git 2.54のリリースを発表した。同バージョンには、137人以上のコントリビューターによる多くの新機能や修正が含まれている。
今回のリリースの注目点の1つは、新たに追加されたコマンド「git history」だ。これは、コミットメッセージの修正やコミットの分割といったシンプルな履歴の書き換えを容易に行うもので、ワーキングツリーやインデックスを変更せずに、対象コミットの履歴を書き換えることができる。「git history reword」でメッセージを書き換えたり、「git history split」でコミットを分割できるが、マージコミットを含む履歴には対応していない。
また、これまで個別のスクリプト配置が必要だったGitフックの実行コマンドを、設定ファイルから柔軟に定義できるようになった。これにより、ユーザー単位やローカル、システム全体の設定でフックを一括管理でき、同一イベントに対し複数フックも実行可能となった。従来のフックスクリプトも引き続き利用できる。
⇧ 何と言うか、「多機能」になるのは構わないのだが、「ユースケース」とかハッキリしないと厳しいのよね...
とりあえず、
⇧ 上記の記事でも触れたのだが、「Git」の「設計」は「責務」の問題を抱えていそうなのよね...
一般的に、
KISSの原則 (キスのげんそく、英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
ソフトウェア開発
KISSの原則に反して、仕様が徐々に複雑化していくことは、ソフトウェア開発の世界でよくみられる。これは、「なし崩しの機能追加主義」として知られる。
ソフトウェアが複雑になるにつれて、使い方を習得する時間が増えたり、操作に手間取ったり、どれが重要な機能なのか分からなくなったりする。さらには、ハードウェアへの要求スペックが高くなったり製品価格が高くなったりもする。しかし、大多数のユーザーが実際に使用する機能は、そのごく一部であったりする。ユーザへの負担や開発コストを考えると、単純なソフトウェアの方がユーザフレンドリかつ生産性が高い可能性がある。
単一責任の原則 (たんいつせきにんのげんそく、英: single-responsibility principle) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある。
単一責任の原則は、ロバート・C・マーティンによって定義された。この原則について、彼は、「クラスを変更する理由は、ひとつだけであるべきである」と表し、「変更する理由」に関して、「この原則は、人についてのものである」と述べ、アクターについてのものであると補足した。
⇧ 上記にあるように、「役割」を持たせ過ぎるのは、後々「カオス」に至ることになりかねないので、避けるべきではあるはずなのよね...
まぁ、「コンポーネント」単位に「機能」を集約させる「アプローチ」もあるので、悩ましいところなのだが...
兎にも角にも、「ユーザーフレンドリー」な「設計」を意識して欲しいお気持ちです...
ストリーミングレプリケーション構成のPostgreSQLのバージョンアップ手順が知りたかったが...
とりあえず、
⇧ 公式の「ドキュメント」によると、「pg_upgrade」で実現できそうな感じなのだが、いまいち、
- Primary
- Replica
のどちらの作業なのかが分かり辛いので、「ChatGPT」氏に整理してもらった。
📌 ストリーミングレプリケーション構成のPostgreSQLのバージョンアップ手順
| Step | 作業内容 | Primary | Replica | 備考 |
|---|---|---|---|---|
| 1 | 🟡 事前バックアップ取得 | ◎ | 任意 | 公式には強制ではないが実務必須 |
| 2 | PostgreSQL 15 インストール | ◎ | ◎ | pg_upgrade前提条件 |
| 3 | 新クラスタ initdb | ◎ | × | 公式手順に明記あり |
| 4 | pg_upgrade --check | ◎ | × | 公式手順に明記あり |
| 5 | 🟡 サービス停止（全ノード） | ◎ | ◎ | 公式は単一ノード前提 |
| 6 | 🟡 LSN（Log Sequence Number）同期確認 | ◎ | ◎ | レプリケーション特有の運用要件 |
| 7 | pg_upgrade 実行 | ◎ | × | 公式手順の中核 |
| 8 | analyze スクリプト実行 | ◎ | × | 公式で推奨されている |
| 9 | 新Primary起動 | ◎ | × | 手順上必須 |
| 10 | 🟡 レプリケーション設定準備 | ◎ | × | 公式は触れていない |
| 11 | 🟡 replication slot作成 | ◎ | × | 再作成が必要（非明示） |
| 12 | 🟡 basebackup取得 | ◎（提供） | ◎（実行） | Replica再構築手順 |
| 13 | 🟡 standby.signal / 設定 | × | ◎ | レプリカ再構成の実務 |
| 14 | 🟡 Replica起動 | × | ◎ | 公式の対象外 |
| 15 | 🟡 レプリケーション確認 | ◎ | ◎ | 運用チェック |
✅ 🟡の意味（重要）
🟡のマークが付いているものは：
pg_upgrade単体の公式手順には出てこない- ただし
- レプリケーション構成では必須
- 実務ではほぼ省略不可
✅ 特に重要な🟡（優先度高）
中でもミスりやすい順：
- LSN同期確認
- Replica再作成（
pg_basebackup） - replication slot再作成
- 全ノード停止タイミング
✅ 実務的な理解
- 公式 = 「ツールの使い方」
- 🟡部分 = 「壊さないための運用設計」
✅ なぜ差分が出るのか（整理）
公式ドキュメントのスコープ：
pg_upgrade = 単一クラスタのアップグレード手順
あなたのケース：
Primary + Replica = 分散構成の整合性維持
👉 この差分が🟡部分
📌 切り戻し手順
| Step | 作業内容 | Primary | Replica | 備考 |
|---|---|---|---|---|
| 1 | 🟡 PG15停止 | ◎ | ◎ | 障害検知後すぐ |
| 2 | 🟡 PG15アクセス遮断 ※1 | ◎ | ◎ | アプリ停止 |
| 3 | 🟡 PG12データ存在確認 | ◎ | × | 消してたら詰み |
| 4 | 🟡 PG12起動 | ◎ | × | 旧環境復帰 |
| 5 | 🟡 接続先切替 ※1 | ◎ | ◎ | アプリ側 |
| 6 | 🟡 Replica再構築 | ◎（提供） | ◎（実行） | PG12で再作成 |
| 7 | 🟡 レプリケーション確認 | ◎ | ◎ | 状態確認 |
※1 PostgreSQL サーバ側の作業ではなく、クライアント／アプリケーション側（またはその手前の仕組み）の作業です。
え～っと...
仮に「ChatGPT」氏の回答が「幻覚（ハルシネーション）」を引き起こしていないとすると、公式の「ドキュメント」が役に立たないことになるのだが...
そもそも、肝心の新しい「バージョン」の「PostgreSQL」をインストールする部分については、公式の「ドキュメント」にも記載がされていないので、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
Linuxディストリビューション毎のパッケージ管理ツールでインストールして問題ありません。PostgreSQL 12が稼働中でも、PostgreSQL 15は並行してインストール可能です。むしろ
pg_upgrade前提なら「共存」が正しい状態です。
✅ なぜ共存できるのか
RHEL系の公式RPM（PGDG）はバージョンごとに完全分離されています：
/usr/pgsql-12/ ← PostgreSQL 12 /usr/pgsql-15/ ← PostgreSQL 15 /var/lib/pgsql/12/data /var/lib/pgsql/15/data
👉 バイナリ・データディレクトリ・サービス名がすべて別
✅ 実際の挙動
インストールしても：
- PostgreSQL 12 → そのまま稼働
- PostgreSQL 15 → インストールされるだけ（起動しない）
👉 既存サービスには影響しません
✅ systemdサービスも別
postgresql-12.service ← 稼働中 postgresql-15.service ← 停止状態
👉 勝手に切り替わることはない
✅ 注意すべきポイント
① ポート競合
デフォルトはどちらも 5432
👉 同時起動する場合は変更必要：
port = 5433
ただし：
pg_upgradeを使用する際は同時起動しないのでポートの変更は通常不要
② PATH混在（地味に危険）
psql --version
👉 意図せず12を使う事故
対策：
/usr/pgsql-15/bin/psql
③ 拡張のバージョン
PG12とPG15で別パッケージ必要
例：
postgresql12-contrib postgresql15-contrib
④ ライブラリ依存
基本問題ないが念のため確認：
ldd /usr/pgsql-15/bin/postgres
✅ むしろやるべき理由
pg_upgradeでは：
-b /usr/pgsql-12/bin -B /usr/pgsql-15/bin
👉 両方同時に存在している必要がある
✅ やってはいけないこと
❌ 12をアンインストールしてから15入れる
→ pg_upgradeできなくなる
💡 まとめ
- PostgreSQL 12稼働中でも問題なく15インストール可能
- 共存は前提設計
- 影響なし（起動しなければ）
- むしろ必須ステップ
う～む...
公式の「ドキュメント」で「ストリーミングレプリケーション」構成のケースにおける「PostgreSQL」の「バージョンアップ」の正確な手順の「情報」が集約されていないのは辛過ぎるんだが...
とりあえず、「ファインダビリティ（Findability）」が絶望的な状況にあることは分かった...
そもそも、
■日本語版
■英語版
⇧ 上記にありますように、
- 日本語版
- 英語版
で、微妙に「ドキュメント」の構成が異なり、「英語版」の方が「アップグレード」の「方式」としての選択肢が把握し易い形になってはいそう。
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
📌 アップグレードの方式比較
【凡例】評価の読み方（補足）
- ◎：非常に優れている / 強み
- ○：実用的
- △：条件付き / トレードオフあり
- ×：弱点・制約あり
| No | 観点 | 19.6.1 pg_dumpall | 19.6.2 pg_upgrade | 19.6.3 Replication |
|---|---|---|---|---|
| 1 | ダウンタイム | ×（長い） | △（短いが必須） | ◎（ほぼゼロ） |
| 2 | 速度 | ×（遅い） | ◎（最速） | △（初期同期が重い） |
| 3 | バージョン互換性 | ◎（ほぼ無制限） | △（対応範囲あり） | ◎（異バージョンOK） |
| 4 | 構成のシンプルさ | ◎（単純） | ◎（単純） | ×（複雑） |
| 5 | 運用難易度 | ◎（低い） | ◎（低い） | ×（高い） |
| 6 | データ完全性 | ◎（完全再構築） | ◎（完全維持） | △（制約あり） |
| 7 | DDL同期 | ◎（自動） | ◎（そのまま） | ×（手動） |
| 8 | sequence同期 | ◎ | ◎ | × |
| 9 | 大規模DB適性 | × | ◎ | ○ |
| 10 | ロールバック容易性 | × | × | ○ |
| 11 | 必要リソース | △（I/O重い） | ◎（効率良） | ×（2系統必要） |
| 12 | 柔軟性 | ◎ | × | ◎ |
| 13 | 本番無停止対応 | × | × | ◎ |
📌 実務的な観点
✅ pg_dumpall の立ち位置
- シンプルで安全
- ただしスケールしない
👉 小規模 or 最終手段
✅ pg_upgrade が強い理由
- ほぼ全項目でバランス良く◎
- 弱点は「止める必要がある」だけ
👉 止められるなら第一候補
✅ Replication の立ち位置
- 無停止だけは圧倒的（◎）
- それ以外はコスト高
👉 ダウンタイム回避のために複雑さを買う方式
💡 まとめ（評価ベース）
- pg_dumpall 方式 → 「安全だが遅い（◎安全 ×速度）」
- pg_upgrade 方式 → 「最速だが止める（◎速度 △停止）」
- replication 方式 → 「止めないが大変（◎無停止 ×運用）」
とりあえず、「本番環境」を停止できない環境においては、「19.6.3. Upgrading Data via Replication」の一択になりそうなのだが、公式の「ドキュメント」で詳細な「手順」に触れられていないのよね...
誠に遺憾である...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
