MySQLカンファレンス2007 １日目 リアルタイムレポート
注：このレポートはかなりの割合でスライドの内容の写しで、ときどき話していることを絡めています。まとめがすごいんじゃなくてプレゼンスライドの内容がすごくまとまってるってことですよー
MySQLユーザーカンファレンス2007に来ています。会場カコヨス！
Matz氏登場 - MySQLカンファレンス2007
MySQL高可用性ソリューションの概要 - MySQLカンファレンス2007
DRBDおよび Heartbeat による高可用性MySQL：MTVジャパン、モバイルサービス - MySQLカンファレンス2007
MTV Flux/MTV Mobile DB projectにおけるMySQL構成の話
DR:BD/Heartbeat HA Master 構成
- スケール的にはSingle Masterよりちょっといい
- アプリに関して
- Single masterとほぼいっしょ
- フェイルオーバーが十分早いのでたいした影響がない
- Heartbeatに関して
- 設定が大切 間違えの余裕がない
- peerの接続が特に注目点
- 本番化する前にテスト
- mysqld
- DR:BD
- 既存システムに導入の場合、ディスクのレプリケーションが必要
- 動きを理解するため十分検証するとよい
- アウテージがあった場合、drbdステータスの確認が必要
よかったこと
悪かったこと
- 勉強や検証に時間をかける必要がある
- 設定やソフトの関連性が複雑
- mysqldプロセスの再起動はシンプルではない
- 運用の関係者も設定や動きを理解しないといけない
MySQL パフォーマンスチューニング&ベンチマーク - MySQLカンファレンス2007
http://www.mysql-ucj2007.jp/details/e13.html
Agenda
- An introduction to Benchmarking
- data structures
- query optimisation and query cache
- etc..
Why Benchmark?
The Good Scientists Guide to Benchmarking
- The scientific method suggests changing only one variable at a time
- The scientific method suggests repetition, more than once to verify results. If results vary greatly, think about taking averages
- Repeat, rinse , repeat , rinse!
- 少なくとも3回は。
The Good Scientists Guide to Benchmarking II
- Isolate your environment
- Use a different MySQL instance
- Savle all configurations!
Benchmarking Tools
Benchmarking Tools II
Slow Query Log
- log_slow_queries=/var/lib/mysql/slow-queries.log
- long_query_time=2
- Then, use mysqldumpslow
- In 5.1, you can log these details ...
-
-
EXPLAIN columns
- select_type
- table
- ...
「オンラインで読んで」
Scans and seeks
- A seek, jumps into a random place to fetch needed data.
- A scan will jump to the start of the data...
When do you get a full table scan?
- No WHERE conditions
- No index on any field in WHERE condition
- When your range returns a large number of rows, i.e. too many records in WHERE condition
- Pre-MySQL 5, using OR in a WHERE clause
- SELECT * FROM
Subqueries
- Don't use them; replace with a JOIN
- unique_subquery: results are known to be distinct
- index_subquery: otherwise
- Co-related subqueries are worse
- ...
Indexes
Good Schema Practice
- Use small data types
- Is a BIGINT really required?
- Small data types allow more index and data recoreds to fit into a single block of memory
- Normalise first, de-normalise later
- Generally, 3NF works pretty well
正規化しすぎない。
Storing IP addresses
- IP addresses always become an INT UNSIGNED
- Each subnet corresponds to an 8-byte division of the underlying INT UNSIGNED
- From string to int? Use INET_ATON()
- From into to ...
Query Cache
- スライド
- たくさんのストレージエンジンがある
- Understand your applications read/write ratio for most effective use
- Compromise between CPU usage and read performance
- Remember that the bigger your query cache, you may not see better performance, even if your application is read heavy
Query Cache Invalidation
キャッシュの無効化
- Coarse invalidation designed to prevent CPU overuse
- ...
- Thusm any modification to any table referenced in the SELECT will invali...
Choosing a Storage Engine
- MySQLs strong point: many engines MySQLはたくさんエンジンがあるよ
- Use InnoDB for most operations (esp. OLTP), except:
- big, read only tables
- high volume streaming tables(logging)
- specialised needs (have special engines)
- Tune InnoDB wisely
PBXがブログとかにいい。
Quick InnoDB Tuning Tips
Real World MySQL Use (RWMU)
- Run many servers
- Your serious application cannot run on "the server"
- "Shared nothing" architecture
- make no single point of contention in the system
- Scales well, just by adding cheap nodes
- If it works for Google, it will work for you!
RWMU: State and Session Information
- Dont keep state within the application server
- Key to being stateless: session data
- Cookies are best validated by checksums and timestamps(encrypting is a waste of CPU cycles)
RWMU: Caching
RWMU : Data Partitioning
- replication is great for read heavy applications
- Write intensive applications should look at partitioning
- Partition with a global master server in mind
- Give out global PKs and cache heavily (memcached)
- ...
- Consider the notion of summary databases
RWMU: Blobs
- Large binary object storage is interesting
- Image data is best kept in the filesystem, just use metadata in DB to reference server and path to filename
- Try the Amazon S3 storage engine?
- ...
RWMU: Misc.tips
Resources
services
- http://www.mysql.com/training/
- 日本語における認定が今月末(2007年9月末)から始まる
新ストレージエンジン Falcon のアーキテクチャ詳細技術解説 - MySQLカンファレンス2007
Falconとは
InnoDBとの主な差異
ほかのストレージエンジンとの比較
図
Falconのアーキテクチャ概略
- 4つのメモリ領域に分けて開設 Record Cache, Page Cache, Log Cache, System Cache
- できるだけ多くのレコードをRecord Cacheに乗るようにしてある
- Record CacheはPage Cacheよりもオーバーヘッドが少ない
プロセス/スレッド
ファイルの読み書き
シリアルログファイル、データファイル
インデックス構成
インデックス値の圧縮
- 接尾辞の圧縮
- 数値型：末尾のゼロを圧縮
- 文字列型：末尾の空白を圧縮
- 接頭辞の圧縮
- 各ページの先頭のインデックス値は圧縮しない
- 2番目以降のインデックス値は、開始何倍とが先頭のインデックス値と一致するかを調べ、その分を圧縮する
- うまくいくと60%ぐらい圧縮できる
- 圧縮処理をするので当然CPUは使っちゃう。on/off切り替え可能にするか検討中
インデックスアクセラレータ
レコードの取得
- インデックスを検索し、レコード番号を取得
- レコード番号から実際のレコードを取得
- メインのレコードの取得はキャッシュから行われる
データ型と消費サイズ
FalconはTEXT/BLOB型を別メモリ領域に管理する
AUTO_INCREMENTの動作の違い
トランザクション、ロック、MVCC
ロストアップデートの自動検知
- ロストアップデートとは
- Falconの動作を、設定でInnoDBと同じにすることもできる（デフォルトで同一にする方向）
Next-Key Lockingとは (InnoDBのロック制御)
- InnoDBログファイルとバイナリログの不整合をっふせぐために必要な実装
- Insert INTO t1 .. SELECT .. FROM t2
- t2に対して共有ロックをかける
- UPDATE t1 SET xx WHERE non_index_column=x;
- フルテーブルスキャンになる。スキャンしたレコード全体に対して排他ロックをかける
- UPDATE t1 SET xx WHERE non_unique_index_column=x;
- 当該インデックスと、その前後に対して排他ロックをかける
- セッション１:INSERT INTO t1 SELECT * FROM t2
- セッション２:INSERT INTO t2 VALUES(...)
- セッション2がセッション1よりも前に終わったとする
- バイナリログの中身は、順番が逆転する
- Next-Key Lockingはこれを防ぐための実装
FalconではNext Key Lockingは発生しない
- 同時実効性の低下は5.1で回避される
参考資料
- マイコミジャーナル： Falcon徹底リサーチ
- MySQL Developer Zone: Falcon in depth ベータ版リリース後に公開
- MySQLオンラインマニュアルにて http://dev.mysql.com/doc/falcon/en/index.html
- MySQL Forge http://forge.mysql.com/wiki/Falcon
