page

Oct, 201325th

Tritonn (MySQL-5.0.87+Senna)からのmroonga (MySQL-5.6) 移行体験記Kentaro Yoshida in MySQL Casual Talks Vol.5 at Oracle

1

page

そう、前回の発表では...

2

page 3

http://www.slideshare.net/y-ken/my-sql-56innodb-fts

page 4

page 5

page 6

page

あれから半年...

7

page

お待たせしました！

8

page

Oct, 201325th

Tritonn (MySQL-5.0.87+Senna)からのmroonga (MySQL-5.6) 移行体験記Kentaro Yoshida in MySQL Casual Talks Vol.5 at Oracle

9

page

1. はじめに2. 自己紹介3. 移行する3つの理由4. MySQL5.6の魅力とは5. 移行計画6. ハプニング7. プラクティス8. まとめ

本日の流れ

10

page

1. はじめに

11

page

gihyo.jp へ寄稿しました

12

page

お待たせしました！

13

http://gihyo.jp/dev/clip/01/groonga

page 14

page

執筆したタイトル

15

第6回　[実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（1）

第7回　[実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（2）

第8回　CentOS6でのRPMパッケージを用いた MySQL 5.6 & mroonga & PHP 5.4 環境の作り方

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

page

この連載の裏話をお届けします

16

page

2. 自己紹介

17

page

自己紹介

18

•よしけんさん

• (株)リブセンス

• Web系インフラの研究開発エンジニア

• MySQL歴 約10年

好きなプロダクト

page

3. 移行する3つの理由

19

page

移行する3つの理由

20

今時MySQL 5.0を使っているなんて・・・世のトレンドから遅れている感が否めなかった

CPUスケーラビリティの高いInnoDBを使いたい

MySQL 5.5～5.6で導入されたモダンな機能を使いたい

page

4. MySQL 5.6の魅力とは

21

page

MySQL 5.6の魅力とは

22

memcached API

バッファプールの暖機運転

Semi-Synchronous Replication

クラッシュセーフなスレーブ

より強化されたInnoDB Partitioning

ALTER TABLEの高速化

などなど http://www.slideshare.net/nippondanji/mysql-56dbtechshowcase2012

page

5. 移行計画

23

page

2013年7～8月2013年6月2013年4～5月2013年3月

安定稼働移行検証事前調査プラン立案

移行計画 スケジュール

24

page

移行計画 規模

25

対象サイト数

約20サイト

対象データ容量

トータル約300GB

page

移行計画 構成

26

ハードウェア

旧構成 NEC Express5800/iR120a-1E (4C/L5520)

新構成 NEC Express5800/R120d-1M (6C/E5-2630L) x 70台

MySQL, OS

旧構成 MySQL 5.0.87 (Tritonn 1.0.12a) on CentOS 5.6

新構成 MySQL 5.6.12-2 (mroonga 3.05) on CentOS 6.4

page

移行計画 構成変更プラン

27

http://gihyo.jp/dev/clip/01/groonga/0007

page

移行計画 構成変更プラン

28

page

移行計画 構成変更プラン

29

page

移行計画 構成変更プラン

30

page

移行計画 少し大変だったこと

31

トークナイザやノーマライザの組み合わせによる検索ヒット数の違いと最適な組み合わせの検討

検索クエリの動作確認のため，アクセスログから抜き出したURL情報を用いて試験環境で走らせても落ちないことを確認

MySQL 5.6で改善されたオプティマイザにより，逆に遅くなったクエリの調整

MySQL 5.6でより厳格となったSQLMODEへの追従

page

6. ハプニング

32

page

数字で振り返る移行プロジェクト

33

page

数字で振り返る移行プロジェクト

34

3ヶ月

検証・移行期間

16件

mroongaの機能改善や不具合改善

273件

mroongaメイン開発者の須藤 (@ktou) さんとのメンション数

2件

想定外のH/Wトラブル

page 35

page

須藤さんを始めとする　クリアーコードの皆様、ありがとうございます。

36

page

想定外のH/Wトラブル

37

page

想定外のH/Wトラブル

38

つまるところ、サーバ故障です

時期は慣らし運転・稼働テストも完了し、本番切替の1週間前

対象機は、レプリケーションマスタのDBサーバ

死活監視の設定をそろそろ入れようと思っていた頃

page

想定外のH/Wトラブル

39

朝オフィスへ出社すると運用担当の同僚から声が掛かる。

サーバが突然落ちて、IPMI経由での再起動すら出来ないです。

ほう、それではDCのスタッフにリセットボタンの依頼ですかね。

page

想定外のH/Wトラブル

40

現地のDCスタッフより入電。

ラック前に着きました。

リセットボタン、効きません。

そしてなんだか、焦げ臭いです。

社内スタッフ：「え・・！？」

page

何か焦げてる

41

page

想定外のH/Wトラブル

42

page

想定外のH/Wトラブル

43

page

悪いことは続くもので、別機体でCPUの異常クロックダウンが発生

44

page

7. プラクティス

45

page

移行後のパフォーマンス

46

サービス毎に特性が違いすぎたため、詳細データは取っていません

早くなった/変わらない/遅くなったサービス、それぞれあります

オプティマイザの仕組みが変わった影響だと思います

page

GTID

47

あっ・・（察し

現実的に Semi-Synchronous Replication + MHA が個人的にオススメ

未来は明るい・・と思います

参考記事http://y-ken.hatenablog.com/entry/mysql-using-gtid-checklist

page

sql_mode

48

/usr/my.cnf に従来の挙動とは異なるデフォルト設定が入る

STRICT_TRANS_TABLES は従来の動きと異なるため削除し、/usr/my.cnf は自動構築時に次の内容で上書きするようにしました。sql_mode=NO_ENGINE_SUBSTITUTION

参考ページhttp://d.hatena.ne.jp/oranie/20130402/1364906656

page

mysql_upgradeコマンド

49

mysql_upgradeは使わずに、mysqldumpコマンドを使いました

MySQL 5.0 → 5.1 → 5.5 → 5.6 というアップグレードであるため、1つずつバージョンアップするのは手間が掛かる

ibdata1が”超”肥大化している事で作り直しが必要であったため

innodb_file_per_table化を実現したかった

page

mysqldumpコマンド その1

50

MySQL 5.6環境からmysqldumpコマンドでMySQL5.0に繋がらない

mysqldump: Couldn’t execute ‘SELECT @@GTID_MODE’: Unknown system variable ‘GTID_MODE’ (1193)

対処法としては、 --set-gtid-purged=OFF を付ける

page

mysqldumpコマンド その2

51

MySQL 5.0環境からmysqldumpコマンドでMySQL5.6に繋がらない

対処法としては、MySQL 5.6で実行する

参考ページhttp://www.mk-mode.com/octopress/2013/06/02/mysql-5-6-mysqldump-set-option-error/

page

MySQLユーザ認証

52

MySQL 4.x時代からユーザ情報を引き継いでいるシステムもあり、クライアントライブラリもMySQL5.6に更新した都合上、繋がらないMySQLサーバがあった

mysql.user.password が16バイトならば該当します

php-mysqlnd を使う場合には特に注意しましょう

参考ページhttp://www.softel.co.jp/blogs/tech/archives/2225

page

全文検索機能の選定

53

Solr アプリの改修工数的に今回は採用を見送り

InnoDB FullText Search人柱すぎる＆当時はメモリリーク不具合があるため採用を見送り

ftppc (full text parser plugin collection)MyISAM依存・速度面・Wプラグマ非対応な点から採用を見送り

mroonga根気と突破力で潰した不具合ラッシュも落ち着いたので、採用決定注) 2013年秋現在は不都合無く安定稼働中

page

Tritonnからmroongaへの移行Tips

54

その他の詳細な移行Tipsに関しては、gihyo.jp連載にまとめていますTritonnからmroongaへのテーブルスキーマ書き換えガイドTritonnからmroongaへの全文検索クエリ書き換えガイドTritonnからmroongaへ移行する際の要注意ポイントRPMパッケージを使ってMySQL 5.6.12，mroonga，PHP 5.4の環境を作る方法などなど... http://gihyo.jp/dev/clip/01/groonga

page

8. まとめ

55

page

まとめ

56

MySQL 5.0 サーバが無くなった

MySQL 5.6 + mroonga 環境に移行することが出来た

mroongaは4～5月の不具合修正ラッシュ以降はかなり安定した

memcached APIは メモリリーク Bug #68530 のため結局使えず

page

まとめ

57

Now, mroonga is ready for production!

お知らせ

お知らせ

page

Thanks!

65

ご清聴ありがとうございました。