Oracle MySQL Developer Day – Tokyoに参加してきた。
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概要など
- 一日65000ダウンロード!
- ほぼ同じ説明を以前聞いたことがあるので省略 http://d.hatena.ne.jp/kazumaryu/20100902/1283437935
- 最新のバージョンはmysql 5.6 DMR
- DMR = Develop Milestone Release
- モバゲーはMySQLサーバー700台!
- f5のロードバランサーでも組み込まれている
- hardwareについて
- Fusion-io
- CyberAgentで劇的に性能が向上した例がある
- これかな。http://fusionio.seesaa.net/article/229896125.html
- SSD
- 劇的に性能改善した例が増えている
- Fusion-io
- MySQL15分ルール
- インストールから使用まで15分で!
- install後やること
- test database 削除
- root account 削除
- root anonmous host から接続できないように
- 匿名アカウント削除(anonymous account delete)
- mysql_secure_installation http://dev.mysql.com/doc/refman/5.0/en/mysql-secure-installation.html
- アーキテクチャ
- ストレージエンジンの役割
- データ保管、インデックス利用、メモリの使い方、トランザクションについて、同時実行性
- information schemaでengine確認可能。
- select * from information_schema.tables where table_name='xxxx';
- show create table xxx;
- ストレージエンジンの役割
- mysql on windows
- windowsでは5.5にした方がいい!かなりの性能改善が期待できる。
- mysql 5.6
- optimizer
- こちらが詳しい 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
- mysql cluster 7.2 DMR2
- mysql goals
- mysql cluster goals
MySQLレプリケーション&スケーラビリティ スピーカー奥野氏
- このセッションで期待すること
- レプリケーションの使い方
- 開発者vs管理者というアプローチ
- レプリケーションタイプ
- 非同期
- ずっと接続しておく必要がない
- 準同期
- 最低ひとつのスレーブが書き込んだことを確認
- 同期
- すべてのスレーブでデータが完全同期
- 非同期
- フォーマット
- 文ベース
- データが少ない
- 行ベース
- データ量が多い
- mixed
- いいとこどり
- 文ベース
- レプリケーション短所
- システムダウンでデータロストの可能性あり
- ひとつ以上のスレーブでのフェイルオーバー、フェイルバックが煩雑。
- リカバリされたマスタはバイナリログに欠損の可能性あり。
- スレーブとマスターでタイムラグがある。
- レプリケーション利用法
- 高可用性
- スケーラビリティ
- セキュリティ、バックアップ
- 分析
- スレーブを集計用に利用するのによい。
- 長距離感のデータ配布
- ネットワークがつながっていればOK。
- binlog(バイナリログ)について
- マスターのすべての変更を記録している。
- binlogインデックスファイル
- どのバイナリログが存在するかの情報
- ポイントタイムリカバリに使用可能。
- show binlog events;
- レプリケーションのセットアップ
- 省略
- マスターのクローニング
- 省略
- 書き込みのスケールアウト
- シャーディングまたは分割。
MySQLパフォーマンス&チューニング概要 スピーカー梶山氏
- チューニングの基本
- 設定の確認
- show variables like 'auto%';
- 大量のソート処理をsるときは、 set で一時的に変更するのもあり。
- show にもsession とgloabalがある
- 何が起こっているのか確認
- show status like 'innodb%';
- slow query logを有効にしておくこと!
- 設定の確認
- チューニングのルール
- いきなり本番でやらない
- ちゃんとしたベンチマーク
- 一回で一つのことをやって確認する。コンビネーションはあとから。
- 結果をよく見る
- cpu
- io
- クエリ
- 結果を記録しておく
- innodbチューニング
- myisamチューニング
- key_buffer_size
- インデックスのメモリのサイズ。データはのらない。
- あまり大きくしてもしょうがない
- key_buffer_size
- connection
- thread_cache_size
- 一回ずつ接続するアプリケーションの場合
- 作ったスレッドをキャッシュしておける。
- つないで切ってを繰り返す作りだと有効かも。
- mysqlはシングルスレッド・マルチプロセスなので神経質にならなくてもいい。
- thread_cache_size
- sessionごとのパラメータ
- sort_buffer_sizeなど
- なるべく初期値にしておいて、大きい処理を行うときだけ変更するのが吉。
- sort_buffer_sizeなど
- query cache
- ジキルとハイドのような!
- クエリが一文字でも違えば別のキャッシュ。
- 場合によっては使わない方がいいときもある。
- ジキルとハイドのような!
- インデックス
- prefix index
- カラムの先頭何文字という指定でインデックスを作れる
- join対象の列それぞれにインデックスあると吉
- indexのつけすぎはよくない
- 更新負荷が高くなる
- prefix index
- explain
- optimizerの動きを見る
- query
- フルテーブルスキャンをしない
- log_query_not_use_inde
- インデックスを使っていないクエリをはきだし
- 前方一致はインデックス使うけど、広報一致は使わない
- schema
- 最小のデータサイズ型
- procedure analyse
- performance schema
- どちらかといえば内部の開発者にとってうれしい
MySQL管理&運用 スピーカー奥野氏
- 基本コマンド
-
- mysqld
- mysqld_safe
- log のセットアップなど
- mysql_server
- mysqld_multi
- mysql workbench ユーティリティ
- 各種
- 積極的に開発されている
- バックアップツール
- ホットバックアップ(オンライン)
- 有償
- ホットバックアップ(オンライン)
- mysqldump
- レプリケーション
- 動作継続(マスタに負荷がかからない)
- クイックリカバリ
- ブロックしない
- 他のバックアップオプションと連動
- 短所
- 非歴史的
- アーカイブじゃない
- 論理障害につかえない(まちがったクエリ発行に無力)
- モニタリング
- enterprize monitor(商用)
- 統合ビュー
- 企業向けサポート
- クエリ分析
- エキスパートアドバイザ
- 140以上のルール、50以上のグラフで監視可能
- upgradeした方がいいとアドバイスくれたり
- レプリケーションモニタ
- 同期チェック
- クエリアナライザ
- 実行クエリの分析
- ひとつひとつのクエリのドリルダウン。explainなど
- 新ルールの追加も可能
- enterprize monitor(商用)
- パフォーマンスとストレステスト
- sysbench,DBT2は単純な性能試験
- 最終的には実アプリケーションでの試験が必要