サーバ完全復活!ありがとうgemini


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が違ってる!
新旧サーバでmd5比較(13tableが不一致)

違った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を特定
ver.18だけにあるviewを調べると

増えてる関数6個、システム用だよね?

ver.15ver.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年後、思考しないホモ・サピエンスの仕事は無くなります


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA