隔週連載groonga

第10回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド(3)

この記事を読むのに必要な時間:およそ 9 分

mroongaのプロダクション環境への投入

以前の記事で紹介した「Tritonn」から「mroonga」への移行ガイド(2)移行の進め方とサーバ構成の第2~第3段階を実施する準備ができました。つまり,次のような流れでアプリケーションから利用するデータベースをmroongaに切り替えれば移行完了となります。

第2段階
  1. MySQL 5.6スレーブをの配下に,MySQL 5.6の孫スレーブを作る
  2. 準同期レプリケーションの設定をMySQL 5.6のレプリケーションマスタ・スレーブに行う
  3. 参照クエリ稼働試験として,影響範囲と時間を限定した上で部分的にプロダクション環境へ投入する
  4. プロダクション環境からの参照クエリを,MySQL 5.6スレーブに完全に切り替える
第3段階
  1. 更新系クエリを止めるため,サイトをメンテナンス画面に切り替えてオフラインにする
  2. MySQL 5.6にバイナリログがすべて到達していることを確認した後に,レプリケーションから切り離す
  3. MySQL 5.6のレプリケーションマスタに更新クエリが直接発行されるアプリケーションをデプロイする
  4. メンテナンス画面を解除する

さて,レガシーとなったMySQL 5.0を捨てて,MySQL 5.6への移行を行う準備は整いました。 事前の予行演習無しでの移行は大変なリスクですので,同様の構成を仮想マシンで作成し,当日立ち会うスタッフと共に手順の読み合わせや調整を行います。それを何度か繰り返すうちに個別業務要件に合った手順書ができると思いますので,それを元に当日の切り替え作業に臨みます。そして五月雨式にシステムの切り替えを進め,これといったトラブルも無くあっけなく移行は完了させることができました。

なお,第3段階のMySQLマスタ切り替え時のメンテナンス画面切り替え後は,MySQL 5.0のマスタに更新系クエリが来ても受け入れないようにするため,set global read_only = 1というクエリを発行しました。また,メンテナンス画面の作用範囲には動作試験時に使うグローバルIPアドレスを除外し,アプリケーションデプロイ後の最終稼働試験や品質テストを行いました。

振り返ってみると,ここに行き着くまで・後に行った次のような事前の品質テストが大変でした。

  • トークナイザやノーマライザの組み合わせによる検索ヒット数の違いと最適な組み合わせの検討
  • 検索クエリの動作確認のため,アクセスログから抜き出したURL情報を用いて試験環境で走らせても落ちないことを確認
  • MySQL 5.6で改善されたオプティマイザにより,逆に遅くなったクエリの調整
  • MySQL 5.6でより厳格となったSQLMODEへの追従

例えば3つめの遅くなったクエリの調整は事前の洗い出しが大変手間なため,移行後にスロークエリ集計と逐次対応を行う計画を盛り込んだことで,迅速なクエリチューニングができました。

こういった大規模な切り替えにはリスクは伴いますが,試験環境でのバグ収束を確認できたところで早々に移行を行い,その後に見つかった些細な不具合は随時改修するという対応が良いと思います。

Tritonnからmroongaへ移行する際の要注意ポイント

移行中にハマった要注意箇所は次の通りです。

文字のエスケープ

Tritonnではこれまで緩い処理であったところが厳格になったため,先ほどの「Tritonnからmroongaへの全文検索クエリ書き換えガイド」にて紹介したような,ダブルクォートで囲うだけでなく必要に応じてエスケープする処理が必要になりました。

TokenMecabを用いた際のハマリポイント

記号や半角数字等が4,097文字以上連続すると,トークナイズできないためにINSERT時には無視され,warningとなります。

メモリチューニング

MySQL 5.0時代から使っているmymemcheckを引き続き利用しました。mroongaテーブルのデータは空でもFULLTEXTインデックスを作成しただけで/var/lib/mysql以下の*.mrnファイル群は相当な容量を使いますので,空きメモリを多めに確保しておきましょう。

mroongaのトラブルシューティング

運用中に遭遇したトラブルシューティングをまとめておきます。

API version for STORAGE ENGINE plugin is too different

mroongaで「API version for STORAGE ENGINE plugin is too different」というエラーが起きたときの対処法が参考になります。

.mrnファイルがlock failedとなる

groonga/mroongaの.mrnファイルがlock failedとなった場合の復旧方法が参考になります。

ERROR 1005 (HY000): already used name was assigned

存在しないはずのテーブルが作れない。その場合にはmroonga内の管理データに異常が起きていると推測できます。mroongaで「ERROR 1005 (HY000): already used name was assigned」エラーが起きた際の復旧手順が参考になります。

まとめ

Tritonnからmroongaへの移行プロジェクト,遂にフィナーレを迎えました。移行中に踏み抜いた不具合は数知れず,しかし開発者の皆様との密な連携によりその困難を乗り越えられました。ありがとうございます。

なお,この移行プロジェクトでは数多くの自社WEBサービスを対象に,五月雨式にTritonnからmroongaへの乗り換えを行いました。約3ヶ月に及ぶ検証と実移行を終えた今,プロダクション環境にてmroongaを入れた総計40台以上のMySQL 5.6サーバが稼働している光景はとても感慨深いです。

近日開催のMySQL Casual Talks vol.5にて,ここでは書けないようなお話も交えてお話させていただく予定です。時期としてはYAPC::Asia Tokyo 2013の後に開催予定と聞いておりますので,ご興味のある方はぜひお越しください。

追記:「MySQL Casual Talks vol.5」は,2013年10月25日(金)に日本オラクル 青山センターにて開催です。

Tritonnからmroongaへの移行プロジェクトのご声援ありがとうございました。それではまた,どこかでお会いしましょう。

次回予告

次回はいよいよ最終回です。⁠読者の皆さんがgroongaを使いたくなる!」ことを目指して,2013年4月2日より約半年にわたり隔週でgroongaの情報を届けてきました。最終回ではgroonga関連プロダクトの最新情報と今後の展望について紹介します。

週刊groonga on Qiita

もっとmroongaを知りたくなったらQiitaにあるmroonga情報もチェックしてみてください。毎週木曜日にgroonga関連情報を提供しています。

著者プロフィール

吉田健太郎(Kentaro Yoshida)

株式会社リブセンス,Web系インフラの研究開発エンジニア。

ITベンチャー立ち上げに参画し,幅広い領域での経験を積むこと8年目。フルスタックエンジニアを目指して,湧き出るアイディアを形にする日々を過ごしている。

GitHub:https://github.com/y-ken/
ブログ:http://y-ken.hatenablog.com/

コメント

コメントの記入