MySQLユーザーカンファレンス2日目

in

1日目に続き、 MySQL Users Conferenceの2日目に行ってきました。

個人的感想

  • MySQL Clusterは高可用性と高信頼性、フェールオーバー待ちも恐れるとき
  • 一般用途にはDR:BDおよび通常のレプリケーション設定の方が良い
  • Connector/J、MySQL Proxy
  • MySQL 5.1に大いに期待

以下各セッション・・・

パネルディスカッション

  • MTV Japan、XAMPP、MySQL AB CEO、MySQL fellow、MySQL architect
  • 有償サポート依頼したのはDBAがいないから (MTV Japan)
  • MySQL ProxyはFreeでLB、ロギング、キャッシュ?の機能あり
  • MySQL開発で優先しているのは安定性、パフォーマンス、使い易さ
  • 後回しにしているのは開発コミュニティー、タイミング (レプリカの非同期性とか?) (fellow)
  • 機能セットはユーザー要望にしたがって進めている
  • 5.1では行ベース複製で、確定的ではないクエリーも同期取れるよ (nowを使ったクエリーとか?) (architect)
  • 5.1にはまだ怖いからしないかなー (MTV Japan)
  • 5.1向けに5.0からテストケースを2倍に増やした
  • 「仮想企業」MySQLは、フィンランド、カリフォルニア、ドイツ、東京に拠点があるが、どこが本社ということもない
  • 在宅で、朝起きてIRC, AOL, Yahoo!等で他の開発者と連絡を取り合う
  • 採用したい開発者はGoogleとかぶるが、うちは在宅をアピールしている
  • お金を節約したい人と時間を節約したい人のどちらにも対応できるMySQL
  • Oracle, DB2に比べての優位性は、設定しやすさと、経験者の多さ

国内大手メディア企業における MySQL Cluster 導入事例

  • NRI 梶山氏
  • 5.0まではオンメモリだが、正常にシャットダウンすればディスクに入る
  • 冗長化しておけば一台落ちてデータが失われることもない
  • サードベンダーのHAは、共有ディスクにデータを格納する場合が多い
  • MySQL社は、春の (海外の?) カンファレンスではDRBD + Heartbeatを推しに推していた (今回はClusterか)
  • 2UのPCサーバー2台、MySQLとNDBストレージを共用した
  • ほぼ参照ばかりの表はMyISAMにし、更新が行われる表のみクラスター構成にした
  • Javaアプリだったが、MySQL提供のConnector/Jを使って接続先サーバーをバランシング
  • 50万以上する外部ストレージや同じく50万以上するクラスタソフトを入れずに済んだ
  • 一度やり方を覚えれば、同じ設定でさまざまなシステムに応用できる
  • 5.0.30前後での検証時は、不具合はかなりあったが、いまはかなり直った (が若干不安定な気配)
  • データノード追加時は要検証。速くなるとは限らない
  • フルスキャンになってしまうとMyISAMよりかなり遅いが、engine_condition_pushdown設定を変えるとかなり改善
  • JOINが多いと性能劣化。5つくらいJOINしてるとなかなか返ってこない
  • ログパラメーターの設定が複雑。チェックポイントでのフラッシュなど
  • 32bitサーバーはメモリ4GBなので無理がある。(IAまたは) EM-64T, X86-64を
  • 2台でも可用性は充分で、上記のような問題がなければアプリ変更は不要
  • SCIカードは高性能だが高くて導入せず
  • クラッシュリカバリーについては、バイナリログを残していればここからでも直せる
  • キャリアグレード版だと、Cluster同士のレプリケーションが取れる

ランチタイム

  • 今日は無料ではないが、従業員向け食堂で600円
  • なかなかおいしい

MySQL Cluster入門

  • メルボルン出身 Stewart Smith クラスターチーム
  • 高可用性(99.999%)、高パフォーマンス、ミリ秒フェイルオーバー
  • MySQL Clusterの管理サーバーは、動作と言うよりは、サーバーを増やすような時に使う?
  • MySQL Cluster Certificationは普通のとは別だよ

MySQL Cluster詳細解説

  • 入門と同じ講演者
  • JOINのようなある種のクエリーにはethernetはいまいち。TCP転送とSCIカードが使える。
  • 100Mではなく、ギガビットを使うべし
  • Heartbeatにも障るからCluster専用にプライベートネットワークを
  • internodeのやりとりは暗号化されてない
  • Cluster用に三種類のIndex (Primary/Unique/Ordered Tree) 作る時に変えられる
  • hash → key lookup。ordered tree → range。unique → order by
  • データ量計算法には、データセットやマニュアルを読むのが基本
  • ndb_size.plで既存のDBについてCluster時のサイズ見込みについてレポート作れる
  • engine_condition_pushdown設定で5~10倍
  • EXPLAIN EXTENDED
  • DataMemory設定: 4nodes, 2replica, DataMemory=100MB → 2copies * 200MB data
  • MaxNoOfConcurrentTransactions等Cluster用パラメーターもあり
  • REDO Log (System Restart用) サイズ。超えると 410 Out of log file space
  • 通常数百メガだが、64MB * 300 = 19.2GB くらい必要になるシステムもあろう。動作中に設定変更可能。
  • commit != disk persistence
  • チェックポイント。ディスクレスモードもある
  • ndbクラスタ単位での複製可能
  • クラスタごと行う理由は、地理的 (別データセンター) な冗長化。もう一つはmonthly reports用などでロードを分割できる
  • マスターを普通に複製してそこで再度ndbクラスター作れば良い
  • マスターとスレーブのバックアップを用意し、ndbクラスターを共有させることも可能
  • (がんばればかなりHigh Availability実現できそう)
  • NDB APIはパフォーマンス改善や、クラスター処理に不具合があるような時に使う
  • 「MySQLが有料のSCIカードを推すのは矛盾では?」そんなには高くないよ →質問者その通りと思ったが、下層レイヤーまで書く余裕がないのでしょう

MySQL 超高速化 KnowHow

  • Sun 河原氏。若い
  • Sunは統計機能がLinux等より豊富。特にDtrace
  • 大抵遅いのはディスク。特にコストをケチられてる内蔵ディスク
  • あとはSQL。特にRuby on Railsみたいなフレームワークが作るSQL
  • iostat -Cxn 1 でディスク使用率%bやレスポンスタイムasvc_tを確認
  • vmstatで実行待ちスレッドrやswap, freeを確認してメモリー増設
  • 最適なバイナリーを使う。-O3や-O5でコンパイルするだけでも違う。64bit版
  • OSとデータで、せめてパーティションを分けると、マウントオプションを最適化できる
  • mpstatで、CPUのうち1つに負荷が掛かっていないか確認。デバイスドライバが張り付いているかも
  • mallocをMT対応の物に。UFSの--forcedirectioを。fasttimeモジュールを
  • ディスク48本搭載の「Web2.0サーバー」はいかがですか
  • (超高速化、て大げさじゃないかな)

Web システムを支える Zend と次世代プラットフォームへの対応

  • Zend Japanの取締役佐藤氏
  • PHPはトップシェア、のグラフが出たが、比較はASPやServlet。例えばPerlは?
  • ZendはSIやサポートをしてます
  • WIMP (Windows IIS)。Microsoftと協業中でFastCGI対応
  • NETCRAFTによると、IISのシェアも30%きてますよ
  • (次世代プラットフォームってWindows 2008サーバーのことか・・・)

MySQLテクニカルケーススタディー

  • Jimmy Guerrero氏。人少ない
  • スケールアウトとスケールアップを間違えるとか、flickrの説明など、プレゼン翻訳の質が低かった
  • データウェアハウスでは、速度を低下させずに複雑な照会や解析を行えるかどうか
  • MyISAMはデータウェアハウス用に作られた
  • ほとんどさんしょうアーカイブストレージエンジンなんか使えるんじゃない?
  • 政府の要件を守るために殆ど参照されないデータを保管しておく場合にArchiveエンジン
  • Archiveでデータを15~20%に圧縮される
  • 5.1のパーティショニング、テーブル容量110TBなど

MySQL テクニカルケーススタディ(海外事例解説)

  • Jimmy Guerrero氏
  • ロスアラモス国立研究所で5,500万件以上の記事を含むアプリケーション
  • 認証用のMySQL Serverを立てて、その裏にMySQL Serverが並ぶ構成
  • 12ノード、234GBメモリ、7TBディスク
  • Cox Communicationsはケーブルテレビ情報の管理、解析等
  • 1200万のケーブルモデムへのポーリング
  • 2台のxSeriesサーバーでRedHatを動かし、20億行のMySQL
  • 海外では電気通信事業に広がっている
  • アルカテル・ルーセントではリアルタイムアプリからWANの裏に複数のMySQLクラスター
  • feedburnerは、リードが多いのでクエリーキャッシュが非常に有効に作用
  • ドイツで3番目に大きいメールオーダー会社 Neckermann.deの例
  • 商品数14万、一日50万人が来訪
  • セッション管理を高コストのSMPシステムからMySQLクラスターに
  • PowerEdge 1855 bladeに、SuSE Linuxエンタープライズ。インテル EM64-T
  • 8GB RAM。データベースは6GB
  • DRBDは、LinBitがメンテナンス。
  • 待機サーバーへのフェールオーバーは "virtual IP management" を通して行う
  • 米footnote.com 歴史的資料の書庫。社員数は80人
  • 表数63、最大の表は3600万行以上、DBサイズ計15GB
  • fastiron, serveriron, netapp fas 3020ha, 35-40 Dell 1955 blades
  • CentOS 4.4, MySQL 5.0.36, 読み取り専用Slaveは1台
  • woodstone servers alive, gandia, splunk, automysqlbackup

レセプション

  • アルコールと食べ物出たよ!すげー
  • 抽選で、スリランカの紅茶セットがあたった

セイロン茶セット

その他

  • Zend Frameworkの品質はまだ微妙。評価段階か。1.1が今月には出そう
  • PHPにてApacheとの連携の高速化、workerへの対応は予定なし
  • PHPからMySQL接続のネイティブドライバがβ版。5.3には入るのではないか
  • Slaveの足し方。一台のslaveを落として新サーバーにファイルコピーし、設定部を変えて、再度復帰。
  • MySQLクラスターはデータの同期が必要な高信頼性システム用で、一般にはDRBDと通常のレプリケーションを使うのが良いと言うことか →そうだ

他の方のブログより

追記 セッション資料が公開されました。

Trackback URL for this post:

http://nonn-et-twk.net/twk/trackback/93
0