TED

TED のおすすめタイトルふんふん、というのをみかけるので だいぶ TED が知られるようになってきたってーことなのかしら。 ノイジーなエントリを目にしたくはないものだ。

なまり

イタリア
http://thechangelog.com/post/2801342864/episode-0-4-5-redis-with-salvatore-sanfilippo


フランス

それっぽい訛りだな〜というのがなんとなく感じられるけど、内容を理解できてるかは別・・・
第二言語はこんなものだと思ってさっさと身につけるべきだなぁ。。

IaaS なクラウド

はストレージ・I/O まわりがキモだよなぁとさくらのクラウドの障害を
Twitter 上でみていて改めて思った。

今はどうかわからないけど、某社の「クラウド」とうたってるIaaSなものをお試しでつかっていたとき、サーバによって cron の時間が異なっていた。
その件について問い合わせてみると、

I/O 負荷を軽減させるため

だとか・・・。なんともな〜という回答を貰った。1年くらいまえなので今は解消しているのかもしれないけど。

料金周りで AWS よりオトク！に提供するものがあるかもしれないけど、であれば AWS と同等のものを用意したうえでそういうプライスでないと魅力的ではないと思う。
まぁ〜無理な注文だよな。

しかしながら、後発でクラウドを謳うのであればそれくらいのものをもってきて欲しいのは事実。。くらうどぎょうしゃさんたいへんね。

これから

今後についてどうすればいいんだろう、とぼんやり考えている。

相変わらずサーバ・インフラまわりをやっているのだけど、AWS を利用している今、言ってしまえば単なる

AWS オペレータ

でしかないのではないか？と思ったりしている。
いわゆる「オンプレミス」な環境と比べると、やらないといけないことは減っているのでそのぶん

弱体化

していたり、

骨抜き

になっている、と感じていたりもする。

また、やはり AWS をはじめとしたクラウドのものは「なにかを作り出すひとが活用するもの」のような気がしていて、そうでない人が使う分には自分自身の首を絞めるもののように思っている。

DevOps について考えてみたりもするけれど、やはり「プログラマからサーバインフラ」より「サーバインフラからプログラマ」は難しいものだと感じている。若い時期のある程度ものごとに没頭できる時間、というのを自分はサーバインフラ周りに費やしてしまった。その頃、サーバインフラを「メインで」やりつつ、がりがりプログラムを書いているひとはほぼいなかった。いるとしても、すでに自分の手から離し、没頭できる時間を確保できているひとくらいだったかな。

これまで通り自分も手を動かすけど、今後は動かしかたをぐぐっとかえていく感じ。

[AWS] MySQL な RDS を 5.1 => 5.5 する(予定

EC2, RDS 再起動祭りの最中、まえから標題の作業をすることになっていたのでごそごそと事前作業。
主に所要時間がどれほどかかるかの計測に勤しむ。。

まず抑えておくポイント。

その1
「CSV での出力はややめんどい」
というのも、RDS は MySQL のインスタンスではあるもの、ふつーのサーバのように ssh ログインしてローカルにファイルを作成することができない ( SELECT ... INTO OUTFILE ができない ) 。こんなかんじ => https://forums.aws.amazon.com/thread.jspa?threadID=41443
まるっと SELECT なんだよなぁ。。。うぅむ。
当然ながらまるっとデータディレクトリを rsync なぞできない。なにかしら MySQL を介す必要がある。

その2
「Amazon RDS Customer Data Import Guide for MySQL」をみよう
ここ => http://aws.amazon.com/articles/2933
これをみると、

• でかいならフラットファイルにして mysqlimport すべし
• 1G毎にすべし
• RDS の自動バックアップはきるべし、データロード後に有効にするべし

といったことがかかれている。** 自動バックアップは ReadReplica 持ってる RDS は切ることができないので注意！！ **

で、以前 5.1 => 5.5 ではなく、us-west-1 => ap-northeast-1 に移行したときは特にフラットファイルにせず、mysqldump したファイルを圧縮 => us-west-1 の EC2 から ap-northeast-1 の EC2 へ rsync => 展開 => mysql でぶちこむ、というので終わらせた。そのときはダンプファイルサイズが計 13G でインポートだけで3時間くらいかかった。

さて今回。。mysqldump したもののファイルサイズは 30G超(テーブル毎にダンプ). うち最大のものは 18G.
愚直に mysqldump 〜 mysql でインポートしてみると、、てんでだめ。お話にならない速度。
ふつーのサーバのように mysqld とめてまるっと rsync できるなら簡単なのに・・・

次。駄目元でためしに Import Guide の最初にあった mysqldump と mysql をパイプでやっちゃう手法をためす。(Small Loads From .. ってかいてあるんだけどね)
でかいテーブル (mysqldump で1G以上になったもの) だけ並列で走らせてみると、最長で2時間半。
うーん。。なかなか厳しい。しかも、5つとも1度は Lost Connection エラーがでていた。不安。

その次。フラットファイルにして1G毎に分割して mysqlimport する。
こいつはなかなか手間がかかって、

• 前述のフォーラムに書かれているとおりにまるっと SELECT したのをごにょごにょして CSV として書きだす。
  
• show create table でスキーマを調べて、mysqlimport 前にテーブルを作っておく
  
• split する
  
• mysqlimport する
  

・・・という手順なのだけども、mysqlimport は set foreign_key_checks=0; を実行することができない orz..
軽く調べてみたかんじ、提案されてパッチが作られたりしてるものの、実装はされておらず。
ここ => http://bugs.mysql.com/bug.php?id=19996
facebook の中の人もそのような機能をいれてたりhttp://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/5.1/revision/3459

くっそーーー、、と思いつつ、仕方がないのでパッチをあてた mysqlimport を作成し利用。
その後インポートしてみるも、、今のところ

• warning 多発
• 1Gあたり20分？

という状態. warning は CSV にしたとき "" でくくってるのが "" 含んでそのまま入ってるせいだろうか・・・。--fields-enclosed-by= つけわすれたし・・！
また、autoincrement のことを考慮してなかったので id がずれまくり orz...
ひとまずそのへん対応するとして、、このインポート速度はどうしたもんか。
よし！これでいける！という感触がまだつかめない。

つづく。