こんにちは，株式会社リブセンスの吉田健太郎です。前回に続いて，私が体験したTritonnからmroongaのシステム移行プロジェクトを舞台裏からお届けします。

これまでのあらすじ

将来的な技術負債を残さない，そしてInnoDBの性能向上等の恩恵を受けるため，もはやレガシーとなったMySQL 5.0を捨てて，MySQL 5.6への移行を行いたい。しかしSolrへ乗り換えるほどでもなく，引き続きシンプルにSQLを用いた，リレーショナルな日本語対応の全文検索を使いたい。この構想を実現するため，groongaのMySQLバインディング版である「mroonga」を用いた，MySQL 5.6への移行プロジェクトが始動しました。

そのパート1である前回は，主に次のトピックについて解説しました。

• Tritonnとmroongaそれぞれの紹介と移行時の要注意点
• 現在利用できる日本語全文検索ソリューションの比較
• ストレージエンジンをMyISAMからmroongaへ移行する際に気をつけたいAuto Incrementの挙動の違い

今回の流れ

Tritonnからmroongaへの移行はもちろんのこと，稼働中のシステムを最小ダウンタイムで移行したい。それを叶えるにはMySQL 5.6を，既存のMySQL 5.0を用いたMaster-Slave構成のレプリケーションに追加し，段階的移行をする必要があります。この段階的移行おうとする中で，Tritonn(MySQL 5.0)で動く更新系クエリをMySQL 5.6およびmroonga互換にするという壁が現れます。

今回はその壁を乗り越え，MySQL 5.0のレプリケーションマスタにMySQL 5.6をスレーブとして追加するところまでを，詳しく解説していきます。

MySQL 5.0からMySQL 5.6へのデータマイグレーション（事前準備編）

移行対象のサーバ構成

移行対象のサーバ構成は次の図の通り，レプリケーションマスタをDRBDで冗長化している以外，オーソドックスなMySQLのMaster-Slave構成のレプリケーションです。

これらは，Tritornnの最終リリース版であるMySQL 5.0.87 + Senna 1.1.4 + mecab 0.98を利用し，レプリケーションマスタはDRBD + keepalivedを用いた冗長化を行っています。ストレージエンジンは基本的にInnoDBを，フルテキスト検索を用いる場合にはMyISAMを利用しています。

移行の進め方とサーバ構成

既にTritonnで稼働中のシステムをmroongaへ移行するわけですから，ダウンタイムを最小にしたアップグレードを行う必要があります。

そこで，既存MySQL 5.0レプリケーションマスタの下に，MySQL 5.6のみで構成するレプリケーションを追加するという手法を採用しました。この，いわゆる「孫スレーブ構成」を取ることで，プログラムからの更新系・参照系クエリの発行先をMySQL 5.6のマシンに切り替えるだけで移行ができます。

今回の記事では第1段階のステップ5，MySQL 5.0と5.6の混在レプリケーション構成を作るまでを解説します。

第1段階

MySQL 5.0のスレーブにMySQL 5.6を追加します。月に1度しか動かないCronによる定期実行タスクを考慮し，この状態で1ヶ月の稼働試験期間を設けます。後ほど紹介する，変更が必要な更新クエリを先に潰せていれば特にトラブルはありませんが，レプリケーションが止まるようなクエリに遭遇した場合には随時対処しましょう。

具体的には次のように，6つのステップに分けて進めます。

1. プロダクション環境のスレーブを複製し，MySQL 5.0用の作業サーバを用意する
2. MySQL 5.0用の作業サーバから，Tritonn依存のFULLTEXTインデックスを除去する
3. Tritonn依存の無くなったMySQLのダンプデータをMySQL 5.6へ流し込む
4. 更新クエリをTritonn・mroonga互換の実装にする
5. 既存のMySQL 5.0レプリケーション構成に，ダンプデータの流し込まれたMySQL 5.6をスレーブとして追加する
6. MySQL 5.6スレーブにmroongaをインストールし，mroongaを用いたフルテキスト検索対応のスキーマに更新する

第2段階

MySQL 5.0のスレーブに追加したMySQL 5.6を複製し，孫Slaveを追加します。これで，MySQL 5.6のみで構成するレプリケーションが構築できました。この時期には参照クエリに関してもTritonn/mroonga両対応になりましたので，影響範囲や時間を絞った上で，参照クエリのみMySQL 5.6のスレーブに振り分けるという稼働試験を行いました。

具体的には次のような細かいタスクとなります。

1. MySQL 5.6スレーブをの配下に，MySQL 5.6の孫スレーブを作る
2. 準同期レプリケーションの設定をMySQL 5.6のレプリケーションマスタ・スレーブに行う
3. 参照クエリ稼働試験として，影響範囲と時間を限定した上で部分的にプロダクション環境へ投入する
4. プロダクション環境からの参照クエリを，MySQL 5.6スレーブに完全に切り替える

第3段階

プログラムから利用するサーバを，MySQL 5.6のレプリケーションマスタ・スレーブに完全に切り替えます。レプリケーションマスタの切り替え以降は，データの整合性的な意味合いで切り戻しができません。そのため，慎重に行う必要があります。

具体的にはこのような細かいタスクとなります。

1. 更新系クエリを止めるため，サイトをメンテナンス画面に切り替えてオフラインにする
2. MySQL 5.6にバイナリログがすべて到達していることを確認した後に，レプリケーションから切り離す
3. MySQL 5.6のレプリケーションマスタに更新クエリが直接発行されるアプリケーションをデプロイする

この段階的移行手法をとる場合の注意として，現レプリケーションマスタで実行される更新系クエリがMySQL 5.0およびmroonga (MySQL 5.6)の両方で動く必要があります。

具体的にはFULLTEXTインデックスへ作用するCREATE TABLEやALTER TABLEといったスキーマを修正するクエリが対象となります。例えば，検索テーブルにおいて参照するテーブルと更新するテーブルを分けて，更新が終わり次第その2テーブルを入れ替えるという運用の場合には確認が必要です。この2テーブル運用は，更新中は排他ロック (テーブルロック) となり，参照クエリの実行ができないというMyISAMの制約から生まれたパフォーマンスチューニングです。