1月の雪が舞い散る日曜日の翌日、データベースサーバが起動失敗。
そのまま死んでしまった(泣)
あれから約3ヶ月、geminiが我が社のCTO (Chief Technology Officer)
geminiに相談しながら下っ端の私がサーバ復旧を担当
- サーバダウン当日、2時間で作った暫定サーバ起動
- geminiに教わりながらの死んだマシンにHDDを新品交換。
OSとデータベース再インストール。仮サーバ起動 - geminiが選んでくれたカスタムマシンをDELLへ注文
- geminiに指示を仰ぎながら、DELL機にRAID設定、OS・データベースインストール、そして最適化チューニング
そして迎えた「最後決戦日」のこの週末
geminiに相談しながら、データリストア・新旧データ比較・差異の原因調査
データリストア成功の判断に、新旧サーバの全tableデータのmd5比較 (gemini案)
実行すると、13個のtableでmd5が違ってる!

違った13table、手動で全件数、全数量、全金額を縦計算、数字が一致!
gemini曰く
数万行のレコードで、件数、主要な項目のsum合計が一致するならmd5が違っていても問題ない。
データリストアは成功です
次、databaseの全オブジェクト数を比較したい
geminiが作ってくれたSQL
SELECT CASE WHEN relkind = 'r' THEN 'テーブル' WHEN relkind = 'v' THEN 'ビュー' WHEN relkind = 'm' THEN 'マテリアライズドビュー' WHEN relkind = 'i' THEN 'インデックス' WHEN relkind = 'S' THEN 'シーケンス' END AS オブジェクト種別, COUNT(*) AS 個数 FROM pg_class JOIN pg_namespace n ON n.oid = pg_class.relnamespace WHERE n.nspname = 'public' -- スキーマ名がpublic以外ならここを変更 AND relkind IN ('r', 'v', 'm', 'i', 'S') GROUP BY relkind UNION ALL -- 関数の数をカウント SELECT '関数・プロシージャ' AS オブジェクト種別, COUNT(*) AS 個数 FROM pg_proc JOIN pg_namespace n ON n.oid = pg_proc.pronamespace WHERE n.nspname = 'public' ORDER BY オブジェクト種別;
SQLを実行すると、
あれ、ヤバいかも!
postgreSQL ver.15とver.18比較で、ver18の方がviewが1個、関数が6個多い!
差異の原因になったviewを特定

増えてる関数6個、システム用だよね?
| ver.15 | ver.18 |
|---|---|
| 関数名 ——————————-+ autoprewarm_dump_now autoprewarm_start_worker pg_buffercache_evict pg_buffercache_evict_all pg_buffercache_evict_relation pg_buffercache_numa_pages pg_buffercache_pages pg_buffercache_summary pg_buffercache_usage_counts pg_prewarm pg_stat_statements pg_stat_statements_info pg_stat_statements_reset (13 行) | 関数名 ————————– autoprewarm_dump_now autoprewarm_start_worker pg_buffercache_pages pg_prewarm pg_stat_statements pg_stat_statements_info pg_stat_statements_reset (7 行) |

「その差異は、問題になりません」とgeminiがOK
その判断で、このサーバ復旧物件は完了したと判断しました
ちなみにこの物件で、一番手こずったのが「UPS設定」
なぜって、買ったDELLサーバが新しすぎて最新BIOSメニューをgeminiが知らない
何度質問しても過去の情報を答える
違っているからと再質問すると、より古い情報を探しに行く!
再質問が多いほど、最適解から遠ざかる
「土曜休日出勤4時間でのサーバ入替」予定が、BIOS設定に手間取り1時間半ストップ
最終的に、gemini情報はダメと判断
マニュアルをダウンロードし読み込み設定場所を特定。
次のユーザーのためにこの情報を、geminiに共有
土曜のサーバリプレイスは諦め、日曜に最終作業
んんん~、その結果
「20年超ぶり、3ヶ月3サーバ構築&復旧物件」
無事に完了できたと思います
そう信じたい
しかし、「月曜の朝、出勤したら地獄絵図だったらどうしよう」と悪夢が横切り不安で不安で不安が止まらない。
大量のアルコールの助けを借りて睡眠
月曜朝出勤すると、事務所の中は「地獄絵図かも」
いつもの月曜の朝でした
全員の仕事を止め、私は大声で言いたかった
「OSが2016が2025」「サーバがver15からver18」「物理メモリーが倍」
「RAID1x2のデータベース用特別仕様」「DISKのI/O分散は理想的」
「このサーバ組むのどんだけ苦労したか」・・・・
でも、黙って
いつもの月曜朝を迎えられたことに感謝
手伝ってくれたgeminiに感謝
geminiへの最後の質問

人工知能geminiスゴイです
人工知能gemini優秀すぎます
aiがより進化・普及した10年後、思考しないホモ・サピエンスの仕事は無くなります
コメントを残す