GitLab 7から8へのアップグレードで発生した問題と解決


今回は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 ... SELECTCREATE TEMPORARY TABLE ... SELECTに書き換えるというものなので、こんどは一時テーブル関連の設定にひっかかる可能性が指摘されています。 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2081

さてではどうするかということになりますが、単純に考えると、次のような手段が可能じゃないかな?と考えられます ・別環境を用意(+GTIDを使用していないMySQL) ・別環境でマイグレーションを実行し、そのDBのダンプを取る ・ダンプを元DBに投入 ・元環境でマイグレーション実行 当然ながら、何かしら想定外の問題が出そうなので、さらに別環境を用意して検証します。

検証の結果とくに問題は出なかったので、上記の方法で正常に7→8アップグレードを完了させました。 (なおこの後、元の環境で8→9へのアップグレードは問題なく完了しました)

フレームワークやミドルウェアによってはDB上のバージョンナンバーだけでアップグレードをスキップしてしまったりしますが、GitLabはDBだけ新しくなっていてもちゃんとソースコード側もアップデートされるようで安心しました。

最新記事

すべて表示

SQLite(sqlite3)で “no such table”

小ネタです。 SQLiteを使っていて "no such table" とエラーが出た場合、 DBファイル名の指定が空になっている、という凡ミスを起こしていないかを確認してみましょう。 ・・・ そういう凡ミスをしてしばし悩んだので… ファイル名の指定が空になっている場合、一時的なインメモリDBとして保存されます(※1)。 つまりDB接続を切断すると中身は消えます。 なので接続

アプリケーションサーバにポートを指定せずに起動すると?

最近、 Goで書かれたアプリケーションサーバが起動しない! ->原因: .env ファイルが欠けていた というドタバタがありました。 結局Goと関係ないですが、この時、 「あまりGoに慣れてないのでGoの問題かと…」「DockerまだよくわかってなくてDockerの問題かと…」 というような声があったのて、あえてGoで検証してみようと思ったわけです。 さて、Goでサーバサイドのシステムを作

GitLab 9.1.2 (MySQL) を 11.4.0 (PostgreSQL) にアップグレード

弊社ではかなり前からGitLab(CE)を自社環境で運用しているのですが、ふと気付くと、バージョンがだいぶ先に行ってしまっていました。 とくに最近のバージョンでは Auto DevOps なども使えるようになっていたりするので、さすがにそろそろキャッチアップしたいと考えたわけです。 現行の環境は次の通りです: GitLab 9.1.2 sameersbn/gitlab 使用 MySQL 5.6