今回は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だけ新しくなっていてもちゃんとソースコード側もアップデートされるようで安心しました。