2月13日に開催されたエスキュービズム社内勉強会資料です。

1. 意外と知らないかもしれない...
MySQL

2. メジャーバージョンの系譜
レプリケーション
古いバージョンのMasterから新しいバージョンのSlaveへはできない
メジャーバージョンの差は1つまで
4.0 サポート終了
4.1 サポート終了
5.0 サポート終了
5.1 RHEL/Cent OSでyumで入る
5.5 RHEL/Cent OSでremiレポジトリを使うとyumで入る
5.6 2013年2月5日リリース

3. Maria DBへの流れ
Oracleの「10の約束」の期限は2014年12月。
OracleへのMySQLプロジェクトを閉鎖的にしているとの批判
Fedora19ではMaria DBが標準に。
そこから派生するであろうRHEL/Cent OS7でも?
4.0 サポート終了
4.1 サポート終了
5.0 サポート終了
5.1 RHEL/Cent OSでyumで入る
5.5
RHEL/Cent OSでremiレポジトリを使う
とyumで入る
5.6 2013年2月5日リリース
MySQL AB
Sun Microsystems
Oracle

4. MySQLのインストール
yum install mysql-server
chkconfig mysqld on
service mysqld start
/usr/bin/mysql_secure_installation
使ってますよね？
test データベース削除
rootパスワード設定
匿名ユーザ削除
remote hostからのrootログイン禁止

5. my.cnf
デフォルトのmy.cnf
・長年メンテされてない
MySQL5.5では動かないパラメータがある
想定するハードウェアスペックが低すぎる
・オプションが少ない
・想定外のケースで使ってしまうケースがある
my-innodb-heavy-4G.cnfは「複雑で思いクエリを処理するが想定する接続数は少ない」という意味
/usr/share/mysql/ 以下にあるサンプル
my-small.cnf
my-medium.cnf
my-large.cnf
開発環境以外でそのまま使ってはいけない
実運用には適していない

6. ログ
・エラーログ
・一般クエリログ
・スローログ
・バイナリログ
エラーログ以外はデフォルトでは出力されないことに注意
バイナリログが出力されていない場合、
後述のロールフォワードリカバリができない
バイナリログ未出力は業務使用では絶対にNG
以下4つのパラメータは必ず確認が必要
log-bin=mysql-bin
expire_logs_days=7
max_binlog-size=1G
sync-binlog={0¦1}

7. スローログの解析
Percona Toolkit(旧Maatkit)
MySQLの便利ツール
Appエンジニアで使っている人をあまり見ないが、
O ReillyのMySQL本や鍵本などMySQL関連本には必ず載っている。
#yumもしくはcpan/cpanmで以下のモジュールをインストール
yum install perl-Time-HiRes
yum install perl-IO-Socket-SSL
wget http://www.percona.com/redir/downloads/percona-toolkit/LATEST/percona-
toolkit-2.1.8-1.noarch.rpm
rpm -ivh percona-toolkit-2.1.8-1.noarch.rpm
pt-query-digest /path/to/slowlog.log
pt-query-digest --explain h=hostname,u=username,p=password --type tcpdump /tmp/
mysql.tcpdump > /tmp/pqd.out
スローログを簡単にサマれる(cronで結果をメールで飛ばしておいてDailyで結果確認等)
tcpdumpの結果を直接食べられる
バックアップやオンラインスキーマ変更等の操作系コマンドは個人的には使ってない

8. バックアップとリカバリ
オンラインバックアップ(無停止)
コールドバックアップ(要停止)
mysqldump
MySQL Enterprise Backup
LVM等のスナップショット
/var/lib/mysql/以下を丸ごとバックアップ
→使いどころとしては同じ環境を別サーバに立ち上げたい場合等にこちらの方が速い場合がある
オンラインバックアップによるフルバックアップからのロールバックリカバリ
+
バイナリログを使ったロールフォワードリカバリ
基本

9. リカバリ
mysqldumpによるフルバックアップ
障害発生
dumpファイルからのロールバックリカバリ
欠損
バイナリログを使ったロールフォワードリカバリ
フルバックアップだけではバックアップ取得時点∼障害発生時点までのデータが欠損
バイナリログだけでは起点となるデータがないためロールフォワードできない
したがって、どちらかが欠けてもNG

10. メモリチューニング
・クエリチューニング
・インデックスチューニング
・メモリチューニング(上2つの方が優先度高い)
MySQLの動作プロセスを理解しておく
MySQLの動作はシングルプロセスマルチスレッド(マスター側)
接続毎にスレッドを1つ立てる
mysqldサーバプロセス 接続スレッド
接続スレッド
接続スレッド
グローバルバッファ
スレッドバッファ
スレッドバッファ
スレッドバッファ
MySQLが使用する最大メモリ=
グローバルバッファ+max_connections スレッドバッファの合計値

11. メモリチューニングの方向性
※DB専用サーバ&innodbの場合
innodb_buffer_poolsizeに全体の5∼7割を割り当ててやる
[@development ~]# mysqladmin -uroot -p extended-status | egrep '(Max|Threads_)'
Enter password:
| Max_used_connections | 24 | ←これまでに記録された最大同時接続数
| Threads_cached | 0 |
| Threads_connected | 1 | ←現在開いている接続数
| Threads_created | 1905 | ←接続を処理するために生成された接続数
| Threads_running | 1 | ←スリープ状態になっていない接続数
調整
サーバ搭載メモリを超えた場合→swap発生
サーバ搭載メモリより少ない場合→サーバリソースを有効活用できない
32bit OSの場合、MySQLが使用できるメモリは2∼3GB前後になるという制限がある
↓
めんどいのでmymemcheck.plでチェック
アプリ側でコネクションプーリング有効にするとmax_connections減る
→三城で行ったパフォーマンステストではコネクションプーリングは参照系、更新系共に有効との結果が出ている

12. クエリキャッシュ
SQL文が以前に実行したものと同じ場合は
事前にキャッシュしておいた検索結果をそのまま返す
→SQL文のハッシュ値で比較するので一字一句違ってもダメ
mysql > SHOW GLOBAL STATUS LIKE 'Qcache%'
クエリキャッシュヒット率 =
Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached)
クエリキャッシュヒット率が低い場合、
クエリキャッシュオフにした方がいい場合もある
キャッシュに依存している構成の場合、いきなりmysqld再起動したりすると刺さる場合がある。
Slave複数台を負荷分散している場合、新参者のSlaveは比率下げてぶら下げるとか。

13. MySQL5.5、5.6の新機能
5.5
5.6
・準同期レプリケーション
・FLUSH LOGSでFLUSHするログを個別指定可能
・各種パラメータの指定方法の変更
レプリケーションの際のMasterサーバのhost名等がmy.cnfに書けなくなった
→change master toコマンド使う
・InnoDBでフルテキストインデックス使えるようになった
・InnoDBのいくつかのALTER TABLEでロックが掛からないようになった
・memcachedインターフェースの追加
・クエリオプティマイザを改善
サブクエリも最適化されるように。
UPDATE/DELETE/INSERTにもEXPLAINが使える
・GTID(Global Transaction ID) - スレーブの自動的な昇格が可能に
・遅延レプリケーション
・マルチスレッドスレーブ(SlaveのSQLスレッドがマルチスレッドに)
・/usr/my.cnf←ないわー

14. 準同期レプリケーション
MySQL5.5から使える
標準の非同期レプリケーション
クライアント Master Slave
更新SQL
ACK
更新SQL
ACK
データ更新
ログ送信
IOスレッド SQLスレッド
リレーログ読み取り
データ更新
ログ送信
障害発生
Masterは更新を続けるが、
障害発生以降、Slaveは更新されない

15. 準同期レプリケーション2
準同期レプリケーション
クライアント Master Slave
更新SQL
ACK
ACK
データ更新
ログ送信
IOスレッド SQLスレッド
リレーログ読み取り
データ更新
Slaveサーバからackが返ってきた時点で初めてcommitが成功
IOスレッドは同期処理、SQLスレッドは非同期処理=準同期
メリット
HA実現
デメリット
Masterの更新がSlaveのIOスレッドの処理に引きずられる。
(SlaveのIOスレッド、SQLスレッドはシングルスレッド/ただし5.6からはSQLスレッドがマルチスレッド)
ACK