Road To Nowhere

主にWebまわりのエンジニア的なお仕事に関するようなことのあれこれ。

Oracle MySQL Developer Day – Tokyoに参加してきた。

MySQL

アジェンダ

10:00〜12:00 MySQLエッセンシャル＜技術概要＞
12:00〜13:00 昼食タイム
13:00〜13:45 MySQLレプリケーション&スケーラビリティ
13:45〜14:30 MySQL Cluster
14:30〜14:45 休憩
14:45〜15:30 MySQLパフォーマンス&チューニング概要
15:30〜16:15 MySQL管理&運用
16:15〜16:30 閉会

場所は青山のオラクル本社。
初めて行きましたがとても立派な建物でオシャレ！
社員さんがうらやましい。

以下走り書きの自分用メモ。気が向いたら補足します。
全体的にMySQLの初歩的な部分が多かったのでかなりはしょってあります。
正直言って日常の業務でMySQLを触っている人には物足りない内容だったかもしれません。

MySQLエッセンシャル＜技術概要＞ スピーカー梶山氏

  • mysql 5.6
    • optimizer
      • (small)limit使用時のファイルソート高速化
      • index condition pushdown ICP
      • batch key access BKA
        • join時、サブクエリ時のパフォーマンス改善
        • join bufferを増やせば増やすほど高速に
        • diskゴリゴリ使用時に劇的に改善
      • explainの改善
      • 更新系のクエリでもexplain可
      • optimizer trace
        • selectの内部処理をtraceできる
      • innodbのoptimizer staticsを永続化（？）
    • こちらが詳しい http://nippondanji.blogspot.com/2011/04/mysql-56.html
    • preformance schema
    • replication
      • slaveのクラッシュセーフ
      • slaveのスレッドをマルチスレッド化（スキーマ単位）
      • time delayed replication
        • わざと時間差をつけて同期する。スナップショットのようなもの。
    • not only sql options
    • other
      • partitionごとのimport export強化
      • notonlysql mysql
    • under develop
      • full text search(under develop)
      • smaller page size(under develop)
      • binlog api
      • global transaction id
      • マルチコアスケーラビリティ
      • サブクエリ高速化
      • explain 結果の構造化。見やすく。
      • オンライン操作。インデックス関連。
      • ssd 最適化。

MySQLレプリケーション&スケーラビリティ スピーカー奥野氏

  • このセッションで期待すること
  • レプリケーションタイプ
    • 非同期
      • ずっと接続しておく必要がない
    • 準同期
      • 最低ひとつのスレーブが書き込んだことを確認
    • 同期
      • すべてのスレーブでデータが完全同期
  • フォーマット
    • 文ベース
      • データが少ない
    • 行ベース
      • データ量が多い
    • mixed
      • いいとこどり
  • レプリケーション短所
    • システムダウンでデータロストの可能性あり
    • ひとつ以上のスレーブでのフェイルオーバー、フェイルバックが煩雑。
    • リカバリされたマスタはバイナリログに欠損の可能性あり。
    • スレーブとマスターでタイムラグがある。
  • レプリケーション利用法
    • 高可用性
    • スケーラビリティ
    • セキュリティ、バックアップ
    • 分析
      • スレーブを集計用に利用するのによい。
    • 長距離感のデータ配布
      • ネットワークがつながっていればOK。
  • binlog(バイナリログ)について
    • マスターのすべての変更を記録している。
    • binlogインデックスファイル
      • どのバイナリログが存在するかの情報
    • ポイントタイムリカバリに使用可能。
    • show binlog events;
  • マスターのクローニング
    • 省略
  • 書き込みのスケールアウト
    • シャーディングまたは分割。

MySQLパフォーマンス&チューニング概要 スピーカー梶山氏

  • チューニングの基本
    • 設定の確認
      • show variables like 'auto%';
      • 大量のソート処理をｓるときは、 set で一時的に変更するのもあり。
      • show にもsession とgloabalがある
    • 何が起こっているのか確認
    • slow query logを有効にしておくこと！
  • チューニングのルール
    • いきなり本番でやらない
    • ちゃんとしたベンチマーク
    • 一回で一つのことをやって確認する。コンビネーションはあとから。
    • 結果をよく見る
      • cpu
      • io
      • クエリ
    • 結果を記録しておく
  • ストレージエンジン
    • innodb
      • myisamからするとデータファイルは2-3倍
      • 圧縮可能
    • myisam
      • 参照ははやい
      • データファイルがの信頼性がいまいち
      • コンパクト
  • innodbチューニング
    • innodb_buffer_pool_size
      • 一番重要
      • なるべく大きく確保してデータをメモリにのせる
      • データが全部メモリにのると劇的に早くなる
    • innodb_flush_method = O_DIRECT
      • 性能が変わる可能性がある。遅くなる可能性も。
  • myisamチューニング
    • key_buffer_size
      • インデックスのメモリのサイズ。データはのらない。
      • あまり大きくしてもしょうがない
  • connection
    • thread_cache_size
      • 一回ずつ接続するアプリケーションの場合
      • 作ったスレッドをキャッシュしておける。
      • つないで切ってを繰り返す作りだと有効かも。
      • mysqlはシングルスレッド・マルチプロセスなので神経質にならなくてもいい。
  • sessionごとのパラメータ
    • sort_buffer_sizeなど
      • なるべく初期値にしておいて、大きい処理を行うときだけ変更するのが吉。
  • query cache
    • ジキルとハイドのような！
      • クエリが一文字でも違えば別のキャッシュ。
      • 場合によっては使わない方がいいときもある。
  • インデックス
    • prefix index
      • カラムの先頭何文字という指定でインデックスを作れる
    • join対象の列それぞれにインデックスあると吉
    • indexのつけすぎはよくない
      • 更新負荷が高くなる
  • explain
    • optimizerの動きを見る
  • query
    • フルテーブルスキャンをしない
    • log_query_not_use_inde
      • インデックスを使っていないクエリをはきだし
    • 前方一致はインデックス使うけど、広報一致は使わない
  • schema
    • 最小のデータサイズ型
    • procedure analyse
  • performance schema
    • どちらかといえば内部の開発者にとってうれしい

MySQL管理&運用 スピーカー奥野氏

  • 基本コマンド
    • mysql
    • mysqladmin
      • サーバ構成
    • mysqlcheck
    • mysqldump
      • backup
    • mysqlimport
      • restore
    • mysqlshow
    • mysqlslap
      • 負荷をかける
    • mysqld
    • mysqld_safe
      • log のセットアップなど
    • mysql_server
    • mysqld_multi
  • 内部スキーマ
    • information_schema
      • anci sql
      • sqlで参照できる
      • 表、ビュー、ストアド、トリが、イベントなどを見る
  • パフォーマンススキーマ
    • mysql開発者がボトルネックなおをさぐれる
    • コードに埋め込まれているinstrumetntation pointを使ってデータ収集
  • mysql workbench
    • official gui アプリケーション
      • SQL開発
      • データ設計
      • 管理者
  • mysql workbench ユーティリティ
    • 各種
    • 積極的に開発されている
  • バックアップツール
    • ホットバックアップ（オンライン）
      • 有償
  • mysqldump
    • 長所
      • 小規模向け
      • DBが壊れてなければ確実
      • SQlでバックアップ
    • 短所
      • リストアが遅い
      • オンラインではない（テーブルロックを必要とする）
      • 増分バックアップができない（毎回フルバックアップ）
      • 一貫性がとれない
  • レプリケーション
    • 動作継続（マスタに負荷がかからない）
    • クイックリカバリ
    • ブロックしない
    • 他のバックアップオプションと連動
    • 短所
      • 非歴史的
      • アーカイブじゃない
      • 論理障害につかえない（まちがったクエリ発行に無力）
  • mysql enterprize backup
    • 物理バックアップなのではやい
    • フレキシブル
    • 圧縮可
    • 一貫性あり
    • いいことづくめ
    • 短所
      • プランニングが必要
  • モニタリング
    • enterprize monitor(商用)
      • 統合ビュー
      • 企業向けサポート
      • クエリ分析
      • エキスパートアドバイザ
        • 140以上のルール、50以上のグラフで監視可能
        • upgradeした方がいいとアドバイスくれたり
      • レプリケーションモニタ
        • 同期チェック
      • クエリアナライザ
        • 実行クエリの分析
        • ひとつひとつのクエリのドリルダウン。explainなど
      • 新ルールの追加も可能
  • パフォーマンスとストレステスト
    • sysbench,DBT2は単純な性能試験
    • 最終的には実アプリケーションでの試験が必要
  • QA
    • oracleとmysqlどっちがいいの？
      • スペックをおさえた状況ではmsyqlのが優秀
      • クエリにもよる。いちがいにいえない。
    • mysql 5.6、cluster 7.2はいつリリース？
      • 5.6の年内のGAリリースはない。
      • 7.2も開発中。約束できない。
    • 来年2月にリリース案件があるが7.2本番で使える？
      • 海外ではすでにリスクをとって動かしている例もあるが。

まとめ

最初にもちょっと触れたけど毎日MySQLを触っている人にとっては新しい情報が少なく物足りない内容だったかもしれない。
収穫らしい収穫はMySQL5.6のGA版が年内にはでないとはっきりわかったことだろうか。
ただMySQLの概要から運用テクニックまで改めて聞いてみると、本当に素晴らしいソフトウェアだと再認識。
無料で使わせてもらっていることにもうほんと感謝感謝！
最後に、こんな充実したセミナーを無料で、しかも弁当まで用意していただいて、オラクルさんありがとうございました。