MySQLカンファレンス2007 ２日目 リアルタイムレポート
MySQLユーザーズカンファレンス2007 ２日目のリアルタイムレポートです。
パネルディスカッション MySQLの独自性と優位点 - MySQLカンファレンス2007
MTVでMySQLをどう使っているか？
なぜMySQLを使うことにしたか？
安定性、パフォーマンス、使いやすさについて、MTVの例についてどのように考えているか
- MySQL AB Monty,
- もう使っていたということで追加努力が必要なかった
- 一番は使いやすさではないだろうか
- patrick,
- Yes.
優先順位が低くなった項目はあるか？
- 現在はコミュニティではないだろうか
- 司会；異議あり。製品についての優先順位を。
- Monty,
- 新しいフューチャーのフィードバックを受けて...（答えになってない？）
5.1のフューチャーに興味は？
- MTV patrick,
- 開発リソースは限られている
- 新しいのに行く前にテストしたい
- 開発コミュニティからの強いプッシュはあるだろう
- MySQL AB Brian Aker,
- テストケースの数が増えている
- 5.0から5.1で2倍になった
- テストケースのドキュメント化はされていない
- MTV patrick,
- テストケースがどれだけ多くても確認は必要だ
XAMPPについてお話ください
- XAMPP Kai Seidler,
- XAMPの概略
- テストは非常に時間がかかる
- 我々のパッケージは非常に短時間でセットアップできる
あなたの関心は？
- いろいろやってきたが半分ぐらいはインストールについてだった
- ダウンロード数は？
- 5年くらいやってきたけど...現在月々40万ぐらい
XAMPPはMySQLと対立になる？
- CEO Marten,
- 間に入るだけで対立にはならないよ
普及率について
- 長所の一つとして接続/切断が簡単
- 今まではコネクションのコストは低くなかった
- MySQLでブログも簡単に作れるようになった
コミュニティについて、どのようにスタートした？
ユーザーとしてどう？
- MTV Patrick
- コマーシャルな関係になったわけだけど...（以下よくわからず）
コミュニティから何を得られる？
- MTV Patrick,
- 同じ目的の人々がコミュニティに参加していることは安心できる
MySQLのビジネスモデルの独自性は？
- CEO,
- コミュニティは時間を使ってサポートを得る
- 時間を使いたくなければ、お金を出してサポートを得る
バーチャルな企業だけどどう？
- Brian Aker,
- ちゃんと小切手で給料もらってるからバーチャルじゃないよ（笑）
- どこでも仕事ができる。自宅で、砂浜で
分散していることのメリットデメリットは？
- CEO,
- もともとグローバルになろうと初日から始めた
- Googleと重なるところはある
- 世界中から優秀なエンジニアを集めることができる
日本について
- CEO,
- 3年前に日本は重要だと思った。投資が必要だ
- 東京にオフィスがあるがたとえば北海道からももちろんOK。バーチャルな会社だから
質疑応答
- Oracleとかと比べることは意味ないの？ どんな比較でもいいんだけど...
- CEO 同じ速度がでるかは比較できる
- Monty
- Brian 技術的には根本的に違う。ストレージを切り替えることができるとか
- Patrick Oracleはセットアップはうまくいくけど、頭痛がする。認定された人がいないといけない。PHPとOracleをつなぐのに4日かかったりする。複雑すぎて。MS SQLは、Windowsを買い足さないといけない。Apacheを動かすのはそれほどでもないけど、DBになるとODBCのドライバーを探さないといけない。セットアップが難しい。
- XAMPP Kai Oracleを使うときは知っている人を探さなくてはいけない。
国内大手メディア企業における MySQL Cluster 導入事例 - MySQLカンファレンス2007
http://www.mysql-ucj2007.jp/details/j21.html
MySQL Clusterとは？
MySQL+DRBD
3rdベンダ製HAソフト利用
- 共有ディスクにデータを格納
- たとえばLifekeeper
SQL層とデータ層の分離
事例：某メディア企業 情報サイト
システム構成概要
- ロードバランサ/Webサーバにより、APサーバへのアクセスを制御し、DBの負荷を分散
- APサーバからはConnector/Jのフェールオーバー機能を利用して耐障害性を確保
- DBサーバはPCサーバ２台、共有ディスクは無し
- オンラインで更新されるデータは、NDBDプロセス上のテーブルに配置
- 参照のみのデータは書くサーバのMysqldプロセス上のMyISAMテーブルに配置
- ...
APサーバ障害の場合
MySQLサーバ障害の場合
データノード(ndbdプロセス)障害の場合
MySQL Cluster導入メリット
- コストメリット
- 設計の横展開可能
- シンプルな構成なので他システムでも利用可
- スケールアウト構成
- 必要な箇所だけサーバを塚することで、柔軟なシステム拡張が可能。ただし、データノードの追加時は要検証。
MySQL Clusterで大変だったこと
- ソフトウェア品質は要改善
- 複数の致命的なバグ（signal 11発生など）に直面
- その後のバージョンでは改善傾向
- Bug #25668 (mysqldダウン） 5.0.36にて修正
- Bug #26176 (Signal11発生) ...
- ...
- パフォーマンス
- WHERE句つきのSELECT文が遅いことがある
- INDEX無しのカラムを検索すると遅い
- engine_condition_pushdouwn=ON で改善
- JOINの多いSQL文で性能問題
- 使用上の制限。一部のクエリを修正して回避
- パラメタチューニング（特にチェックポイント関連）が複雑
- WHERE句つきのSELECT文が遅いことがある
- データ量の制限
- オンメモリデータベースであるため、64bit版サーバの利用検討
MySQL Cluster 入門 & 詳細解説 - MySQLカンファレンス2007
高可用性
- 99.999% Uptimeのために設計されている
- ノーロックで、オンラインバックアップ
- NoOfReplicas
ハイパフォーマンス
- Not BEGIN to COMMIT Through Parallelism
- ひとつのトランザクションを速くするのではなくシステム全体を速くする
- インメモリ (4.1 and 5.0)
- メインメモリにインデックス
- Check point to disk
- フレキシブルで設定も十分できる
Shared Nothing
- 安いハード
- 安い接続（イーサネットなど）
- 高価なShared Diskは不要
クラスタリング
- 全てアクティブ
ストレージエンジン
- ENGINE=NDBCLUSTER
何がMySQL Cluster?
マネジメントサーバーの設定例
[ndbd default] NoOfReplicas= 2 DataMemory= 400M IndexMemory= 32M DataDir= /usr/local/mysql/cluster [ndbd] HostName= 192.168.0.40 [ndbd] HostName= 192.168.0.41 [ndb_mgmd] DataDir= /usr/local/mysql/cluster HostName= 192.168.0.42 [mysqld] [mysqld] [mysqld]
基本的なモニタリング
$ /usr/local/mysql/bin/ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1 (not connected, accepting connect from 192.168.0.1) id=2 @127.0.0.1 (mysql-5.1.19 ndb-5.2.3, Nodegroup: 0, Master) [ndb_mgmd(MGM)] 1 node(s) id=3 @192.168.0.1 (mysql-5.1.19 ndb-6.2.3) [mysqld(API)] 6 node(s) id=4 @192.168.0.1 (mysq-5.1.19 ndb-6.2.3) id=5 (not connected, accepting connect from any host) id=6 (not connected, accepting connect from any host) id=7 (not connected, accepting connect from any host) id=8 (not connected, accepting connect from any host) id=9 (not connected, accepting connect from any host)
$ /usr/local/mysql/bin/ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=1 @127.0.0.1 (mysql-5.1.19 ndb-6.2.3, starting, Nodegroup: 0) id=2 @127.0.0.1 (mysql-5.1.19 ndb-6.2.3, Nodegroup: 0, Master) [ndb_mgmd(MGM)] 1 node(s) id=3 @192.168.0.1 (mysql-5.1.19 ndb-6.2.3) [mysqld(API)] 6 node(s) id=4 @192.168.0.1 (mysq-5.1.19 ndb-6.2.3) id=5 (not connected, accepting connect from any host) id=6 (not connected, accepting connect from any host) id=7 (not connected, accepting connect from any host) id=8 (not connected, accepting connect from any host) id=9 (not connected, accepting connect from any host)
CREATE TABLE
CREATE TABLE t1 ( pk1 INT PRIMARY KEY AUTO_INCREMENT, v VARCHAR(100) ) ENGINE=NDB(NDBCLUSTER);
SHOW CREATE TABLE
mysql> SHOW CREATE TABLE t1\G
*** 1. row ***
Table; t1
Create Table: CREATE TABLE `51` (
`pk1` int(11) NOT NULL AUTO_INCREMENT,
`v` varchar(100) DEFAULT NULL,
PRIMARY KEY (`pk1`)
)ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
Don't see ENGINE=NDB?
- SHOW WARNINGS is your friend
Clusterで問題がおきたときは
標準的なスペックについて
- 参照キーはなし
- フルテキストインデックスはなし
ノードの復旧
- 新しいマシンを用意する
Node failureの場合はトランザクションは
- 続行している。
冗長構成
- Management Serverを増やしてもいいけど管理者の負担も増えるよ
通信について
- 通常はイーサネット
- めちゃ安いから
- しかし最速ではない
- ギガビットイーサで十分なパフォーマンスが出る
ハートビート
- Between data nodes and API nodes
- ハートビートが足りないときはそのノードがダウンしていると判断する
テーブル
- テーブルにはすべてPRIMARY KEYがある
- HASHアルゴリズムを採用する
- インデックスは3種類
- primary index
- unique hash index
- orderd tree index
（ディスク、メモリ）スペース使用量への配慮
- 5.1では可変カラムをサポートした
- インデックスが多いとメモリ食うよ
- インデックスの無いカラムをディスクのみに保存することもできる
- ディスクカラムは固定サイズ
- ストレージ要件は予測可能
- ndb_size.pl
- レポートを出してくれる
（ここでしばらくトピック化できる話じゃなくなってきたので深い眠りへ...）
質疑応答
- ノードの追加はどうするのか？
- ダイナミックなノード追加は今のところできない
- 現在での代案としては、別のノードグループを作ってレプリケーションしてSwitchする
MySQL 5.1 の詳細解説 - MySQLカンファレンス2007
Table/Index パーティショニング
- 全てのエンジンで使えるようにした
- 5.1で実現
パーティショニング例
レンジパーティショニング
ハッシュパーティショニング
キーパティショニング
リストパーティショニング
サブパーティショニング
パーティショニングで90%短縮！
アーカイブエンジン Enhancements
- I/Oのオペレーションが2倍になった
- メモリの要求が少なくなった
- AUTO INCREMENTをサポート
- Unique key support
- Non-unique key support
MySQL Cluster Disk-Based Data
Row-Based Replication
タスクスケジューラ
イベント例
Alterの高速化、インデックスの追加削除の高速化
インポートの高速化
- New option for mysqlimport utility
- --use-threads option allows DBA to specify multiple threads
- Particularly well-used by MySQL Cluster
データベースの管理性
New Performance/Load Testing Utility
memcache Engine
HTTP Engine
InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007
- http://www.mysql-ucj2007.jp/details/j25.html
- 木下 靖文 氏
NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ
（「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました）
InnoDBチューニングの王道的アプローチ
- クエリを改善して全体的に処理効率を上げる
- データサイズをできるだけ小さく
- メモリをできるだけ多く積む
コミット性能（同期書き込み）
- innodb_flush_log_at_trx_commit=1,0,2
- 0 1秒ごと
- デフォルト:1 コミットのたびに同期書き込み
- 2 1秒またコミットのたび
- マスターは1を推奨
同期書き込みのパフォーマンス
- fsync() (あるいはO_SYNC + write, fdatasync()) の速度に依存
- ディスクに対する同期書き込み１回の所要時間
- シーク待ち時間 4ms
- 回転待ち 4ms
- 転送時間 1ms
- 合計 9ms
同期書き込みのパフォーマンス向上
よくある問題
- 主キーは重複しないようにUUIDにした
- とりあえずインデックスつけた
- ...
クラスタインデックスと主キー
クラスタインデックスの特性を生かす
AUTO_INCREMENTとスケーラビリティ
巨大な列の扱いには注意
- InnoDB Buffer Poolには全ての列が読み込まれる
- ので、Text型は分けたほうがよいときがある
データ型と文字エンコーディング
innodb_buffer_pool_size
チェックポイントに影響のあるパラメータ
Next-Key Locking
- InnoDBログファイルとバイナリログの不整合を防ぐために必要な実装
Next-Key Lockingの無効か
その他のパラメータ
- innodb_thread_concurrency
- innodb_support_xa
- バイナリログとInnoDBログファイルの同期をとる（２相コミット）
- 5.0から
- デフォルトON
- innodb_autextend_increment
- 単位時間あたりのデータほげほげ
- デフォルト8MB すくない
- innodb_file_per_table
- テーブルごとにファイルを作成
- デフォルトoff
- table_cache
- 同時実効性をあげるための重要なパラメータ
- 目安は 同時接続数 x テーブル数
- 1024〜2048が一般的
- thread_cache
- 切断した後に、再接続を軽いコストでできるようにするためのキャッシュ
- コネクションプールを使わない場合に効果的
- 数百程度にすることも珍しくない
5.1での変更内容
- AUTO_INCREMENTの同時実効性の向上
- 透過的なテーブルの圧縮（オプション）
- row_format=COMPRESSED engine=InnoDB
- CPU使用率が若干増加す
- インデックスの追加/削除が高速になる
- 5.0までは１行１行処理してた
- 5.1からはインデックス領域だけの再作成ができるようになった
- 6.0ではオンラインで再作成の予定
- Next Key Lockignの無効か
- ...
シャットダウン時間の短縮
ALTER TABLE, LOAD DATAの高速化
- SET GLOBAL ...trx_commit=0
- 処理
- 1
大量の更新処理
マスターでは耐障害性、スレーブでは性能を追求
InnoDBがハードウェアを生かし切るために - MySQLカンファレンス2007
- コアだよ
- ソース変更しちゃうよ
- 資料はダウンロード可能になるよ
多CPUの有効利用について
- 基本方針は「不要な待ちを発生させない」
- 排他の期間は極力短い方がよい。
- マルチコア(マルチCPU)の恩恵は5.0.30を使わないと受けられない（Buffer Poolの排他制御において）
（コアすぎてまとめられない！）
