=======================================
20231027(金) 14:47 pg_restore に -v 付けてもう一度やってみる。
20231027(金) 17:01 pg_restore: creating INDEX "public.activities_visibility_index" のまま
20231027(金) 23:26 ずっと変化なし。このまま明日まで置いてみよう。
20231029(日) 9:02 何も変化せず。pg_restoreをkillした。
20231029(日) 9:22 prune前のdumpを-v 付きでpg_restorした。やはり同じ、pg_restore: creating INDEX "public.activities_visibility_index" で進まなくなった。(15:00)
ということで、これはDBがprune前からこの位置で壊れていたのだろう。私には修復不可能。
=======================================
★20231026(木)にPleromaのDBのbackup/prune/restoreをしたがrestoreで失敗。prune前のDBのrestoreでも同様。もともとDBがおかしかったのかも。
★plr.ph3j.comは閉鎖するのがほぼ確実になって来たが、もう少し考える。
★さて、これからどうするか?
以下20231026(木)にやったこと
=======================================
20231026(木) 8:45 shutdown pleroma server
20231026(木) 8:53 shutdown lemmy server
20231026(木) 9:03 start pg_dump
20231026(木) 9:06 pg_dump end これでうまく行ったのか? 多分うまく行っただろうということで次
20231026(木) 9:31 start prune without vacuum
20231026(木) 9:38 Elixir でエラー; DBに接続できない?
20231026(木) 9:58 MIX_ENV=prodを追加でpruneがスタート
20231026(木) 10:01 prune end
20231026(木) 10:07 start pg_dump after prune
20231026(木) 10:10 end of pg_dump after prune; dumpしたサイズが858MB-->533MB
20231026(木) ここでミカンを食べて休む
20231026(木) 10:31 start restore dump after prune
20231026(木) 12:45 client_loop: send disconnect: Broken pipe ということでsshの端末は落ちたが、postgresqlはCPU100%近くで走っている
20231026(木) さてどうするか。もう少し様子見。
20231026(木) 13:36 進展がないようなのでposgresqlを停止した
20231026(木) 13:48 再起動したposgresqlをvacuum fullし始めた
20231026(木) 14:01 vacuum full完了
20231026(木) 14:04 pleromaを起動してみるが、timelinesが読み込めない
20231026(木) 14:48 にスタート。pg_restoreしたファイルをサーバに送ってそれを使ってrestoreしてみる。
20231026(木) 19:40くらい。DBをprune前のに戻しても同様の症状、restoreが終了しない。Pleromaを起動してもtimelinesが取得できない。
=======================================
(by sumiyaki as of 20231030)
@sumiyaki.ph3j.com at bsky.app
@sumiyaki@misskey.cloud
:q
@sumiyaki@plr.ph3j.comは閉鎖したので410/goneになりました