CDNサービスを手掛ける米Cloudflareのマシュー・プリンスCEOは11月18日（現地時間）、同日昼前に発生した大規模な障害についてブログで説明した。ChatGPTやXを巻き込んだ今回の障害は「2019年以来で最悪の障害となった」という。
障害が発生したのはUTC（協定世界時、日本は9時間進んでいる）で18日の午前11時20分ごろ。Cloudflareのネットワークでトラフィックで重大な障害が発生し、顧客企業のサイトにアクセスしようとしたユーザーに対してエラーページが表示されるようになったという。影響はChatGPT、X、Spotify、Zoom、Microsoft Teams、Canva、Visaなど広範囲に及んだ。
Cloudflareは当初、その症状からDDoS攻撃の可能性を疑ったが、実際はデータベースシステムの権限変更によってbot管理システムで使用されるフィーチャーファイルに重複する行が多数発生し、サイズが2倍以上になったことだった。ルーティングソフトウェアが読み取るフィーチャーファイルのサイズ制限を超えたため、障害につながった。
⇧ 何と言うか、未然に防止できる仕組化しておいてもらわないと、「保守・運用」担当者の精神的負担が大き過ぎるように思いますな...
おそらく、
- DEV（Development）環境
- STG（Staging）環境
- PRD（Production）環境
で差分があって、事前の検証の意味がなくなっていたような気がしますが...
By the way、
キリンホールディングス傘下のメルシャンが、フランス産ワインの新酒「ボージョレ・ヌーボー」の輸入販売から撤退することが7日分かった。今秋分から取りやめる。嗜好の多様化でボージョレの消費が減少しているほか、輸送費などコストが上昇しているため。代わりに日本産ワインの新酒の販売を拡大するという。
⇧ そもそも、美味いのかどうかが謎過ぎる...
イメージ的には、
| No | 国 | 地域 ※ | 水質 |
|---|---|---|---|
| 1 | 日本 | 東アジア | 軟水 |
| 2 | フランス | 西ヨーロッパ | 硬水 |
| 3 | アメリカ | 北部アメリカ | 硬水 |
⇧「水質」が違うこともあり、日本人に合わないような気もしますな。
※ Wikipediaの「国連による世界地理区分」を参照。
「ボージョレ・ヌーボー」はというと、
ボジョレーワイン （フランス語: Vins du Beaujolais）とは、フランスワインの1つ。ローヌ県北部、ソーヌ＝エ＝ロワール県の数箇所のコミューンで生産されている。ブルゴーニュワインの1種類とされている。生産地域は、マコンとリヨンの間、ボジョレー地方の山のふもとである。
毎年11月第3木曜日（日付が変わった午前0時）に解禁される、特産品の新酒をボジョレー・ヌヴォー （仏: Beaujolais nouveau） という。
以前はその年のブドウの出来栄えをチェックすることを主な目的としたもので、ワイン業者が主な顧客であったが、その後、解禁日をイベントとして、新酒として大々的に売る販売戦略や販売手法が確立され、現在はフランスでも、日本と同じ目的で一般の消費者向けに売られている（ブルゴーニュ地域圏のマコネー （Maconnais） 地区に隣接する地のワインはブルゴーニュ・ワインに分類される）。
⇧ 何か、「恵方巻き」のような扱いなのかね？
とりあえず、
- ボージョレ・ヌーボー
- ボジョレー・ヌヴォー
の「表記ゆれ」が気になって仕方ない...
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
質問：
ボジョレーヌーボーや恵方巻きの他に、本来の目的から乖離して大々的に売る販売戦略や販売手法が確立された商品を教えてください。
回答：
「本来の用途や文化的意味から少し離れて、マーケティングや販売戦略によって大々的に消費されるようになった商品」を探しているわけですね。ボジョレーヌーボーや恵方巻きはその典型です。いくつか例を挙げて整理してみます。
| 商品 | 本来の意味・用途 | 現在の消費形態 | 販売戦略 |
|---|---|---|---|
| ボジョレーヌーボー | 新酒の味わいを楽しむフランスの収穫祭 | 日本での解禁日に飲むイベント化 | 発売日を固定し、期間限定で話題性を演出 |
| 恵方巻き | 節分に縁起をかつぐ食事 | 全国的に太巻きを丸かじりする習慣 | コンビニ・スーパーが宣伝して大量販売 |
| ハロウィン関連商品（日本） | 死者を迎え、悪霊を追い払う宗教行事 | 仮装、キャンディ、お菓子、装飾の消費 | 百貨店・コンビニが「イベント消費」として大量販売 |
| サマー／ウィンター限定商品 | 季節の食材や風物 | 季節限定フレーバー、期間限定商品 | 限定商法で購買意欲を喚起 |
| バレンタイン（日本） | キリスト教聖人の記念日 | 義理チョコ・友チョコ・本命チョコの大量消費 | 「義理チョコ文化」を作り出し百貨店イベント化 |
| 七夕関連商品 | 中国由来の星祭り | そうめん、笹飾り、地域イベントでの景品 | 食品メーカー・小売が「七夕限定商品」を販売 |
| 土用の丑の日のうなぎ | 夏に栄養をつける風習 | スーパー・デパートでのうなぎ大量販売 | 江戸時代の宣伝戦略で「土用＝うなぎ」を定着 |
| クリスマスケーキ（日本） | キリスト教の祭日 | 家族・カップル向けにホワイトケーキを消費 | 昭和初期に洋菓子業界が宣伝して日本独自習慣化 |
| パンプキンフレーバー商品 | 収穫祭の装飾や料理材料 | パンプキンスイーツ、パン、ラテ | 季節商戦に合わせた限定味商品 |
⇧ まぁ、日本国外の文化由来の商品が多いですな...
上記だと、「鰻（うなぎ）」が一番魅力的に感じてしまいますな（個人の見解です）
価格が高過ぎて、おいそれとは、手が出ませんが...
PostgreSQLには2種類のレプリケーション機能が用意されているらしい
公式の情報では無いのだが、
⇧ 上記サイト様によりますと、
| No | レプリケーション機能の種類 | 導入バージョン | 内容 |
|---|---|---|---|
| 1 |
ストリーミングレプリケーション |
9.0～ | マスター側から全てのトランザクションログ(WAL)を転送し、スタンバイ側はWALを適用（リカバリ）します。 |
| 2 |
論理レプリケーション |
10.0～ | WALに記載されている変更情報を論理的なレベルに変換（デコード）してから転送します。 |
⇧ 上記の2種類の「レプリケーション機能」が用意されている模様。
なのだが、公式のバージョン 12.0 のドキュメントを確認した限り、
These settings control the behavior of the built-in streaming replication feature (see Section 26.2.5). Servers will be either a master or a standby server. Masters can send data, while standbys are always receivers of replicated data. When cascading replication (see Section 26.2.7) is used, standby servers can also be senders, as well as receivers. Parameters are mainly for sending and standby servers, though some parameters have meaning only on the master server. Settings may vary across the cluster without problems if that is required.
https://www.postgresql.org/docs/12/runtime-config-replication.html
⇧ 何か、「レプリケーション」の種類が異なるのよね...
一応、バージョン 18.0のドキュメントを確認した限り、
These settings control the behavior of the built-in streaming replication feature (see Section 26.2.5), and the built-in logical replication feature (see Chapter 29).
https://www.postgresql.org/docs/current/runtime-config-replication.html
⇧ 参考サイト様の説明通りの「レプリケーション」の種類になっているようだが...
PostgreSQLのStreaming Replication利用環境のバックアップの復元がややこし過ぎる
で、「ストリーミングレプリケーション（built-in streaming replication）」はハマりどころが多いらしく、
⇧ バックアップからの復元の正しい手順を教えてという声が上がっているようですし、被害者は多そう...
そりゃあ、世の中で、誤設定によるシステム障害が頻発するのも然もありなんという気がしてしまうのよ...
📘 完全手順書（バックアップ復元 → 元の構成に戻す）
●前提
-
サーバーBにサーバーAのバックアップ（
base.tar.gz+pg_wal.tar.gz）がある
※ pg_basebackupをサーバーBで実行している -
PostgreSQLデータディレクトリ例：
/var/lib/pgsql/data
※ PostgreSQLサーバーのデータディレクトリは、環境によって異なるので注意 -
レプリケーション用ユーザー名：
replication_user
※ PostgreSQLサーバーでSQL文で作成したロール -
レプリケーションパスワード：
REPL_PASS -
PostgreSQLはバージョン一致
●作業フロー図
┌───────────────┐ ┌───────────────┐
│ サーバーA │ │ サーバーB │
└───────────────┘ └───────────────┘
│ │
│ │ Step 1: バックアップ展開
│ │ - base.tar.gz + pg_wal.tar.gz
│ │ - PostgreSQL停止
│ │ - データディレクトリ削除
│ │ - standby.signal削除
│ │
│ │ Step 2: B昇格(Primary化)
│ │ - pg_ctl promote
│ │
│ │ Step 3: レプリケーション準備
│ │ - replication_user作成
│ │ - pg_hba.conf更新 + reload
│ │ - レプリケーションスロット作成(slot_for_A)
│ │
│ Step 4: A初期化 │
│ - データディレクトリ削除 │
│ - PostgreSQL停止 │
│ │
│ Step 5: AがBからデータ取得してReplica化 │
│ ----------------------------------------> │ データ取得
│ - pg_basebackupで取得 + standby.signal作成
│ - PostgreSQL起動 │
│ │
│ Step 6: 同期確認 (サーバーA) │
│ - pg_stat_replication / pg_is_in_recovery() 確認
│ ----------------------------------------> │
│ │
│ Step 7: 元の構成に戻す │
│ Step 7-1: A昇格(Primary化) │
│ - pg_ctl promote │
│ │ Step 7-2: B初期化
│ │ - データ削除
│ │ - pg_basebackupでAから取得 + standby.signal作成
│ │ - PostgreSQL起動
│ │
│ │ Step 8: 同期確認 (サーバーB)
│ │ - pg_stat_replication / pg_is_in_recovery() 確認
│ <---------------------------------------- │
●作業手順
■Step 0: 前準備
作業場所：サーバーB
/path/to/base.tar.gz /path/to/pg_wal.tar.gz
- サーバーA/Bの現在の接続ユーザー、IPを確認
■Step 1: サーバーBでバックアップファイルを展開（解凍）する
作業場所：サーバーB
※ Replicaは書き込み禁止のため、PostgreSQLサーバーを停止してから、バックアップの展開（解凍）する必要がある。
# PostgreSQL停止
pg_ctl stop -D /var/lib/pgsql/data -m fast
# データディレクトリを空に
rm -rf /var/lib/pgsql/data/*
mkdir -p /var/lib/pgsql/data
chown -R postgres:postgres /var/lib/pgsql/data
# バックアップ展開
cd /var/lib/pgsql/data
tar -xzf /path/to/base.tar.gz
tar -xzf /path/to/pg_wal.tar.gz
chown -R postgres:postgres /var/lib/pgsql/data
# Replica用設定削除
rm -f /var/lib/pgsql/data/standby.signal
■Step 2: サーバーBを昇格してPrimary化
作業場所：サーバーB
pg_ctl promote -D /var/lib/pgsql/data
- この時点でサーバーBはバックアップ時点のPrimaryとして起動
■Step3: レプリケーションに必要な情報の準備
■■Step 3-1: サーバーBにレプリケーション用ロール作成
作業場所：サーバーB
-- サーバーBにサーバーAへの接続用のユーザーを作成する CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'REPL_PASS';
-
replication_userは任意 -
REPLICATION権限が必須
■■Step 3-2: サーバーBの pg_hba.conf 設定
作業場所：サーバーB
pghba.confでレプリケーション
# /var/lib/pgsql/data/pg_hba.conf host replication replication_user サーバーA_IP/32 md5
PostgreSQLサーバーの再起動。
pg_ctl reload -D /var/lib/pgsql/data
■■Step 3-3: サーバーBにレプリケーションスロット作成（サーバーA用）
作業場所：サーバーB
SELECT * FROM pg_create_physical_replication_slot('slot_for_A');
■Step 4: サーバーAを初期化してBのReplicaにする準備
作業場所：サーバーA
# サーバーA停止 pg_ctl stop -D /var/lib/pgsql/data -m fast # 古いデータ削除 rm -rf /var/lib/pgsql/data/* mkdir -p /var/lib/pgsql/data chown -R postgres:postgres /var/lib/pgsql/data
■Step 5: サーバーAをReplicaにする
■■Step 5-1: サーバーBからベースバックアップ取得
作業場所：サーバーA
pg_basebackup -h B_IP -D /var/lib/pgsql/data -U replication_user -Fp -Xs -P -R
■■Step 5-2: サーバーA起動
作業場所：サーバーA
pg_ctl start -D /var/lib/pgsql/data
- サーバーAはサーバーBのReplicaとして同期開始
■Step 6: 同期確認（サーバーA→サーバーB）
作業場所：サーバーA
SELECT pid, client_addr, state, sync_state FROM pg_stat_replication;
■Step 7: 元の構成に戻す（サーバーAをPrimary、サーバーBをReplica）
■■Step 7-1: サーバーAを昇格してPrimary化
作業場所：サーバーA
pg_ctl promote -D /var/lib/pgsql/data
■■Step 7-2: サーバーBを初期化してAのReplicaにする準備
作業場所：サーバーB
# B停止 pg_ctl stop -D /var/lib/pgsql/data -m fast # 古いデータ削除 rm -rf /var/lib/pgsql/data/* mkdir -p /var/lib/pgsql/data chown -R postgres:postgres /var/lib/pgsql/data
■■Step 7-3: サーバーAからベースバックアップ取得
作業場所：サーバーB
pg_basebackup -h A_IP -D /var/lib/pgsql/data -U replication_user -Fp -Xs -P -R
■■Step 7-4: サーバーB起動
作業場所：サーバーB
pg_ctl start -D /var/lib/pgsql/data
■■Step 7-5: 同期確認（サーバーB→サーバーA）
作業場所：サーバーB
SELECT pid, client_addr, state, sync_state FROM pg_stat_replication;
⇧ う～む...、「幻覚（ハルシネーション）」してる箇所の特定に相当な時間が取られそうなのだが...
念のため、再度、「ChatGPT」氏に確認してみたところ、先ほどと異なる「回答」...
■作業手順
| Step | サーバーA | サーバーB | 操作内容 | 実行済み |
|---|---|---|---|---|
| 0 | psql -c "CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';"vi /etc/postgresql/12/main/postgresql.conf:wal_level = replicamax_wal_senders = 10max_replication_slots = 5listen_addresses = '*'vi /etc/postgresql/12/main/pg_hba.conf:host replication replication_user <B_IP>/32 md5sudo systemctl reload postgresql |
同様に replication_user 作成・pg_hba.conf 設定（必要に応じて） |
レプリケーションユーザー作成・pg_hba.conf / postgresql.conf 設定 | ☐ |
| 1 | sudo systemctl stop postgresql |
BのPostgreSQL停止 | ☐ | |
| 2 | rm -rf /var/lib/postgresql/12/main/*mkdir /var/lib/postgresql/12/mainchown postgres:postgres /var/lib/postgresql/12/main |
データディレクトリを空にして準備 | ☐ | |
| 3 | tar -xzf base.tar.gz -C /var/lib/postgresql/12/maintar -xzf pg_wal.tar.gz -C /var/lib/postgresql/12/main/pg_wal |
バックアップ展開 | ☐ | |
| 4 | rm /var/lib/postgresql/12/main/standby.signal |
Primary化のため standby.signal を削除 | ☐ | |
| 5 | sudo systemctl start postgresql |
PostgreSQL起動（BをPrimary化） | ☐ | |
| 6 | psql -c "SELECT pg_is_in_recovery();" |
Primary化確認 → false なら成功 | ☐ | |
| 7 | psql -c "SELECT * FROM pg_create_physical_replication_slot('replica_slot');" |
PrimaryのBでレプリケーションスロット作成 | ☐ | |
| 8 | sudo systemctl stop postgresql |
サーバーA停止（BがPrimary化後） | ☐ | |
| 9 | rm -rf /var/lib/postgresql/12/main/*mkdir /var/lib/postgresql/12/mainchown postgres:postgres /var/lib/postgresql/12/main |
ディレクトリを空にして準備 | ☐ | |
| 10 | pg_basebackup -h <B_IP> -D /var/lib/postgresql/12/main -U replication_user -Fp -Xs -P -R -S replica_slot |
BのデータをAに取得（AをReplica化） | ☐ | |
| 11 | sudo systemctl start postgresql |
PostgreSQL起動（AをReplica化） | ☐ | |
| 12 | psql -c "SELECT * FROM pg_stat_wal_receiver;" |
同期確認（AがBに接続されているか） | ☐ | |
| 13 | pg_ctl -D /var/lib/postgresql/12/main promote |
AをPrimary化（元構成に戻す） | ☐ | |
| 14 | sudo systemctl stop postgresql |
BをReplica化する準備のため停止 | ☐ | |
| 15 | rm -rf /var/lib/postgresql/12/main/*mkdir /var/lib/postgresql/12/mainchown postgres:postgres /var/lib/postgresql/12/main |
ディレクトリを空にして準備 | ☐ | |
| 16 | pg_basebackup -h <A_IP> -D /var/lib/postgresql/12/main -U replication_user -Fp -Xs -P -R -S replica_slot |
AからBへデータ取得（BをReplica化） | ☐ | |
| 17 | sudo systemctl start postgresql |
PostgreSQL起動（BをReplica化） | ☐ | |
| 18 | psql -c "SELECT * FROM pg_stat_wal_receiver;" |
同期確認（BがAに接続されているか） | ☐ |
「AI」の「回答」に「冪等性」が期待できないとは言え、「回答」の乖離が激し過ぎると、全く持って信用できなくなってしまうのよ...
と言うか、無茶苦茶に複雑な感じで、確実に復旧が失敗しそうな気がするんだが...
環境が壊れそうなのよな...
そして、「AI」は「責任」を担ってくれないから、根拠のない提案されたとて、見極められない我々が悪いということになるので質が悪い...
言い方悪いが、「詐欺師」と対峙しているような状況になることが多過ぎて、「ユーザーエクスペリエンス（UX：User eXperience）」は最悪としか言いようがない状態が続いているのよ...
やはり、何回も虚偽の情報で騙され続けている身からすると、信頼しろという方が無理な話なのよね...
いやはや、
- AIに質問
- AIからの回答
- ネット上で検索
の無限ループが止まらないのよな...
明らかに誤っている部分を指摘しても改善されないことも多いですし...
とりあえず、
2025年5月19日、GitHubが実装しているAIツール「GitHub Copilot」の新機能「コーディングエージェント」がパブリックプレビュー版で公開されました。この機能はGitHubのIssueをCopilotに割り当てるだけでCopilotが解決してくれるというものですが、実際の動作を見るとあまりにもダメダメであるとの投稿が話題になっています。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
⇧ このあたりの状態がどの程度、改善されたのかは気になりますな...
話が脱線しましたが、可能であれば、
⇧ 上記サイト様にあるように、シンプルに「rsync」で転送して復元する手順で作業したいのよな...
「コーディング」の量が多ければ、バグが混入する確率も上がるという話がありますが、手順も多ければ、それだけミスを誘発しやすくなる確率は上がりますからな...
公式のドキュメントで正確な手順を公開して欲しいお気持ち...
正解探しの不毛な時間が始まるわけなのよな...
健康を犠牲にして、日々ストレスと徒労感しか蓄積されていかないのだが...
当然のことながら、モチベーションが保てるわけがないのよな...
今日も今日とて、虚無感しか生まれませんな...
ちなみに、
表26.1 高可用性、負荷分散およびレプリケーションの特徴
https://www.postgresql.jp/document/12/html/different-replication-solutions.html
⇧公式のドキュメントによると、「最も一般的な実装」として「ストリーミングレプリケーション（built-in streaming replication）」が挙げられているのだが、「復元」の方法がブラックボックス過ぎるのよな...
う～む...、諸行無常...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
