京王線でも上手にJAWSと付き合って行こう

JAWS-UG Advent Calendar 2014の10日目です。最近寒さが厳しくなってきている中、すべり気味なタイトルで更に寒さを増してしまっていること、反省しています。技術ネタではないです。

はじめから結論、「JAWS-UG京王線」やります!

初めましてな方もそうでない方も、出オチですみません。JAWS-UG京王線やります!年明け1月にでも第0回ができるよう準備を進めていますので、京王線井の頭線沿線にお勤め/お住まいの皆様、沿線に縁のある方はぜひ参加していただければと思います。勉強会のテーマとしては、自分がインフラや運用を担当しているというのもあって、「AWSの運用・監視・トラブルシューティング」まわりのネタで構成できたらいいなと思っています。

現在、cloudpackの吉田さん、(一部で話題の)肉会メンバーであるSendGridエヴァンジェリストの中井さん&サーバーワークスのぎょりの協力のもと話を進めています。さらに、ISIDの品田さんも協力してくださるとおっしゃってくれています。会場としては京王線ならではということで電通大が使えたらいいなと思って、ハートビーツの藤崎さんにお願いして電通大が使えないかを調整して頂いています。他にもご協力いただける方がいましたら、Facebooktwitter経由でご連絡いただけると嬉しいです。

と、いってみたものの、どれくらい参加者・協力者が集まるのか不安な部分もありつつ、吉田さんと肉会メンバという謎の安心感のあるメンバがいるので、なんとかなるかなとも思っています。

事の発端

言いたいことは言ったので、ここからは流す感じで。

なぜに京王線勉強会をやろうと思ったか、学生時代からずっと住んでいる京王線をもっと盛り上げたいなと思ったのがきっかけです。その結果、肉会の帰りにした以下のツイートが吉田さんに捕捉され拡散されるに至り、退路を絶たれたわけです。

退路を絶たれたと言うとネガティブに聞こえますので、背中を押してもらったといったほうがいいですねw

そもそもJAWS-UGとの出会い

自分の所属についてプライベートな場で触れることは(マイナス面が大きすぎるので)ほとんどないのですが、ブログ上では発表資料を公開しているので今更隠す必要もないですよね。

EightをPrivate BetaからPublic Betaにするにあたって、もともと使っていたサービスから他のサービスに切り替えるかどうかという話があったわけです。その時に、(Eightがメインではなかったにもかかわらず)自分が使いたいという思いからAWSを猛プッシュしたまでは良かったんですが、設計のお作法がよくわからなかったんです。。途方に暮れそうになっている中で、すごくちょうどよくJAWS-UG東京勉強会(2011年12月のやつ)が開催されることを知って、藁をもつかむ思いで参加したのが最初でした(補欠だったけど)。そこで出会ったサーバーワークスさんには設計の協力をしてもらったことをきっかけに、プライベート含めて仲良くさせてもらってますw

今の自分とJAWS-UG

業務上必要にかられてのスタートでしたが、その後は自分の興味から積極的に東京勉強会には参加させて頂いています。人見知りの激しい自分にとっては、懇親会とかでぼっちになる確率が高く厳しいこともありますが、知り合いも増えてきて楽しく過ごしています。

1度だけJAWS Days 2013で発表をさせてもらったきり、発表をしていないのは心苦しいですが、最近では、AWSウルトラクイズで運良く優勝してしまって、ラスベガスで開催された最大のイベントであるre:Invent 2014に参加させていただくことができました。本当に貴重な体験をさせていただけて、すごくプラスになっただけでなく、本気で英語できないとダメだなとも実感させられました。はい、頑張ります。。ただ、re:Inventに参加できたことで、AWSを使うだけでなくJAWS-UGというコミュニティへの関わりを変えていけたらいいなと思うようになってきました。

そんな中で、12/2に開催されたCloud Roadshow 大阪には有給をとって完全プライベートで参加してきました。大阪という場もあるのでしょうが、JAWS-UG関西のLT大会は東京の勉強会とはまた違った感じでエンターテイメント感が強いもののように感じました。運営側がすごく楽しそうに進行していたこと、懇親会でADSJの小島さんが熱く語っていたJAWSというコミュニティの素晴らしさ、懇親会解散後に遅くまで飲みに付き合ってくれたサーバーワークスの小林さんと仕事について語ったことなどなど、すべてが京王線勉強会の実施を後押ししてくれている感じがして、すごくやる気をもらって東京に戻ることができました。

意外と長くなってきたので、そろそろ締め

JAWS-UG京王線勉強会が開催されたら、ぜひとも参加してください!京王線京王線連呼しれますが、京王線井の頭線沿線のJAWSな人たちを盛り上げていくことが目的ですので、沿線に関係ない方もよろしくお願いします!

中央線のコアメンバの方々、高尾山ビアマウントでのイベントの際は是非一緒に何かできたらと思ってます。(京王線高尾山口駅があるのでw)

re:Inventの参加報告ブログは近いうちに書きます。。。

下手な文章を読んで下さりありがとうございました。

(追記) ロゴを募集してます

大事なことを忘れてました、誰かロゴを考えてくださる優しい方はいませんか?自分の中での京王線のイメージは馬車道なのでそのあたりのイメージとか、かっこいいのができたらいいなあと(他人任せ)。
(「馬車道」というと京王多摩川駅の飲食店を想像してしまうのが京王線ユーザの性だということをすっかり忘れてました。「馬車鉄道l」とか「馬車軌間」といったほうが良いようです。 )

※勝手に会社名や名前を出させていただいた方、NGだったらFBなどで凸ってください(先に許諾をとってなくてすみません)

SR-IOV対応版AMIでのカーネルアップデート時は注意 (自分用メモ)

AWSの(いろいろな意味で有名な)マッツォさんがSR-IOV版CentOS6.5のHVM AMI*1を公開してくれて、ありがたく試していました。最近になってそのインスタンスを気軽に yum update して、再起動したら eth0 と(つけてないけど) eth1 が up しなくてアカンヤツになってしまいました。

まあ、当然といえば当然ですね。SR-IOVのドライバはカーネルモジュールなので、カーネルのバージョンが変われば動作しなくなってしまいますよね。というわけで、カーネルをupdateするときには以下のようにしましょう。(注:アップデート後のカーネルが2.6.32-431.20.3.el6.x86_64の場合です。適宜読み替えてください。)

# yum update
# mkdir tmp
# cd tmp
# curl -O http://jaist.dl.sourceforge.net/project/e1000/ixgbevf%20stable/2.14.2/ixgbevf-2.14.2.tar.gz
# tar xf ixgbevf-2.14.2.tar.gz
# cd ixgbevf-2.14.2/src
# BUILD_KERNEL=2.6.32-431.20.3.el6.x86_64 make install
# reboot

これで大丈夫(だった)。

AWSウルトラクイズで優勝しちゃいました

土曜日に思い切り寝まくって、現実に戻ってきました。駄文ではありますが、記録には残しておこうと思い、1年半ぶりくらいのブログを書いております。

7月17日、18日の2日間で開催されたAWS Summit 2014。
なかなかセッションの内容が埋まらないなあと思ったまま申し込みを忘れていたため、7月の頭まで登録をしていなかったのは内緒です。

申し込みが遅かったので、一番聴きたかったTech Deep Dive by Amazonのセッションはひとつも取れておらず、事例系のセッションをひたすら聴講しておりました。各セッションでは、AWSは自分たちの売上が上がることよりも、ユーザのサービスやシステムが低コストで効率よく構築・運用できるかという視点でアドバイスやサポートをしてくれているということが語られていたと思います。自分が携わっているサービスで利用しているので、その点は結構感じます。
あと、ユーザの声が大きくなるほどその要望が実現されやすくなるということで、Amazonさん自身も積極的に聞くようにしていますし、発表者の皆さんも積極的に要望をあげているというのも面白いしなと思います。

Intelさんの発表の中では、最後にちらっとなんで現行インスタンスのほうが旧世代インスタンスよりも安いのかについて触れられていたのかも良かったです。現行世代のインスタンスはIvyBridgeのCPUを使っていて、旧世代のSandyBridgeよりも1ソケットあたりのコア数が多くなっています。そのため、少ないハードでより多くの仮想マシンを提供できるので、インスタンスの単価を下げることができるそうです。より多くのユーザが利用してハードウェアの購入単価が下がるということもあるのでしょうが、こういった部分も値下げに寄与しているんですね。


Summitのそれぞれのセッションも楽しみにしていましたが、一番楽しみにしていたナイトセッション、毎年恒例のJAWS-UG勉強会 in AWS Summit!事前にビア(だけじゃないよ)とおつまみが振る舞われて開始されました。人大杉で知り合いも来ているはずなのに、相変わらずのぼっちでスタート。。。いや、いいんです、勉強会のコンテンツさえ聞ければ。。。と思ったら、ぼっちの特等席である壁際を陣取ったために、後ろ過ぎて全く内容が聞こえてこませんでした。。。WernerとJAWS-UGメンバのパネルディスカッション聴きたかった。。。
※あとで知り合いの方が話に来てくれて、最後までぼっちだったわけではありません

そして、お待ちかねのAWSウルトラクイズ。前々回は全くダメで、前回は仕事で参加できなかったので、今年は壇上に上がるくらいにはなりたいなと意気込んで参加しました。危うさもありつつ、なんとか正解を重ねて壇上へ上がることができた時点で、ほぼほぼ満足してしまっていました。 見回してもても、壇上にいる人たちは猛者ばっかりですし、敗者復活によってCertificateを3つ持ってるマサカリ集団が上がってくるし、一旦全滅するし、全然わからない問題ばかり出るしで、運と勘に頼るしかなかったです。

そして運命の時が訪れました。

問題
Amazon WorkSpacesのユーザボリューム(Dドライブ)のスナップショット頻度は?
[グー]6時間
[チョキ]12時間
[パー]24時間

(WorkSpacesは発表された時の説明を少し聞いたくらいで、使ったこともないからマニュアルとかサービス説明よんでねーよー!!!まったくわかんねーーー!!!)

(6時間じゃちょっと早い気がするし、24時間だとちょっと自動でやるにしては長すぎるんじゃないか。間をとって12時間だな。)

デーデン♪(みんな一斉に回答の手を挙げる)

(あーーー、チョキ出してるの一人しかいない。。マサカリerが違うの出してるんだから終わったわ。。。)

「正解は12時間!」

(え、マジ?えっ?えっ?えっ?)
この時点で頭が真っ白になってました。というわけで、このへんの記憶が曖昧だったりしますw


2位と3位も決まり、表彰式でAmazon CTOのWernerから目録(?)を頂いて、もう笑うしかない状態。仕事中には出ることのない満面の笑みで写真撮影に応じていたかと思います。完全な浮かれポンチ(古)ですね。いや、でも本当に嬉しかったことは確かです!


壇上から降りて、「締めの言葉オナシャス!」と言われ、真っ白第二弾。。。
全く言葉が浮かぶはずもなく、ただただキョドって終わってしまいました。本当に申し訳ありません。。。いいおっさんなんですし、もっと度胸つけるようにします。

当日は全く何も言えなかったので、この場を借りて伝えたいと思います。
まさか自分が優勝できるなんて夢にも思っておらず、嬉しいと同時にもっと頑張らないといけないなと気を引き締めています。Twitterなどで皆様から温かい言葉をかけていただきまして、本当に感謝しております。re:inventではちゃんと吸収してこられるように、まずは英語を聞き取れるようにしたいと思います。そして、ベガスぼっちにならないように社交性も高められればと思っております。関係者の皆様、おめでとうと言ってくださった皆様、本当にありがとうございます!

と言った感じで、AWS Summitは無事終了。複数の部隊に分かれて2次会(?)へ向かいました。私は脱藩先の仕事やプライベートでもお世話になっているサーバーワークス組に混じって、天狗で飲んでました。翌日は二日酔いでした。。。

長々と駄文を失礼しました。

(実はブログを書くよりも他にやることあるだろうというツッコミを受けそうでビクビクしています。そちらもちゃんとやりますので、お手柔らかに。。w)

JAWS DAYS 2013 DAY2で「Eight meets AWS」という発表をして来ました #jawsdays #jawsug

ちょっと遅くなりましたが、3月16日のJAWS DYAS 2013のDAY2で発表して来ました。

概要はこちら
Ustの録画はこちら。(動画マジ恥ずかしい。自分では冒頭だけ見て、まだ全部は見れていません。)

発表資料の方は、こちらからご覧いただけます。

内容としては、おおまかに言うと下の3点。

  • AWSのEC2以外のサービスをうまいこと使って運用コストを下げましょう
  • 使いづらい部分があったらSDKを使って使いやすいツールを作るといいよ
  • SWF使ったよ (#ヤマンさんへの感謝を込めて)

途中、Amazonさんの回し者なんじゃないかというくらいAWSのサービス押しを決めてましたが、Management ConsoleのVPC周りがちょっと使い勝手が良くないので、そのあたりをもう少し改善してくれると、ライトユーザも使いやすいんじゃないかなと思って発表にも織り交ぜておきました(ライトに使っていたら感じない不満かもw)。

資料を見て、何かお気づきの点などありましたら、ご指摘ください。

社会人になってから初めての発表ってこともあり、かなり緊張していたのですが、進行役(?)のAmazon 松尾さんが頷きながら聞いてくれているのを見て、結構救われました。

懇親会でもいろいろな方とお話させていただいて、特にChef関連の話をしている時に、Amazonの松井さんが「OpsWorksはまだまだおもちゃみたいなもん」(酒が入っていたので間違って覚えていたらごめんなさい)といっていたのは良い収穫だったと思う。もう少し待ってから触って見るくらいでもいいのかも。
JAWSUGのコミュニティの素晴らしさも改めて実感できたし、応援(冷やかし?)に来ていた後輩もああいう雰囲気の中に放り込むことができたし、大変充実した一日でした。

帰宅後に、恐る恐るTogetterで反応を見てみましたが、皆さん温かい目で見守ってくださっている感じがして嬉しかったです。

技術以外の部分で成長できるいい機会をくださった AWS&JAWSUG の方々、本当にありがとうございました!
(忙しすぎて発表の機会を譲ってくれた先輩にも感謝!)

Redis + Sentinel で自動フェイルオーバ in Amazon VPC を試してみた

お久しぶりです。
最後にブログを更新したのがInternal ELBが登場して勢いで書いた6月11日。。。更新してなさすぎですね。

そこで今回試してみたのは、Redis + Sentinelの自動フェイルオーバをAWS VPC環境で実現するというものです。

元々は「 RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店 」を参考にして構築しようと考えていたのですが、VPC(というかAWS)の環境ではbroadcastやmulticastが使用できないので、VRRPが使えず断念。そこで少し途方にくれつつ考えたのが、Sentinelを使う方法。

Redisについては特に説明は必要ないと思いますので、Sentinelについて簡単に。

  • 監視: masterやslaveが期待通り動いているかどうかを定期的に監視
  • 通知: 指定したログレベルのものが発生した時に、管理者やプログラムに通知を行う
  • 自動フェイルオーバ: master障害時にslaveをmasterへと昇格させる。redisを使っているアプリケーションに新しいmasterのIPアドレスを通知する

詳細はこちら( Redis Sentinel Documentation – Redis )を参照していただければと。

構成

構成としては、以下のような感じです。すべてCentOS6.3(ちょっとだけカスタムAMI)を使っています。

  • web(application)サーバ2台
  • Redis + Sentinelサーバ2台

f:id:matetsu:20121228110332p:plain
※ #ヤマン さんによる「 VPCでアベイラビリティゾーン越しにプライベートIPを共有する(Source/Descチェック外し) - c9日記 -カタヤマンがプログラマチックに今日もコードアシスト 」のような構成です。

webサーバは特に言及することはなく、Redisに接続するためのIPとしてVIPである 172.16.0.10 を使うようにするくらいです。
Redisサーバでは、以下のような設定をします。

  • 両機のループバックインターフェイスに予めIPエイリアスとして 172.16.0.10/32 を設定
  • インスタンスのSource/Dest Checkをdisableにしておく←これ重要(masterにするスクリプトでもdisableにするようにしてるけど)

VPCのroute tableの設定はmaster/slaveの設定をするときにスクリプトを使って一気にやってしまうので、先に設定しておく必要はない。

Redisの設定(初期設定)

master/slaveの関係を作る前のRedis初期設定は以下のようにしています。

slaveof no one
masterauth [pass]
requireauth [pass]

くらいしか変えていません。

Sentinelの設定はこちら。まだ特に関しの設定はせずに、起動するだけになっています。

この状態で、まずはサービスを起動します。

# service redis start
# service sentinel start

Master/Slaveの設定

続いて、redis01をmaster、redis02をslaveとして設定します。

基本的には単純にredis-cliからslaveofコマンドを実行するだけなのですが、requireauthを設定しているので、パスワードを入れるのが面倒だったので、以下の様なpythonスクリプトにしています。

また、masterノードのVIP(ループバックに設定したやつ)にwebサーバからのアクセスを向かせるために、VPCのroute tableを設定するためのスクリプトも準備しておきます。ACCESS_KEYやSECRET_ACCESS_KEY,routetable_idは自分の環境にあわせてください。

このスクリプトでは、自分自身のインスタンスIDにVIPへのアクセスをルーティングするようにしています。

このスクリプトと、実行ノードをmasterにするスクリプト(redis-to-master.sh)、指定したmasterノードのslaveにするスクリプト(redis-to-slave.sh)を組み合わせて、master/slave構成を取るようにする。


redis-to-master.shとredis-to-slave.shの中で、sentinelが監視するクラスタの情報を登録するためにsentinel.confを変更する処理も入っています。この処理は、以下のテンプレートのmasterノード情報をsedを使って置換しているだけです。

以下のように実行して少し待てば設定完了です。

[redis01]# redis-to-master.sh
[redis02]# redis-to-slave.sh redis01

フェイルオーバを試す

ここからが本題です。
フェイルオーバはSentinelが自動で行なってくれて、masterが切り替わったことをアプリケーションに伝えてくれるとのことですが、VIPを使ってVIPの向き先を変更することで対応しています。

sentinelの設定で指定している client-reconfig-script で指定しているスクリプト redis-failover.sh では failover endが渡された時に route-table を書き換えてVIPを自身のインスタンスIDに向けるようにしています。こうすることで、webサーバ側では特に接続先を変えなくてもそのままの設定で接続できます。もちろん、failover endが渡ってきているので、自動フェイルオーバが完了して、もともとslaveだったノードがmasterとして稼働します。

また、SentinelがWarning以上のステータスを検知した場合に通知するためには notification-script に通知スクリプトを指定する。

これで、フェイルオーバが起きたことを検知することもできる(もちろん監視も忘れずに)。
フェイルオーバが起きた時には、以下のようなログが出力される。上のnotification-scriptだと、5通のメールが来ることになる。。。これも「+hoge」となっているEvent Typeを見て分岐したりもできるので、もう少し改良の余地はあるかと思います。

[23304] 15 Jan 19:59:06.858 # +sdown master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:06.859 # +odown master mymaster MASTER_IP 6379 #quorum 1/1
[23304] 15 Jan 19:59:17.395 # +failover-detected master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:17.495 # +failover-end master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:17.495 # +switch-master mymaster MASTER_IP 6379 SLAVE_IP 6379

masterが切り替わったあとも、webサーバからはVIPでそのままアクセスできることも確認できた。まだまだ検証しないといけないこともあるけれど、それなりに簡単にフェイルオーバの仕組みを構築することができました。

Sentinelについては、簡単に動かしてみた程度なので、もう少し詳しく調べてみたいなと思っています。


年末に勢いで3分の2くらい書いたところで放置してしまっていましたが、このまま眠らせておくのもアレですし、とりあえずアウトプットしておこうとようやく書き上げました。不備などありましたらご指摘ください。gistも(ほぼ)初めて使って見ました。
今年はちゃんとブログにアウトプットしていきたい!

VPCのInternal ELBを早速試してみた

AWS

待ちに待ったあいつが来ましたよ!この時をどれほど待ったことか。(まだ1年も触ってないのにw)

VPCでPrivate IPでアクセスできるELBが来ちゃいましたよ!
外からはアクセスさせたくないけど、内部的なアクセスを負荷分散させたい時には欲しかったですよね。

というわけで、早速。

ELBを作る


EC2のメニューから「Load Balncers」を選択
f:id:matetsu:20120611212813p:plain

右上ペインから「Create Load Balancer」を選択
f:id:matetsu:20120611213131p:plain

いつもの通り、必要項目を入力 (薄く見えちゃってますね、ヤツが)
f:id:matetsu:20120611213454p:plain

Create LB InsideをEC2ではなくvpc-hogehoge(設置するVPC ID)にすると。。。

チェックできます!
f:id:matetsu:20120611213845p:plain

あとは適当に項目を埋めていき
確認画面で、Schemeが「internal」になっていることを、十二分に確認したら
f:id:matetsu:20120611214511p:plain

「Create」ボタンを押しましょう。

確認する

ELBの一覧画面で、先程作ったLBを見てみると、
f:id:matetsu:20120611214850p:plain
DNS nameに「internal」なんてついちゃって、wktkしますね。

さっそくVPC内のインスタンスから確認してみましょう
f:id:matetsu:20120611220920p:plain
ちゃんとPrivate IPになってますね!

さすが

いやはや、AmazonさんマジAmazon。すごいですね、このスピードでの機能リリース。

今回のリリースでいろいろと捗る人たちがどれだけいるんだろうっていうくらい、素晴らしくそしてうれしいリリース!本当に待ってました!
internet向けのELBだとACLやらSGの穴を開けるのがアレだったり、内部で制御しなきゃいけない部分が多かったりと苦労もありますが、Internal ELB、ステキ過ぎますね。

今日はこのリリースを聞いて、業務を忘れて触り始めてしまいました!(ぉぃぉぃ

MySQL Beginners Talk #1に参加してきたので、そのメモ

参加してきました。思い切りそのままメモ転載。

初心者向けMySQLの始め方 - tmtmsさん

  • MySQLオープンソース(GPL)なRDBMS
  • たいていのLinuxには含まれている
  • 今なら5.5系を使いましょう
  • 公式バイナリを使うのがいい
  • 設定ファイル(my.cnf)は読まれる場所は全部読まれて、あと勝ちになるので注意が必要
  • skip-name-resolve, innodb-file-per-tableとかshow-warningsとか
    • skip-name-resolveをしておくと、クライアントが接続してきたときに逆引きしなくなる
  • mysqld_safeは最近は安定しているので使わなくてもいいと思う
  • kill -9 はダメ、絶対!
  • 待受ポートはTCP:3306とUNIX Socket:/tmp/mysql.sock
  • パスワードの設定はプロンプトの画面で set password [for user@host] = password('hogehoge');
  • -pの後ろに空白は要らない
  • (初期状態では)匿名ユーザ(適当な名前のユーザ)はパスワードなしでtest DB(information_schema)にアクセスできる
    • 気持ち悪いので消しておいたほうがいい(基本的には自分自身からしか繋げないけど)
    • root@localhostだけ残して消しても問題ない
  • たいていは grant all on DB名 to user@host; で権限を与えれば良い
    • 細かくもできるがDB単位くらいで
  • 127.0.0.1localhostは違うよ!
  • 日本語
    • 初心者は黙って utf8
      • [mysqld] character-set-server = utf8 / [mysql] default-character-set = utf8
      • アプリなどは、それぞれで指定
  • charset と collation
    • charsetはコードと文字の対応(ざっくりいうと)
      • mysql-5.5からはutf8mb4も使える
    • collationは文字の照合順序
      • utf8_general_ciはデフォルト大文字小文字を区別しない
      • utf8_binは大文字小文字を区別する
      • utf8_unicode_ci はUCAによるcollation。全角半角も区別しない。

ORACLEさん、ハイパー宣伝タイム

  • MySQLの普及率 60.5% (2009年調べ)
  • 資格認定試験 = MySQL 5 Database (Administrator|Developer) など
    • 実際の運用管理の現場で求められる知識とスキルの認定
  • 資格に対応した講習もあるよ
    • TuningやClusterの講習もあるが、テキストが英語です!
      • 秋くらいには日本語でできるかも(確約はできません)
  • トレーニング・オンデマンドというビデオ教材での研修もある
    • テキストはPDF
    • 有効期限は購入より3ヶ月
      • 半額で3ヶ月延長可能
    • iPadでも見られるよ!
      • HTML5 の動画なので
    • MySQLの講習は日本語化されていません!
      • ITの世界は英語必須だから、問題ないよね
      • しゃべっている内容が字幕で出るので、全文検索もできて便利

MySQLインストールお作法 - @meiji さん

  • あまりよく考えずにソースからインストールするのはやめましょう
    • 本に書いてあるからってダメ!絶対!
    • 公式のバイナリがいいよ
    • RPM全部入りのやつもあります
      • その中でどれ入れたらいいの?
      • Cのライブラリ(libmysqlclient.so.xx)が必要なら、MySQL-sharedが必要。shared-compatパッケージには旧バージョンのライブラリが入っている
      • 5.1まではshered-compatとsharedの共存は不可(compatに最新版も含まれているため)
      • libmysqlclient.soを使わないプログラムを書く場合は、MySQL-connectorが必要
    • Windowsはbitを気にすればいいだけ
      • インストール時のcharset周りのpath周りだけ気をつけてね
  • データとバックアップ/バイナリログは別の場所(ディスク)にしておこう

MySQL日本語利用徹底入門 - @nippondanjiさん

MySQL文字コード

  • 照合順序
    • 文字の並び順
    • ソートや比較の処理に影響
    • show collation
  • 文字コードがセッションごと/テーブルごと/カラムごとに異なるかも
    • 柔軟さの現れだが、扱いには十分注意
    • カラムごとに指定可能で、指定しなければテーブルのデフォルト文字コード、テーブルの文字コード指定がなければDBの文字コード、DBの文字コード指定がない場合はcharacter_set_serverが使われる
    • 基本はcharacter_set_serverを指定しておく
  • 照合順序の指定
    • カラムであればcollate utf8_binのように指定
  • 確認方法
    • show create table テーブル; で文字コードを確認すること大事
    • show full fields テーブル; でcollationの確認ができる(collationがわかれば文字コードもわかる)
    • information_schemaを使って確認することもできる
  • 文字コード関連のオプション
    • character_set_server
    • character_set_database
    • character_set_connection
    • character_set_client
    • character_set_results
    • character_set_system
    • character_set_filesystem
  • skip_character_set_client_handshake
    • クライアントが指定した文字コードを無視
      • C APIPHPの時に便利
      • Connector/Jでは効かない
  • default_character_setはserver側の文字コード指定では使えない(MySQL5.5以降)
    • クライアント側では使える

文字コード関係のトラブル

  • 文字化け
  • LOAD DATA IN FILE
    • ファイルの文字コードがcharacter_set_databaseになっていることを期待される
    • テーブルの文字コードと同じ場合には bunary に一時的にSETしてあげる
    • mysqlimportを使う
  • SELECT ... INTO OUTFILE
    • 後で LOAD DATAで読む場合は binaryを指定するといい
    • CHARACTER SET 〇〇 のように指定するといい
  • latin1で格納されている?
    • セッションの文字コードもテーブルの文字コードもlatin1の場合には化けずに格納できてしまう
    • はまりやすい
      • SELECT INTO OUTFILEなんかでbinaryでダンプして作りなおす必要あり
  • 5C問題
    • Shift JISの2バイト目が0x5C (\) の場合に起こる
  • ラウンドトリップ変換
    • ダッシュサインなんかがいい例
    • 検索の時に引っかからなくなる

まとめ

  • 自動変換が起こらないようにする
  • 迷ったらすべてutf8いで統一する
  • showコマンドやinformation_schemaで色々捗ります
  • 鍵本が近日増刷予定!

LTセッション

studio0340_comさん

  • スロークエリどうにかならない?
    • innodb_buffer_poolを増やして対応
      • 本当に改善って言っていいの?
  • インデックス使っていないスロークエリを探せ!
    • min_examined_row_limit
      • 指定行以上のテーブルから読み込んだクエリをスロークエリに記録する
      • これがデフォルト10000行以上 デフォルト値は0なので記録されない。潜在的な性能劣化をさせる危険性を秘めているクエリを見つけるために10000行とかにしておく。ただ、これを超えないと記録されないので、値の設定は吟味が必要。
  • mysqldumpではまった
    • ダンプ中に更新が走ったものは、その間(ロックされている間)は更新されない
  • dump-slave
    • ダンプ中はreplicationが止まる!
    • パッチができて、対応(実際はFlush logsに関するもの)

Beginnerならきっと役立つMaster-Slave環境 - @yut148さん

  • Paasで無料なのもあるよ!
    • ただ使うだけなら自前で環境作らなくてもよいのではないかということ
    • 流れるデータには注意

MySQL Casual Talks - @myfinderさん

  • ガチュアルではなくカジュアルです!
  • ノウハウの共有 ≠ 事業価値の毀損
    • 画像がDBに入っていたっていいじゃない
    • autoincrementでもいいじゃない
  • あなたの疑問は誰かの疑問
  • LTは直前でも申し込みOK
  • #mysql-casual@freenode (IRC) で開催について最初に話されるよ(多分)

1台から500台までのMySQL運用(Beginners編) - @kazeburoさん

  • Livedoorは基本的には開発者がサーバを見てきた
    • サービスごとに差が生まれる
    • いくない
  • 仮想化によるサーバ集約で4桁台あったサーバが400台に
  • 基本的にはMySQL 5.1.x
    • 必ずinnoDB-pluginを使う
      • Fast Index Creation 様さま!
  • my.cnfを共通化
    • セットアップツールの提供
      • よくあるチューニングを施してある
  • my-moder.cnf
    • 標準のはいまいち
    • オレオレmy.cnfに自身がある人いない?
  • No MyISAM
    • 絶対に使わない
    • kill -9 しても壊れない
  • xtrabackup
  • ログ系のテーブル
    • Expire処理を忘れるとひどいことに
      • 必ず消すことを忘れないように!
    • 件数が多くなると、削除するほうが大変です!削除戦略をしっかり立てておきましょう。
  • モニタリング
    • 必須です

私がMySQLを始めた理由 - オラクルのやまさきさん

  • MySQLGPL
    • 発展が多くの人に価値をもたらす

感想など

@tmtmsさんのお話は、初めて触る方がどんなことに注意しながら使っていったらよいかという視点で、実際に動かしてある程度何かをしてみるまでの導入部分をすべて網羅しているんじゃないかなと思いました。自分のように触り始めてある程度たった人でも、基本的な部分を見なおしてみるのにはすごくいい機会になりました。

さすがに@nippondanjiさんの話はBeginnerの枠を超えていたような気がしなくも無いですが、最初に文字コード周りの話を理解しておくことでハマりポイントを減らすことができるので、いいですね。さすがエンジニア目線だけでなくサポート目線も持っている方だなぁと、あっけにとられながらも勉強させていただきました。鍵本は増刷されたらぜひとも購入させていただきたいと思います(まだ買ってないのかなんて言わないで><)。

自分は大規模なサービスでMySQLを使ったことが無いですし、ガチなチューニングなんかもしたことがないので、ペラッペラな知識や経験しかないのですが、こういった基礎的な部分を再確認させてもらえる機会があったのはすこくプラスになりました。ガチュアルと呼ばれる人たちに少しでも近づけるよう、最低限基礎は染み込ませておきたい。

追記

  • 2012.06.11コメントでの指摘を受けて min_examined_row_limit のところを修正