プロジェクト

全般

プロフィール

20260712 サーバ移行07 gitbuckeのVIEWが移行できてなかった » 履歴 » バージョン 3

sylow castle, 2026/07/27 23:23

1 3 sylow castle
# 20260712 サーバ移行07 gitbuckeのVIEWが移行できてなかった
2 1 sylow castle
3
成功してなかったよ
4
5 2 sylow castle
- gitbucketのVIEW移行失敗
6
- gitbucketの設定移行忘れ
7 1 sylow castle
8 2 sylow castle
## gitbucketのVIEW移行失敗
9
10
### 結論
11
12 1 sylow castle
> Geminiは次のコマンドを提案:
13
> ```
14
> # dump.sql の中の utf8 をすべて utf8mb4 に置換する
15
> sed -i 's/utf8/utf8mb4/g' gitbucket.sql
16
> ```
17
>
18
>これを実行してgitbucket.sqlを流し込んでやったらあっさり成功。
19
20
移行時にこれをやったのが原因っぽい。
21
どうも一部の構造(ISSUE_OUTLINE_VIEW)に元々utf8mb4という文字コード指定が紛れ込んでいたらしくutf8mb4mb4になって移行に失敗していた。
22
23 2 sylow castle
### 対応
24 1 sylow castle
25
他に引越し漏れているものがないか比較するために最新のmysqldumpを取得:
26
27
```
28
mysqldump -u root -p gitbucket > gitbucket_20260712.sql
29
```
30
31
過去のdumpと比較する
32
```
33
diff -u gitbucket.sql gitbucket_20260712.sql > gitbucket.sql.diff
34
vim gitbucket.sql.diff
35
36
```
37
38
目検して問題となる差分がISSUE_OUTLINE_VIEWだけだと確認。gitbucket.sqlからCREATE VIEWの部分を引っ張ってきて修正して流して完成。
39
復旧。
40
41
大したことなくて良かった。
42
ちなみにやはりGeminiに相談してたら次のような教訓をくれたので共有:
43
44
---------------------------------
45
46
> ### 教訓
47
> 
48
> `mysql < dump.sql` でインポートするときは、以下のようにすると「何が起きているか」を確実に見ることができます。
49
> 
50
> 1. **`-v` (verbose) オプションをつける:**
51
> `mysql -v -u user -p dbname < dump.sql`
52
> これをやると、現在実行中のSQL文が逐次表示されるため、どこで止まったかが目視しやすくなります。
53
> 2. **`--show-warnings` をつける:**
54
> インポート中に「無視された警告」の内容を表示してくれます。
55
> 3. **終了ステータスをチェックする:**
56
> スクリプト化する場合は `mysql ... || exit 1` のようにして、エラーが出たら即座に止まるように設定するのが鉄則です。
57
> 
58
> 今回、エラーが出ずに「入っていない」という状況になったのは、MySQLが「理解できないものはコメントとして無視する」という優しさ(?)を発揮した結果、サイレントにスキップされていた、というのが真相でしょうね。
59
60
-----------------------------------
61
62
AIのいう事をよく考えずに鵜呑みにしちゃダメというのが真の教訓かな。当たり前の話だけど。
63 2 sylow castle
64
## gitbucketの設定移行忘れ
65
66
sshを紐づけるアドレス(ホスト名)を<GITBUCKET_HOME>/gitbucket.confで指定している
67
68
SSHはWebのURLドメイン(www.sylow-castle.work)じゃなくてホスト名(iroha.sylow-castle.work)で受けてたからこの部分を移行しないと不味かった。
69
gitbucket.confを編集「ssh.bindAddress.host=」と「ssh.publicAddress.host=」の2項目を修正して完了