読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

鯖缶主婦の日々の記録です

MySQLCasualTalksVol5にいってきた

こんにちは。smallpalaceです。

タイトルどおりMySQLマニア達が集うわりとガチな会で勉強させていただいてきた個人的な備忘録を。誤字があったら後日なおします。

始まる前から飲んでる人がいるような雰囲気でした。

午前中にオラクルさんのセミナーもあって盛りだくさん。下のロビー階ではハロウィンイベントでハロウィンコスの子どもたちがいっぱい来てたりお祭りでした。

イベントのページは↓こちら。

http://www.zusaar.com/event/1086003

ハッシュタグ:#mysqlcasual

とぅぎゃったー:http://togetter.com/li/581621

アンケート有りhttps://docs.google.com/forms/d/1hZFgCPzRVycI_WQPaxX3sTV9kWTIgkGWNwJhgdo5Y8Y/viewform

皆様のブログ:

 http://y-ken.hatenablog.com/entry/mysql-casual-talks-vol5-mysql-migration

 http://instagram.com/p/f5AsHPFAAb/

 http://b.l0g.jp/mysql/mysql-casual-talks-vol-5/

 http://onigra.github.io/blog/2013/10/25/lightning-talked-at-mysql-casual-talks-5/

 http://nsrzakki.hateblo.jp/entry/2013/10/27/030616

 http://norii.hatenablog.com/entry/2013/10/28/001553

------

@Yuryu MySQL 5.6 で GTID を試してそっと閉じた

いわおさん。フリークアウトの人。女性は初かも?大阪の人

http://www.slideshare.net/Yuryu/mysql56gtid

GTIDとは、

mysql5.6から実装されたGlobalTransactionID、トランザクションごとに固有のUUIDを付与

自分がどこまで実行したかをクラスタレベルで記録

show variablesとslave statusで見れるやつがある

GTID_NEXT次にどういう名前がつくかUUID:番号。デフォルト値はAutomatic

自分のUUIDをもとに連番を作成

GTID_Executed実行したトランザクション。UUID:start-end

Executed_gtid_setも同じ内容

GTID_Purgedバイナリログに記録されたやつ。

Retrieved_Gtid_setマスタから受信したやつ

フェイルオーバ後にChange Masterしたあとは新しいマスタのUUIDで連番がつくので2行になる。

GTIDの利点

 トランザクションが一意に識別可能に、binlogのポジションを自動決定、スレーブがマスタに昇格しても大丈夫(Change masterで自動ポジション決定)

 mysqlfailoverとmysqlrepladminでマスタ切替が便利

GTIDの欠点

 クラスタ内でGTID有効・無効の混在不可(全ノード停止して再起動必要)

 MyISAMが使えない、まだ枯れてない、運用ノウハウの不足、それMHAでできる

不都合との遭遇

 FLUSH LOGSでレプリケーションがとまる

  5.6.11固有のもの。GTID_NEXTがAutomaticでないときに暗黙のトランザクションを禁止しようとしてとまった

 転送中のトランザクションがStop/Start slaveでスキップ

 ネットワーク切断されると転送中のトランザクションがスキップされる

  でっかいばぐだと思う

将来的にGTIDの固有のメリットがあればつかうかもなので勉強はつづける

------

@con_mame 僕達のMySQL5.6移行記(仮)

クックパッドの人。ほしのさん。

http://www.slideshare.net/conmame/mysql56-27565355

普段はAWSとかRedshiftとかいじっている。

おむすびけんで5.6つかってる。ほかにもマネジメントツールとかいろいろ。RDS一部つかってる。

検証は5.6.6からしている。Replicationしつつ本番で流れるクエリをためしてた。

最初だけ意外と素直に進んだ。

5.6のDB群を用意してswitch、メンテナンスでupgrade

EBSのsnapshotを作成して5.6群を作成しアタッチしてrepしてばつっと切り替え

スキーマ・クエリでワーニングでないか、新パラメータでDeprecatedなのがないか

パフォーマンス、スロークエリやレスポンスとCPUメモリ

アプリのライブラリ動作などを確認

kageというやつでプロダクションへのクエリをsandboxにも投げるというのをして試していた(双方同じクエリが流れるがユーザにはプロダクションからしか帰らない)

kageは双方のリクエストのdiffを取ることができる

実際のリクエストで発行されるクエリでテストが行えて便利。

 漏れが少なくread/writeを実際に動作をさせながら確認できる

DB自体の不可試験は別途行う

テストが行いやすくアプリケーション・DB各レイヤで確認できる

開発・検証用のDBとしてバージョン・設定を変えて動作させる。開発中のクエリは実際に使用される可能性がある。

各種環境を用意してバグが直ってんのかとか色々みてる。Mariaも入れようとしてる

本番サーバは一定時間おきにsnapshotがとられている

5.6はじゃじゃ馬

GTIDは運用負荷が高い。replicationエラーでスキップできない

デフォルト値の変更やヒスイセンナもの

explict_defaults_for_timestanp

binlog_checksum

p_fがメモリ食いまくりなのでsmall以下だと厳しい

ピークタイムでレプリケーションエラー起こったら空コミット打つこの手順は厳しい

バグを結構いっぱい踏んだ

5.6はそろそろ気軽に使える(GTIDとpaformance_schemaオフればよいはなし)

検証はしっかりと。kage便利

Q:bugsどうみてる

A:5.6指定でみてます

Q:5.6はほんとにパフォーマンスあがってる?

A:結果的に同じクエリで落ちてたりパフォーマンス食って下がるとこはあるがそれ以外はあがってるところも。

--------

@yoshi_ken MySQL5.0(Tritonn)から5.6(mroonga)への移行体験記 〜[技評連載記事](http://gihyo.jp/dev/clip/01/groonga)の裏話編〜

よしださん。LIVESENSEのなかのひと。全文検索エンジンの話。

デベロッパーズステージに寄稿してるので移行するときは読んでみて。

最近はfluentdがすき。プラグインつくりました。

5.0つかってるのが恥ずかしかったのとCPUスケールを狙って移行しようと。

5.6の魅力

 memcacheAPI、バッファプール暖機運転、セミシンクrep、クラッシュセーフなスレーブ、InnoDBパーティ初任具、AlterTableの高速化とか

3月に実行しようという話になり、事前調査4~5月、検証、6月に不具合が取り除かれたので移行しようと。先月安定稼動に入った。

対象サイト20サイトくらい、合計70台、マスタはDRBDでミラーリング、HAはkeepalived、孫スレーブにrepして切り離す計画でした。

粛々と移行できた。オンプレなので保守切れに伴う一括購入のおかげでリッチな環境で切り替えができた(いいな~

少し大変だったこと

 検索ヒット数の違いと最適な組み合わせの検討

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

数字で振り返る移行プロジェクト、3ヶ月かかった

 mroonga修正がいくつか

 想定外のH/Wトラブル、IPMI経由で再起動ができないのでリセットボタン押す依頼をしたけど焦げ臭いといわれた(2台)NECの電源周りのロット不良だそう2/70台

プラクティス

 パフォーマンスは、5.0からでHWスペックもかなり違うし色々あるけどあがったのも下がったのもあるけど安定稼動すればいいでしょうということで。

 GTID semisync+MHAの組み合わせがいいと個人的に思っています

 SQLモード sql_mode=NO_ENGINE_SUBSTITUTION にしました(oranieさん参考にしました

 mysql_upgradeコマンド

  mysqlupgradelせずにmysqldumpコマンドを使いました。5.0に5.6からつないでmysqldumpした。逆はset_gtid_purgged=ONしないとだめ

 tritonnからmroongaへの移行は技術評論社のページをごらんください

 http://gihyo.jp/dev/clip/01/groonga?ard=1382701510

まとめ

 memcachedAPIはメモリリークのバグがあるため結局使えず

 http://bugs.mysql.com/bug.php?id=68530

最後に人材募集

-----

@yoku0825 非常識DBA grumbles(仮)

みんな大好きMariaDBも10.0.2からGTIDに対応してます。5.6とは書式もちがうし色々違うのでよくわからない

とあるイルカのバーボンハウス

http://www.slideshare.net/yoku0825/ss-27597161

yoku0825さんの ぐちの話だそうです。

命名規則などなどがめちゃくちゃなDDLの紹介。予約語で名前つけたり。

容量節約第一で修正提案を。

インデックスの名前は基本カラム名。where狙ってるのかorderby狙ってるのかわかるように絞り込む順にカラム名つける

名前から型が推測できると素敵。どこ狙ったクエリなのか一目瞭然。

コードだけで会話する必要はないが意思の疎通がコードだけで捗るとステキ

------

ビール飲んだ人用の休憩

------

@kamipo 今週ネタ仕込む余裕ないからmysql-build関連の話すると思います…!

kamipoさん

mysql-buildメンテされてないんじゃという指摘への反論

mysql-buildにプラグインを入れれるようにした。ハンドらソケットも使えるようになったよ。

オプションの第一引数にバージョン2番目にプラグイン、

やってることはbashスクリプトでとってきてがっちゃんこしてビルドしてる

昨日ぺるこなサーバのあたらしいやつも入るようにした。

おっと思った新機能。mysqldumpのオプションのdiff。--innodb-optimize-keys 一回keyをはずしてdumpしといて後でまた貼るみたいな。(※まだバグがあるらしい”https://t.co/CrJAxjWQGl”)平塚さんのデータロードの話でも紹介されてた。サイズも後で張ったほうが小さくなる。pelconaには追加されてる

diffはgistにあげてあるkamito/7151.。。メモリきれず。

InnoDBIndexfullscanを早くした話facebook ロジカルリードアヘッドを実装したやつがFB版の5.6。pelconaのdiffをみるとfb版にもさっきのoptimeize-keysとlraなんとかがついてる。

メンテはしててがんばってます。気軽に@kamipo大丈夫です。とのこと

-------

@do_aki 殿堂入りのアレ ~Multi-Source Replication を添えて~

http://www.slideshare.net/do_aki/ss-27565738

マスタ分割するとjoinできないのでn:1レプリケションを2秒に一回切り替えるというやつの人。

マルチソースレプリケーションの話5.7のやつ

まだlab版で5.7に入るかも不明

並列に同時接続できるようになる。channellできりわけていて、changemasterでchannelを指定する。けっこうべんりそう。

接続設定をテーブルにする必要があるがGTID必須とかでなくて気軽に使えそう。

ピュアSQLでマルチマスタしてる人が実はより前にいたw

データディレクトリを同じとこにする(MyISAM)方法もあるよう。

MySQLで変態的なことを考える人多いみたい。

-----

@Rkajiyama 殿堂入りできないLabs ~Multi-Source Replication を添えて~

かじやまさん。

http://www.slideshare.net/rkajiyama/20131025-casual-uppt

PerconaToolkitもいいけどMySQLUtilityのことも思い出してください

labs.mysql.comのやつの紹介。絶対にプロダクション環境でつかっちゃだめよ。

HadoopAplier for MySQL 

 Insertしかできない。ほかのことがしたい場合はパッチをかくか待つか。

MySQLJSONUDFs 

 yamasakiさんにきいてね

マルチソースレプリケーション

 さきほど説明されたとおりchannelつかうのでFor channel=がいっぱいつく

MySQLUtilities

 けっこうべんりなのでぜひつかってみてね

Fablic

 シャーディングしてくれるやつ。マスタスレーブ構成のグループにしておいて、管理サーバが判別してアプリケーションに場所を返すとコネクタがそれを取得して情報をとりにいく

 アプリケーションは場所しらなくて大丈夫

 まだ設計だけで実装は追いついてないそうです

 フェイルオーバも自動だけど皆大好きGTIDが必要。

 いまはphppythonjavaのコネクタのみ。

 vnwrites.blogspot.comをみてくださいドキュメントは間違ってます

MySQLUtilities-Fabric + MySQL MulitisorceReplication + MultiThreadSlave (GTIDひつよう)

 つかってみてバグレポートよろしく

AffectsMeというボタンが増えたので同じ目にあってる主張がbugsでできる

告知 11/13~15 db tec showcase 松信さんもくるよ、山崎さんが5.6のパフォチューとか、奥野さんがclusterの徹底解説とか、梶山さんが5.7の解説とかしてくれる

日本語の5.7マルチソースレプリケーションの記事あるとつぶやいてた人が。

http://yakst.com/ja/posts/73

----

LT枠

----

@songmu : GitDDL::MigratorもしくはApp::RunCron
カヤックの人。perlの人。パールモジュールの話をします。
マイグレーションスキーマのバージョン管理をするときにバージョンを数値にすると厳しいし時間でも厳しい
ブランチ間でのマイグレーションもむずい
それを解決してくれるモジュール。SQL::Translator。キモイアイコンでTシャツも。
異なるデータ定義方法の相互変換をするすごいやつ。SQL::Translator::Diffも。
任意のDDLを比較して差がだせるようになってる
GitDDLの考え方、gitでバージョン管理する。バージョニングテーブル
何が便利かというと、ブランチを行き来しながら適切に差分SQLを当て込むことができる。
mysqldumpするよりGitDDLのほうが早くて快適
 バージョン管理してないテーブルがあったりするかも
できないこと、トリガとかパーティショニングいれてるやつは解釈できない
cronだと、スクリプトの成否を皇族の処理に通知できない
kazuhoさんのつくったcronlogがかゆいところに手が届く便利さ
runcronをこぴぺしてつくった。アプリケーション用のバッチしょりをラッパーコマンドかいて処理する
色々通知できる、つかってみてください
----
@nekogeruge_987 : MySQLへの移行を支える技術
Yudaiさん、web系の会社きんむ、DBにかかわらず色々している
DB2からMySQL5.5に移行した話を。(超ざわざわしたw
基幹システムとかサービス系とかきなくさいかんじのワードが。成功して数億円経費削減した。
オフラインメンテ8時間のうち移行時間4時間
コールドバックアップのが早かったとかいろいろとめれるログはとめたとかkeyの無効有効とかいろいろあるが、
全体的な処理の短縮にはそんなに影響なかった
cronでいろいろしたのできつい。PuildPipelinePluginが協力になった感じJobFlowをGroovyが便利
この案件tのあとにTiboliとかJtokaしった データ移行をCIするような感じで毎日回す
1クリックデータ移行をめざした
完全自動化もできたかも
ジョブスケジューラのオープンソースソフトウェアについて便利なのあったらおしえてください
/var/lib/mysql配下を全部スレーブにrssyncするみたいなシェルをつくったり
なんとか20分でできたりした
shunit2というシェルのフレームワークが便利
-----
@monry : AWSネタを何か
RDSの話(でもおたかいんでしょう?みたいな
森さん。きこん。お酒と合唱がすきだそうです。
kidsスターという教育アプリをつくってるそうで。仕事はなんでもや。
お金のはなし。スレーブはmicro5台、マスタはsmall?1台、先月は23000円くらいだった。物理サーバだと13万くらいなのでRDSのがお得ではあるかも。
-------
@chobi_e : ストレージエンジンで遊んでみた
ケーブルわすれてしまったそうで。
あとで資料UPするのであるていでイメージしてください。
ストレージエンジンを作ってみたはなし。
kazuhoさんが10/1にmysqlのストレージエンジンの話をしていた。
リアルタイムランキングのストレージエンジン作成をやってみようということでつくってみた
初心者がどうやってかけばいいか。mysqlカスタムストレージエンジンとかで検索するとでてくるが
エキスパートmysqlの10章で6時間くらいでできる。
ランキングならふつうredisつかうのでそこからもってきた。
githubにおいてますhttps://github.com/chobie/ChobieDB
Indexはいまつくってるところ
mysqlほんとすごいなと思った

 

そのほか、sh2さんがAffectMe押そうとつぶやいてたGTIDのバグレポート(松信さんがかいてる

http://bugs.mysql.com/bug.php?id=69943 

http://bugs.mysql.com/bug.php?id=70669

 

以上です。楽しかった。

資料のURLとかはみつけたら載せようかと思います。

読んでいただいてありがとうございました。またそのうちに。