202600712 サーバ移行07 gitbuckeのVIEWが移行できてなかった¶

成功してなかったよ

結論¶

Geminiは次のコマンドを提案：

# dump.sql の中の utf8 をすべて utf8mb4 に置換する
sed -i 's/utf8/utf8mb4/g' gitbucket.sql

これを実行してgitbucket.sqlを流し込んでやったらあっさり成功。

移行時にこれをやったのが原因っぽい。
どうも一部の構造（ISSUE_OUTLINE_VIEW）に元々utf8mb4という文字コード指定が紛れ込んでいたらしくutf8mb4mb4になって移行に失敗していた。

対応¶

他に引越し漏れているものがないか比較するために最新のmysqldumpを取得：

mysqldump -u root -p gitbucket > gitbucket_20260712.sql

過去のdumpと比較する

diff -u gitbucket.sql gitbucket_20260712.sql > gitbucket.sql.diff
vim gitbucket.sql.diff

目検して問題となる差分がISSUE_OUTLINE_VIEWだけだと確認。gitbucket.sqlからCREATE VIEWの部分を引っ張ってきて修正して流して完成。
復旧。

大したことなくて良かった。
ちなみにやはりGeminiに相談してたら次のような教訓をくれたので共有：

教訓¶

mysql < dump.sql でインポートするときは、以下のようにすると「何が起きているか」を確実に見ることができます。

1. -v (verbose) オプションをつける:
   mysql -v -u user -p dbname < dump.sql
   これをやると、現在実行中のSQL文が逐次表示されるため、どこで止まったかが目視しやすくなります。
2. --show-warnings をつける:
   インポート中に「無視された警告」の内容を表示してくれます。
3. 終了ステータスをチェックする:
   スクリプト化する場合は mysql ... || exit 1 のようにして、エラーが出たら即座に止まるように設定するのが鉄則です。

今回、エラーが出ずに「入っていない」という状況になったのは、MySQLが「理解できないものはコメントとして無視する」という優しさ（？）を発揮した結果、サイレントにスキップされていた、というのが真相でしょうね。

AIのいう事をよく考えずに鵜呑みにしちゃダメというのが真の教訓かな。当たり前の話だけど。