20260712 サーバ移行07 gitbuckeのVIEWが移行できてなかった » 履歴 » リビジョン 2
リビジョン 1 (sylow castle, 2026/07/12 02:42) → リビジョン 2/3 (sylow castle, 2026/07/12 03:09)
# 202600712 サーバ移行07 gitbuckeのVIEWが移行できてなかった 成功してなかったよ - gitbucketのVIEW移行失敗 - gitbucketの設定移行忘れ ## gitbucketの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のいう事をよく考えずに鵜呑みにしちゃダメというのが真の教訓かな。当たり前の話だけど。 ## gitbucketの設定移行忘れ sshを紐づけるアドレス（ホスト名）を<GITBUCKET_HOME>/gitbucket.confで指定している SSHはWebのURLドメイン（www.sylow-castle.work）じゃなくてホスト名（iroha.sylow-castle.work）で受けてたからこの部分を移行しないと不味かった。 gitbucket.confを編集「ssh.bindAddress.host=」と「ssh.publicAddress.host=」の２項目を修正して完了