今回はGitLabの引っ越し＆アップグレードの際に環境によって発生した問題とその解決法です。 （GitLabについての説明は割愛します）
なお手元の環境はDockerイメージを使っているのですが、そのことは事態にさほど影響しません。 7→8／8→9の間にそれぞれパラメータ類が増加しているので、それにあわせた対処は必要なわけですが、どの方法（Omnibus Packages／ソースインストール／Dockerイメージ）であっても、公式マニュアルを見れば進められます。
今回ご紹介したい件はもうちょっとややこしい内容でして、そもそもどのパッケージを使っても7→8のアップグレードができないパターンがあるというものです。
発生条件は次の通り： ・DBにMySQLを使っている ・MySQLのGTIDがONになっている というものです。
GTIDについてご存知の方はもうこの時点でピンとくると思うのですが、GitLabの7→8のマイグレーションにCREATE TABLE ... SELECT文が使われているのです。 これはGTIDをONにした場合に使用できなくなるのですよね…。 https://dev.mysql.com/doc/refman/5.6/ja/replication-gtids-restrictions.html
なおこの問題についてはパッチがマージリクエストされているのですが、CREATE TABLE ... SELECTをCREATE TEMPORARY TABLE ... SELECTに書き換えるというものなので、こんどは一時テーブル関連の設定にひっかかる可能性が指摘されています。 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2081
さてではどうするかということになりますが、単純に考えると、次のような手段が可能じゃないかな？と考えられます ・別環境を用意（＋GTIDを使用していないMySQL） ・別環境でマイグレーションを実行し、そのDBのダンプを取る ・ダンプを元DBに投入 ・元環境でマイグレーション実行 当然ながら、何かしら想定外の問題が出そうなので、さらに別環境を用意して検証します。
検証の結果とくに問題は出なかったので、上記の方法で正常に7→8アップグレードを完了させました。 （なおこの後、元の環境で8→9へのアップグレードは問題なく完了しました）
フレームワークやミドルウェアによってはDB上のバージョンナンバーだけでアップグレードをスキップしてしまったりしますが、GitLabはDBだけ新しくなっていてもちゃんとソースコード側もアップデートされるようで安心しました。